Audit Logs and Evidence for AI Agent Activity

The platform has separate records for administrative security activity and agent execution. Use the record that matches the question you are investigating.

To send recorded audit events to a SIEM, start with Configure external security. Installation operators configure audit forwarding; optional agent response has a separate setup path. Forwarding does not require halt credentials or full-evidence capture.

Record	Where to find it	What it answers
Organization security activity	Organization administration, Security	Who changed membership, roles, identity, policy, or other security controls?
Agent Audit View	Governance → Evidence → Runs, when enabled	What triggered an agent run, which actions were recorded, and what evidence remains?
Agent chat timeline	Open the agent	What happened in the everyday conversation and work history?

Review administrative changes

Owner, Admin, Identity Admin, Security Admin, and Auditor can view security activity. Filter the event list to the relevant period, actor, or action using the available controls. Inspect the recorded changes and export a CSV when you need a retained review record.

This security ledger records administrative events. It does not include the full contents of agent conversations. Its coverage starts with recorded events; an empty historical period does not prove no administrative change ever occurred.

Review an agent profile

Open Governance → Evidence → Agents and search by current name, UUID, or primary user. Filter by Team or lifecycle. The default directory includes current agents even if they have never produced an audited run. Choose Include archived & historical to include retained identities. Names can change; the agent UUID connects the records.

Owner, Admin, Security Admin, Agent Admin, and Auditor can review profiles when Agent Audit View is enabled. Audit access is independent of chat and settings access. Open chat and Open settings appear only when the reviewer separately has those permissions. The profile does not offer configuration, approval, credential-reveal, or reconnect actions.

Tab	What it shows
Overview	Identity, governing organization and workspace, lifecycle, pending approvals, storage metadata, and recorded inference usage.
Instructions	Current charter, stored skill versions, enabled system skills, saved intelligence preference, and effective routing configuration.
Access & connections	Human access and its source, contact instruction authority, enabled or discoverable tools, blocking policy, saved connections, credentials metadata, machine grants, and peer quotas.
Triggers	Primary and additional schedules, instructions, timezones, firing metadata, proactive setting, webhooks, and event subscriptions.
Data flow	Recorded services, recipients, providers, inbound endpoints, integration operations, and linked file transfers during the selected period.
Runs	This agent's recorded runs, existing evidence drawer, and full-page timeline.
Changes	Recorded configuration changes, actor and source, before/after metadata, and protected instruction evidence where captured.

Current configuration is dated when retrieved. Historical date filters default to the last 30 days and never reconstruct an older configuration. Choose a custom range or all retained history for the historical summaries, runs, and changes. Links retain organization context and review filters; review URLs remain permission checked.

Connection readiness comes from stored configuration. A saved credential does not prove current provider authorization or network reachability. Requested scopes and provider-reported granted scopes are separate; older records may not contain reliable granted-scope evidence. Profile reads do not contact providers, refresh tokens, discover MCP tools, dispatch agents, or read stored file contents.

Recorded inference usage deduplicates model completions referenced by multiple events. Reported and estimated costs are separate, missing values remain unknown, and token totals identify how many completions supplied each value. These facts are not an invoice or a complete provider billing record.

Historical agents and coverage

Archived agents still in this organization may retain a current stored configuration. An agent that leaves exposes only this organization's retained records and its last recorded identity. The destination's current configuration and history are excluded. An agent that returns has a current profile again, while its time elsewhere remains excluded. Deleted agents with only old run snapshots can still be inspected with limited identity details.

The coverage panel separates configuration-capture activation, earliest retained runs and changes, open execution capture gaps, and instruction-evidence availability. Earlier configuration changes may be missing. Activation does not reconstruct old instructions, and platform prompt or deployment changes are not a complete historical prompt ledger.

Configuration instruction evidence

The configuration ledger records changed field names and safe metadata. Before/after instruction text is encrypted separately only when Capture full evidence was enabled at the time. Revealing it requires a reason and creates an access record. Disabled capture, expiry, and truncation are explicit. The current evidence bound is 100,000 characters per before/after value; redaction still applies.

Capture full evidence keeps supported request text, inputs, and outputs, and the content of an action that matched a security rule, encrypted. Only credentials are redacted. That content can include personal identifiers such as national ID, tax, bank-account, payment-card, and health-record numbers, and contact details, so identifier security rules together with full evidence create a store of the very data the rules look for. Metadata, findings, and rule evaluations never contain the matched value; they record only the kind and a count. Set the evidence retention to the shortest period your reviews need, and limit who may reveal evidence.

Configuration metadata follows the organization's security audit retention, including its one-year minimum. Protected instruction evidence follows the dedicated agent evidence retention policy. These are separate lifetimes: a change can remain visible after its instruction evidence has expired. Shortening evidence retention immediately expires and purges affected content; increasing retention cannot recover purged content.

Export a profile

Use Profile export and provide a review reason. The asynchronous bundle captures current configuration at worker generation time and includes the selected historical range. Run filters select runs, then all their events are included for coherent review. Change-domain and change-actor filters apply separately to configuration history.

The versioned profile bundle includes agent-profile.json, configuration-changes.jsonl and CSV, existing run and event files, and a manifest with organization, agent, request/capture times, filters, coverage, redactions, file sizes, and SHA-256 hashes. Owner-authorized full-evidence exports also include available execution and configuration evidence. Existing run-only exports retain their original format.

Permissions are checked when requested, generated, and downloaded. Full-evidence exports require an Owner and an enabled full-evidence policy. Downloads expire after 24 hours. If an agent leaves before generation, its export becomes historical-only. Changing workspaces does not authorize access to another organization's export.

Inspect an agent run

Agent Audit View is available to Owner, Admin, Security Admin, Agent Admin, and Auditor when the deployment enables the feature. Filter runs and open one to inspect its trigger, initiator, outcome, timeline, and recorded risk or coverage information.

Pay attention to coverage quality and capture gaps. Missing or expired evidence should be described as unavailable evidence, not as proof that an action did not happen. Audit records also cannot prove final delivery or processing by every external service; reconcile those outcomes with the provider when needed.

For a longer investigation, choose Open full page in the run drawer. The dedicated run page shows the agent, recorded initiator, start and end times, outcome, and coverage alongside the chronological timeline. Initiated by is shown as Unknown when the record does not identify the initiator; the agent's name is not proof of who requested the work.

Use Load more events until the displayed event count matches the run total. Refresh retrieves updated activity. Back to audit log returns to your filters and, during the same visit, your list position.

Choose Copy link to share a run with another authorized reviewer. The link includes the Organization context and run ID; it grants no additional access and reveals no protected evidence automatically. It can be opened directly or after signing in. Unavailable or expired runs show an unavailable message.

Ask why an event was recorded

Choose Why? on any timeline event to see the recorded path from the request to that event: who asked, which model chose the next step, the action it called, the network request that followed, and the end result. This chain is read from audit records and does not use a model. Why? opens with a one-sentence summary of that chain. When the original request text was not captured, it says so and that the agent's purpose can't be determined; request text is kept only while full-evidence capture is on, and only for new activity. Explain in words requests a concise AI-generated explanation where one can add something. The default explanation uses only the selected event, its matching attempt or outcome, the run trigger, and a small window of surrounding redacted events. It does not read prompt archives, stored model reasoning, or the agent's current configuration. Generation runs in the background through the Organization's judge-model route, or the platform judge configuration when the Organization has not configured one, counts as Organization model usage, and is capped at 2,000 generated tokens per request.

Each explanation labels its basis as Recorded, Reconstructed, or Insufficient evidence, shows confidence, lists up to four contributing factors, cites the audit event IDs and sequence numbers it used, and calls out important limitations. Recorded means a cited field directly states a reason; reconstructed means the service inferred a likely relationship from nearby records. Neither label proves the agent's private reasoning. If the retained records cannot support a cause, the explanation must say so rather than guess.

Metadata explanations are saved and reused for the same event evidence and prompt version. They are derived records and do not modify the event or its integrity hash. Loading, model-unavailable, changed-source, expired-evidence, and invalid-response states are shown explicitly.

New protected email evidence indexes the subject separately from the body. Subject and body passages have independent positions in redacted text and share the existing 100,000-character capture bound and explanation byte budget; subjects can therefore be cited without changing body offsets. Both require the same full-evidence policy, reveal permissions and retention. Large provider subjects can be excerpted, and ambiguous subjects are marked unavailable. Older body-only evidence remains body-only, and enabling capture cannot reconstruct discarded subjects. New explanations use prompt version 8; request a new explanation when an older queued request reports a version change.

When protected evidence exists, authorized reviewers can choose Explain with full evidence and provide a reason. That use is logged. The worker rechecks the requester's Audit View access before using protected evidence. The resulting explanation is encrypted, expires no later than its source evidence, and can be displayed only through a short-lived grant bound to that reviewer and explanation. The browser clears the protected result when that grant expires. A reload or later review requires a new reason; protected explanations are never revealed automatically.

Review data flow

For an organization-wide view, open Governance → Evidence → Data flow. This includes recorded activity across every organization workspace, including retained history for agents that were moved or deleted. Your current Team selection does not limit the audit view. Access uses the existing Agent Audit View roles and deployment feature gate.

The connection map shows up to twelve recorded identities, ranked by how many agents interacted with them. Choose an identity to see its agent relationships, then choose an agent to inspect observations and follow View audit run to the cited event. Back to organization data flow restores the selection. All connections includes every matching identity and is also the mobile view.

Use the search and period controls, or expand More filters for agent, category, direction, outcome, and evidence-source filters. Headline counts cover all matching records. Connection totals are not additive: an operation can involve several counterparties. Provider-reported attempts have a separate count, and internal relationships without recorded direction remain undirected. The map does not establish which content passed through an entire chain.

Capture status and pending organization audit gaps remain visible. Empty results do not prove that no traffic occurred. Authorized exporters can provide a reason and create a filtered Data flow export containing metadata, references, coverage, and checksums. A selected connection or agent relationship narrows the export. Full evidence is not included; downloads expire after twenty-four hours.

Open an agent's Data flow tab to review recorded connections. The default period is Last 30 days; choose a custom range or all retained history. Filter by category, direction, outcome, evidence source, or host/service/recipient.

The Dashboard shows connection, activity, attempt, and reported-upstream totals for all matching records, including records beyond the first page. Its connection map ranks the eight busiest recorded identities by activity count. A connection combines matching categories and directions for the same recorded identity and role; mixed directions are labeled. Select a connection to review its observations and evidence, or choose All connections for the paginated list grouped by category and direction. Expand a list row for observations, file-transfer metadata, and links to the originating audit run.

Line thickness and bars reflect activity counts. Map lines connect the agent to recorded identities; they do not establish a sequence of network hops between providers. Identities that were not recorded remain unknown. Connection counts describe retained records, not a live connectivity check.

An activity is one originating operation. Its attempts include redirects, retries, and follow-up calls. Queued work and policy rejections are not dispatches. One activity may appear under several counterparties, so group counts should not be added together. Reported upstream model attempts are counted separately. The period selects when an attempt first appeared.

Application-recorded, provider-reported, and historically reconstructed evidence are labeled separately. Provider acceptance does not prove recipient delivery. A historical tool request does not prove transmission. Missing identities remain unknown. Configured connections alone do not count as traffic.

Hosts, recipients/channel IDs, and file IDs/counts/known sizes are visible to authorized auditors. The data-flow view excludes URL paths and queries, credentials, headers, message bodies, filenames, and file contents. Browser subrequests, arbitrary sandbox traffic, and activity hidden inside providers are outside coverage. Review Coverage and counting for the retained period's limits.

Agent-profile exports include matching data-flow JSONL and CSV files plus coverage metadata. Data-flow filters apply to those files without changing which complete runs are included in the existing run files.

Review model use

Model decisions and tool actions linked to those decisions show the configured model and provider or gateway, the model named in the response, and the serving provider when reported. Not reported means no serving-provider evidence was retained for that call; it does not confirm which service processed the request. The response model is shown only when its provenance is known, since adapters can replace it with a configured alias. For an action, these fields describe the model that selected the action. A tool may use additional models internally.

Review input, output, cached and reasoning token counts where available, completion duration, cost and its source, and the response's finish reason. Missing usage or cost is unavailable, rather than zero. Model response references includes the completion and response IDs and other reported identifiers. The first streamed chunk measures when streaming began and may arrive before generated text.

Several actions can share one model completion. Their displayed usage and cost refer to that same completion; count each completion ID once when calculating inference totals. Provider-reported and estimated costs describe inference consumption, not the Organization's final invoice. Failed retry attempts and internal browser model calls are not yet a complete part of this model view.

Model metadata is included in audit exports without revealing full prompt or tool content. The audit event retains its captured model facts when configuration changes later.

Full evidence and retention

Owner, Admin, and Security Admin can manage agent audit policy in Governance → Policies → Audit policy; other roles with audit access can review it there. Metadata retention and full-evidence retention are separate settings. Full evidence must have been captured and must still be within retention before it can be revealed. Enabling capture now does not reconstruct earlier payloads.

Revealing evidence is itself recorded. Treat exported or revealed content according to your Organization's handling rules. Shortening evidence retention can remove existing evidence immediately; preserve required records before applying the change.

Protected event explanations follow the same capture switch, role checks, reason requirement, and evidence deadline. Their encrypted output is purged when its source evidence expires. Metadata explanations remain with their parent audit event and are deleted when that event is removed.

Agent audit policy is separate from data retention, which cleans up conversations, execution content, files, browser artifacts, and security activity. Review both policies when planning an investigation or changing retention.

Export agent audit records

Owner, Security Admin, and Auditor can export permitted audit metadata. Admin and Agent Admin exports also depend on the policy allowing administrator exports. Full-evidence export is restricted to the Owner and requires full-evidence capture to be enabled.

Select the time range and evidence option available to your role, start the export, and wait for it to become ready before downloading. Download links expire; create a new export if necessary. An agent migration export serves a different purpose and is not a substitute for an audit export.