Credential access monitoring: the control auditors actually check

The auditor does not ask how you store secrets. They ask who accessed them, when, and whether anyone was watching. Storage gets all the attention — vaults, encryption, rotation — but the control that actually shows up in a SOC 2 or ISO 27001 walkthrough is monitoring: evidence that access to credentials is logged, reviewed, and acted on. For teams running AI agents on developer machines, that evidence is usually missing.

Why access is the control

The common criteria for logical access require two things: access to sensitive data is limited, and access is monitored. Vaults handle the first part well — their audit trails record every human read. Agents break the second part. An AI agent that resolves API keys and OAuth tokens operates under your existing identity, so the vault sees a session it cannot distinguish from a human one. No separate record exists of which agent touched which credential.

What a credible record looks like

A monitoring record does not need to be elaborate; it needs to be specific and reviewable.

• Resolutions. Which credential was accessed, when, and by which invocation. The credential is identified by name, never by value.
• Failures. Invalid sessions, denied injections, failed unlocks. A credential that stops resolving is often revoked, expired, or under attack — failures are the early-warning channel.
• OAuth lifecycle. Login, refresh, and reauth_required events. A spike of refresh failures indicates revoked tokens or a policy change upstream.
• DLP events. Outbound pattern hits with the mode used. A hit in log mode is a secret that almost left the machine.

Logging is not monitoring

The gap most teams miss: writing events to a file is not a control. A control has a review loop. Someone — or a query — looks at the log on a schedule and acts on what it shows. Three patterns are cheap to define and signal real trouble:

• repeated failed unlocks of the same credential in a short window;
• OAuth refreshes failing across multiple providers at once;
• DLP hits outside expected working hours.

If your log has no reader, it is a file, not a control. An auditor can tell the difference by asking one question: what did you do with the log last month?

Where agents break the pattern

Agent access has a shape that defeats manual review. It comes in bursts — one session can resolve dozens of credentials in minutes, headless, at odd hours. It is attributable to a session that a model influenced, not to a person who decided. And it happens constantly, so volume buries signal. This is why the record needs per-event granularity and machine-readable output: the only realistic way to review agent access is by query, not by eye.

The rehearsal

A useful rehearsal for your next audit: “Show me every credential your agents touched last month, and what happened after each touch.” If the honest answer requires reconstructing shell history, the control does not exist yet. Monitoring is not something you bolt on the week before the examination; it is the evidence trail you build while things are calm.

trustless emits exactly this record: append-only audit events for proxy.inject, proxy.deny, run.spawn, dlp.redact, oauth.refresh, oauth.fail, and oauth.reauth_required, stored at 0600 in JSONL or in journald, with token values never written. The events are documented in the command reference.

When the examiner asks who touched the production key, will your answer be a query or a guess? Have you reviewed your agent access log this month?