Reading the access ledger
Every access request an agent makes through Bursar is written to an immutable access ledger. This article covers what the ledger records, why it's immutable, and how to use it when reviewing agent activity.
What gets recorded
For every access request, the ledger captures:
- Who — which agent's certificate identity made the request
- What — the specific resource or action being requested
- When — a timestamp for the request
- Outcome — whether the request was granted or denied
This is deliberately granular. Rather than logging only successful actions, the ledger also records denials — which turns out to be some of the most useful information in the log, since a pattern of denied requests can be an early signal that an agent is misconfigured, has drifted from its intended task, or is behaving unexpectedly (including, in a worst case, as a result of a compromise or a prompt-injection attack against the agent itself).
Why immutability matters
The ledger is append-only: entries can't be edited or deleted after the fact. This is what makes it useful as an audit trail rather than just a debug log — if you're investigating an incident, you need to trust that what you're looking at is a complete and untampered record of what actually happened, not a log that could have been selectively cleaned up. This mirrors the same audit philosophy used elsewhere on the platform, including Broker's connection audit trail (see Understanding the admin console).
Using the ledger day to day
A few practical ways teams use the ledger:
- Reviewing new agents — after standing up a new agent, check the ledger to confirm its request pattern matches what you expected before broadening its grants.
- Investigating anomalies — an unexpected spike in denied requests, or requests against resources an agent shouldn't be touching, is worth investigating immediately.
- Compliance and reporting — because every request is timestamped and attributed to a specific certificate identity, the ledger can support internal or external audit requirements around AI agent activity.
Where to find it
The access ledger is available from your organization's console alongside the rest of your Bursar-managed identities. If you're not seeing expected entries for an agent, first confirm the agent has successfully obtained a certificate identity (see Installing the MCP client) — an agent that hasn't authenticated yet has nothing to log.
For a broader tour of everything an agent can do once it's connected, see What can Bursar do?.