initializdocs
AgentsRuntime

Audit events

Every agent emits structured security events - tool calls, egress decisions, quota denials - that surface in the platform's Security area.

Everything security-relevant an agent does is recorded. The agent runtime emits a structured audit event for each notable action — every tool call, every allowed or blocked outbound request, every authentication decision, every quota denial — and streams them to the platform, where they appear in the Security area filtered by organization, workspace, and agent.

What gets recorded

The audit stream covers the full lifecycle of agent activity:

  • Task lifecycle — a session starting and ending, and each model call with its token usage (the basis for usage and cost reporting).
  • Tool activity — every tool the agent invokes, with timing and input/output sizes.
  • Egress decisions — each outbound request, allowed or blocked, with the domain and the policy mode that decided it.
  • Policy and guardrail decisions — content that was masked, warned on, or blocked, and commands denied by organization-wide policy.
  • Approvals — a paused tool call, the human decision (with approver identity), or the timeout.
  • User connections — a per-user tool call parked waiting for its user to connect their account, the resolution when they do, or the expiry when they do not.
  • Admission denials — requests turned away because a cost or usage quota was exhausted at the agent, workspace, or organization level.
  • Authentication — every inbound request accepted or rejected, and by which identity.

Events are metadata by default: tool names, domains, durations, token counts, sizes — not prompt text, tool arguments, or results. Payload capture is a deliberate, per-agent opt-in for debugging or compliance needs, with secret-shaped values redacted. Error text is handled more strictly still: the failure reason recorded on any event (a failed model call, a failed tool) is always scrubbed for secret-shaped values and length-capped, whether or not payload capture is on — an error message that echoes a credential never reaches the stream.

Event naming

Event types follow a <entity>_<verb> shape: the prefix names the thing the event is about, the verb what happened to it. The prefix matters — it encodes where in the pipeline the decision was made.

EventMeaning
tool_execThe agent executed a tool
egress_blockedAn outbound request was stopped by the egress allowlist
egress_allowedAn outbound request passed the egress allowlist
task_admission_deniedA new task was refused before execution because a quota (cost or token limit) was exhausted — with the scope, the window (hourly, daily, monthly), and when it resets
task_deferredA tool call was paused for human approval
guardrail_checkA guardrail masked, warned on, or blocked content
llm_callA model call completed, with token usage and the exact endpoint URL the request was sent to (recorded even when payload capture is off — it is metadata, not payload; any credentials embedded in the URL are stripped before recording)
llm_call_failedA model call failed — a transport error or an error response from the provider or gateway — with the provider, model, and failure reason, so operators can alert on provider and gateway outages without enabling payload capture
mcp_auth_requiredA per-user tool call is parked waiting for the user to connect their account — emitted once per user and service, not per call
mcp_auth_resolvedThe user connected their account; the parked calls resumed
mcp_auth_timeoutThe consent window expired and the parked call failed

For example, task_admission_denied is distinct from a per-tool or per-call denial: the task_ prefix tells you the gate fired before any work started, not midway through a tool.

Correlation and attribution

Every event carries identifiers that make the stream navigable:

  • A correlation ID groups all events of one invocation — the authentication, the model calls, the tool calls, and the completion form a single timeline.
  • Sequence numbers within an invocation let consumers detect missing or reordered events.
  • Workflow identifiers tag events produced during a workflow run, so cost and activity roll up to the specific workflow, stage, and step that caused them.
  • Tenancy fields stamp each event with the organization and workspace the agent is deployed in.
  • Channel attribution — when a request arrives through a chat channel such as Slack, events carry the identity of the human who sent the message, not the channel bot's shared identity, so a tool call traces back to the person who asked for it.

Attribution extends beyond the agent's own process. Outbound requests made by skill scripts and subprocesses through the local egress proxy are stamped with the task and correlation IDs of the invocation that ran them, and take sequence numbers in that invocation's chain — a client that strips proxy credentials is still enforced and audited, just without the identity fields. A per-user consent resolution is likewise recorded exactly once, attributed to the invocation it unblocked.

Events are also chained — each one carries a hash of the previous one — so gaps or tampering in the stream are detectable.

Where events surface

Agents publish their audit stream to the platform, and the Security area is where you consume it: browse and filter security events, see posture rollups such as top quota hits and policy denials, and review usage derived from the token counts on model call events. You do not need to access an agent's logs directly — the platform view is the operational surface.

The complete event catalog, with every field on every event type, lives in the developer section: Audit logging.

On this page