The Governance Log

The audit log has always recorded what happened. Every proxied request produced an entry: timestamp, credential reference, endpoint, status code, duration. Accurate, append-only, structurally incapable of containing a credential value.

What it did not record was the state under which things happened.

That distinction matters more than it sounds. A log that tells you STRIPE_KEY was used to call api.stripe.com at 14:22 is useful for operational monitoring. A log that also tells you which agent made the call, what the domain allowlist contained at that exact moment, and what role the caller held can answer questions you have not thought to ask yet.

That is what the governance log is.

What changed in v1.1.1

Every log entry now carries three pieces of information that were not there before.

Agent identity. Which agent made the call, at what identity level, and if issued identity was used, which specific token. This is covered in depth in Part 10. The short version: the log now has a name on every entry, and for issued identity that name is cryptographically verified.

Allowlist snapshot. The domain allowlist as it existed at the exact moment the call was processed, not as it exists today or as it existed when the project was created, but as it existed when that specific call went through the proxy.

"allowlist_snapshot": {
  "domains": ["api.stripe.com", "api.sendgrid.com"],
  "captured_at": "2026-03-07T14:22:01.330Z"
}

Caller role. The workspace role of the user or service account whose session the proxy was running under at time of call. Admin, member, or service.

None of these fields existed in the previous log schema. All three are present on every entry from v1.1.1 forward.

Why the allowlist snapshot is the most important addition

The allowlist is the domain-level security boundary. A call to an unauthorised domain is blocked before credential resolution happens. But the allowlist changes over time, with domains getting added, removed, and modified. A log entry that says "this call was made to api.stripe.com" tells you the call went through, but it does not tell you whether that domain was specifically authorised at the time, or whether the allowlist that existed then looks anything like the one that exists now.

The snapshot closes that gap permanently. Every log entry carries an immutable record of the allowlist state at the moment of the call. If the allowlist changes tomorrow, every historical entry still reflects exactly what was permitted when each call was made, with no inference required.

This is what makes the log forensically useful rather than just operationally useful. If something goes wrong and you need to reconstruct what the system was doing and what it was permitted to do, the log gives you both answers.

What the full entry looks like now

{
  "id": "log_01HXYZ...",
  "timestamp": "2026-03-07T14:22:01.334Z",
  "workspace_id": "ws_01HABC...",
  "project_id": "proj_01HDEF...",

  "agent_id": "billing-tool",
  "agent_token_id": "agt_01HGHI...",
  "identity_level": "issued",

  "credential_ref": "STRIPE_KEY",
  "injection_style": "bearer",
  "target_domain": "api.stripe.com",
  "target_url": "https://api.stripe.com/v1/charges",
  "method": "POST",

  "status_code": 200,
  "duration_ms": 143,

  "redacted": false,
  "resolution_path": "local",

  "allowlist_snapshot": {
    "domains": ["api.stripe.com", "api.sendgrid.com"],
    "captured_at": "2026-03-07T14:22:01.330Z"
  },

  "caller_role": "member",

  "error": null
}

There is still no value field, and the schema has no column for a credential value regardless of what the proxy code does.

Querying the new log

The CLI gains new filter options that make the governance data immediately accessible.

# Everything a specific agent did
agentsecrets log list --agent billing-tool

# All calls where identity was not set
agentsecrets log list --identity anonymous

# All calls that were blocked at the proxy layer
agentsecrets log list --failed

# Export for compliance review
agentsecrets log export --format csv --since 30d

The summary command gives aggregate statistics without paginating through raw entries:

agentsecrets log summary --since 7d

This returns total calls, breakdown by identity level, breakdown by agent, breakdown by credential, and breakdown by domain. Useful for understanding what the system has been doing at a glance and for spotting patterns that warrant closer inspection.

What this is building toward

The governance log as it stands in v1.1.1 captures identity, policy state, and call outcome on every entry. That is the data foundation.

What sits above that foundation — session binding, capability contracts, replay with full policy context — requires this data to exist and to be consistent across every entry. The governance layer cannot be retrofitted onto a log that does not have the right fields. It has to be designed in from the start.

These fields are designed in. Every call made after upgrading to v1.1.1 produces a record that is forward-compatible with everything the governance tier will do, which means records written today will not need migration when session binding ships.

AgentSecrets is open source and MIT licensed. The full architecture is at agentsecrets.theseventeen.co. The repository is at github.com/The-17/agentsecrets.