Audit everything an AI agent did

Something happened, a file changed, a message went out, a ticket moved, and you need to know which agent did it, acting for whom, and whether a policy let it through on purpose. Agent Trail (Audit log) is the record: every tool call, connection, and policy decision, in order, with the agent and the person it acted for attached. This walkthrough goes from a vague question, "which agent touched this repo," to a specific answer.

What you'll need

• Access to Agent Trail in the console
• Something to narrow by: an agent, a user, a resource, or a rough time window

Steps

1. Open Agent Trail in the console nav.
2. Start broad. Set the MCP filter to the server in question, for example the GitHub resource, to see every tool call made to it across every agent.
3. Narrow further with the Agent filter (every instance of one agent, for example all Claude Code clients) or Agent instance filter (one specific connected client), and the Action filter to separate Tool Executed (gateway.tool.executed) from Tool Failed (gateway.tool.error). The filter lists these human labels — the raw action ids are what the API takes, but typing them into the filter finds nothing.
4. To narrow by person or team instead, use the User and Group filters — the same OIDC groups your IdP sends, and the fastest way to answer "what has this team's tooling been doing."
5. Click an entry to expand it. Each one shows the actor, the action, the resource, and action-specific details, including the tool name and, for tool executions, metadata like IP address and user agent. If the call had content redacted on the way through, a DLP redactions section lists each data-protection rule that fired with its match count, linked to the rule — match counts only, since the matched text is never recorded.
6. For a denied call, look for gateway.tool.error with error_type: blocked_by_policy. When an explicit rule caused the block, the entry names it and links straight to that policy — the fastest path from a blocked call to the rule behind it. The event snapshots the policy's id and name, so the link survives a later rename. A call that matched no rule is denied by fall-through and names no policy at all: the row reads "no policy permits this tool."
7. Expand an agent.connected event to see the three tool buckets from the moment the agent came online: allowed outright, denied outright, and conditionally allowed, meaning the tool is gated by an argument-level condition re-evaluated on every call.
8. To see on whose behalf a call ran, read the person linked on the entry, after the em-dash — not the actor. On a tool call the actor is the agent instance itself; the accountable user rides alongside it on the same entry. Every OAuth connection is per-user, so on a connected resource the agent acts with that person's own credentials; on an API-key or no-auth resource there are no per-user credentials, and the accountable user comes from the authenticated gateway session and is still recorded on the event.
9. Scroll and click Load more to page back through history. The feed loads newest first and scales to large volumes without slowing down.

Mapping audit events into a SIEM? Don't attribute tool calls with actor_type or actor_display_name — on gateway.tool.executed and gateway.tool.error the actor is always the agent, so a rule keyed on those fields will blame Claude Code rather than the person whose access it used. Attribute on the user reference carried in the event's resources instead.

Verify it works

Take a concrete version of the opening question, for example "which agent pushed to this repo last week, and what did it do." Filter by MCP to that GitHub server and Action to Tool Executed, then expand the most recent match — the feed is already newest-first. You should land on one entry naming the agent, the person it acted for, the exact tool called, and enough detail to say definitively who did what and whether it was allowed on purpose.

Next steps

• Analytics — aggregated trends when you need a pattern across many events, not one.
• Policies — the rules behind every allow and deny you find here.
• Track AI token spend by team — pair the audit trail with what that activity cost.