Auditing AI agent activity: structured logs for credential access

AI coding agents are the most privileged new user on developer machines in a decade: they read source, run commands, and access credentials. And unlike every other privileged user, they’re almost always unaudited. If you had to answer “which API keys did my agent touch this week?” right now, could you?

Why audit logs matter more with agents

Traditional secret access has a human in the loop: a developer runs a command, and the human’s intent is the context. Agents change the equation:

1. Attribution is unclear. A command run by an agent was decided by a model — influenced by its context, its tools, and potentially by injected instructions. “Who accessed this key” needs to include “what the agent was doing at the time”.

2. The blast radius is session-wide. One agent session touches many credentials through many invocations. Without logs, a compromise is invisible until the damage shows up elsewhere.

3. Compliance surfaces. If your setup ever needs to answer “was this secret exposed?” — for an incident, a client, or your own peace of mind — logs are the difference between an answer and a guess.

What good credential audit logs look like

• Structured. JSON lines, not prose. Each event is a record with fields: timestamp, the credential key, the operation (resolve / refresh / scrub), the invoking context, and the outcome.
• Append-only. The log can’t be rewritten by the thing being audited. File-based logs get 0600 permissions and reopen-on-rotation (so logrotate doesn’t drop events); journald is a solid alternative.
• Complete. Every credential resolution is logged — not just failures. The absence of an event is information too.
• Machine-readable. --json output for cron, SIEM, or alerting: “three failed Bitwarden unlocks in a row” should be something you can detect, not something you notice.

What to log

The useful baseline for agent credential access:

• Resolutions — which key was resolved, when, by what invocation. This is the “who touched what” record.
• OAuth lifecycle — login, refresh, reauth_required. Token refresh failures are early indicators of revoked credentials or policy changes.
• DLP hits — outbound pattern matches, with mode (log vs mask). A pattern hit in log mode is a secret that almost left the machine.
• Scrub operations — what was scrubbed, from where. The audit trail for your erasure layer.

The test: can you answer the question?

A good test for whether your agent setup has adequate auditing: an incident review asks “did the agent access the production key during that session?” If the honest answer requires digging through shell history, you don’t have audit logs — you have hope.

trustless writes structured credential audit events (append-only JSONL at 0600, file or journald) for every resolution, OAuth refresh, DLP hit, and scrub — plus trustless doctor --json for setup health in machine-readable form. The audit command is in the command reference.

Agents will keep getting more capable, which means more credentials touched per session. The question isn’t whether to log — it’s whether you want the answer to “what happened” to be a query or a mystery.