Secrets and Audit Logs

Useful logs without leaked credentials

An audit log exists so a person can review, after the fact, exactly what an agent actually did and why - which matters enormously for an autonomous system taking real actions. A good audit log records request IDs, which tool was called, what decision was made, how long each step took, the outcome, and the arguments used - but with any sensitive parts of those arguments already removed before writing. It should explicitly not include a wholesale dump of every environment variable, raw API keys, authorization headers, the contents of credential files, or full prompts that happen to contain sensitive data.

Redaction is the practice of replacing secret text with a safe placeholder marker, like [REDACTED], before it's written anywhere. The timing matters: redact before writing to a log, never plan to clean it up afterward - a secret that briefly touched a log file can already be captured by a backup snapshot, shipped to a log-aggregation service, or copied by someone else before you get around to scrubbing it. A good way to test that redaction actually works end-to-end is to plant a fake canary secret - a value made up specifically for testing, with no real access or value, that you can safely search for - and then check every log and generated artifact to confirm it never appears anywhere it shouldn't. Beyond redaction itself, restrict who can actually read these log files, and set a sensible limit on how long they're retained.

Goal: The final graded lab in this phase begins with an agent that's actively logging a real API key into plain text. You'll repair the logging code, rotate the exposed sample credential (since once a secret has touched a log, the safe assumption is that it's compromised and must be replaced, not just hidden), and prove the canary is completely absent from every newly generated log.