Audit log

Monitor and search agent activity through the audit log

In the Agent Authority console this page is labeled Agent Trail.

SecureAuth Agent Authority logs every action that passes through it. The audit log provides a complete, queryable record of what happened, when, and who was involved — the evidence trail behind every policy decision.

Audit log showing tool execution events
Every action is logged with the actor, resource, and outcome

What gets logged

The audit log captures events across the entire gateway:

  • Tool executions — every tool call made by an agent, including the tool name, MCP server, and whether it succeeded or was denied
  • Tool errors — failed tool calls with error type and description
  • Redactions — which response filters redacted a tool response, and how many spans each one matched
  • Agent events — agent creation, updates, revocation, deletion, and a connection event each time an agent starts an MCP session, with client metadata
  • Resource events — MCP server creation, updates, and deletion
  • Policy eventspolicy creation, updates, reordering, and deletion with rule details
  • Connection events — user OAuth connections created, removed, and revoked
  • Data protection eventsresponse filter rule creation, updates, and deletion
  • Tag eventstag creation, updates, and deletion, plus tag assignments to MCPs, tools, and agents
  • Webhook and telemetry events — webhook creation, updates, and deletion; telemetry ingest keys created and revoked
  • Anomaly eventsfindings detected, escalated, resolved, and triaged

Events age out: the audit store keeps three months of history, so pull anything you need as long-term compliance evidence before it expires.

Event details

Each audit log entry includes:

  • Timestamp — when the event occurred
  • Actor — the user or agent that performed the action
  • Action — the event type (for example, gateway.tool.executed, policy.created)
  • Resource — the MCP server, agent, or policy involved
  • Details — action-specific payload (tool name, error type, policy effect, etc.)

Rows with more to show — agent connections, tool calls, and configuration updates that carry a field-change diff — have a chevron; click it to expand a detail panel. (Anomaly rows link to the finding drawer instead.) Agent connection events show three buckets of tools: allowed outright, denied outright, and conditionally allowed — tools governed by an argument-level condition that's re-evaluated on every call against the live arguments. Tool executions show metadata like IP address and user agent.

A tool call whose response was redacted carries a Redacted ×N badge, where N is the total number of spans replaced. Focus or hover it to see the per-rule breakdown. The audit record stores rule names and match counts only — never the redacted text. Expanding the entry shows the same detail inline, plus — for blocked calls — the policy that made the decision. Both link out to the rule that fired: each redaction rule name opens it in Data Protection, and the blocking policy name opens it in Access Policies — the fastest path from evidence to the rule responsible for it.

End users see a narrower version of this feed. Their Activity page is restricted to their own events and to an allowlist of actions — their tool calls, agent lifecycle events, and connections. Detail payloads are stripped, so tool rows stay single-line and the redaction badge reads a generic Content redacted without naming the rules or counts. Administrative changes, and anyone else's activity, are visible only in the full audit log.

Filtering

Use the filter dropdowns at the top of the audit log to narrow the feed:

  • Action — filter by event type. The dropdown lists friendly names rather than the wire values used elsewhere on this page: gateway.tool.executed appears as Tool Executed, policy.created as Policy Set
  • Agent instance — see activity for a specific connected client
  • Agent — roll up across every instance of one agent (for example, all Claude Code clients)
  • User — events attributed to a specific gateway user
  • Group — events from the current members of a user group
  • MCP — see events related to a specific MCP server
  • Agent tag — events from any agent carrying a tag (for example, all prod agents)
  • Resource tag — events on any MCP server or tool carrying a tag

Pagination

The audit log loads events in reverse chronological order. Scroll down and click Load more to fetch older events. The log scales to large feeds without slowdown.

Use cases

  • Debug a denied request — filter by agent and look for gateway.tool.error events with error_type: blocked_by_policy. Each blocked event references the policy that caused the block (id, name, description), so you can identify the responsible policy even if it has since been modified or renamed
  • Review agent onboarding — filter by agent.connected to see when agents connect (the earliest event marks the first connection) and what tools they were granted
  • Audit policy changes — filter by policy.created, policy.updated, or policy.deleted to track who changed access rules and when
  • Prove a response filter is working — look for the Redacted ×N badge on gateway.tool.executed events; the per-rule breakdown names each filter and the spans it replaced, so you can confirm sensitive data never left the gateway
  • Monitor a specific resource — filter by MCP server to see all tool calls made to that service across all agents

Next steps

  • Analytics — aggregated trends instead of a raw event feed.
  • Policies — the rules behind every allow and deny you see logged here.
  • Connections — where connection-created and revoked events come from.

On this page