Audit Trail
The audit trail records every tool call an agent makes: which tool ran, which integration it touched, whether it read or wrote, what it returned, and — where a governance policy applied — who approved it and why.
Find it in the product under Settings → Audit Trail.
What a row represents
One row is one tool call. Approval decisions are not separate rows; they appear as fields on the call they gated.
| Column | What it shows |
|---|---|
| Time | When the call was made |
| Tool | The tool the agent invoked |
| Integrations | Which connected integrations it touched |
| Access | Whether the call read or wrote — derived from the integration, not guessed from the tool name |
| Approvers | Who approved or rejected, when a policy gated the call |
| Call summary | A short description of what was requested |
| Status | The outcome (see below) |
| Took | Duration |
| Session | The agent session the call belongs to |
Selecting a row opens a detail pane with the full arguments, the output, and an audit block showing the session, the governing policy (linked), and who decided.
Statuses
The status pill folds several underlying states into plain outcomes.
| Status | Meaning |
|---|---|
| Success | The tool ran and returned a usable result |
| Returned error | The tool ran to completion but the target rejected the request — a bad query, an unknown field, or a command exiting non-zero. Not a platform failure |
| Failed | The call did not complete — timed out, was blocked, or the model rejected the result and retried |
| Internal error | A platform or transport fault. The tool never ran, or its result is unreliable |
| Running | In flight; the outcome has not landed yet |
| Needs approval | Paused at a governance gate, waiting on a person |
| Awaiting input | Paused waiting for a human to answer a question |
| Answered | A human answered, resolving the call |
| Rejected | A reviewer denied the call. The tool never ran |
Two grouping rules are worth knowing when reading the counters:
- "Returned error" counts toward Success, not Failed. The tool ran and handed back a real answer; only the target's response was negative.
- The Failed counter covers genuine failures and internal errors, but not rejections. A call a human blocked is its own outcome, not a runtime error.
Filtering and search
Filter by integration, status, and time range. The status counters above the table are clickable and act as filter shortcuts.
Search matches the tool name only. It does not search arguments, output, session titles, or user names. Searching for a hostname, an IAM role, a repository path, or an error message returns nothing even when that activity is in the feed. To find a specific call, filter by integration and time range, then open rows to inspect their contents.
Search is case-insensitive and matches anywhere in the tool name.
Built-in tools are hidden by default
The Show built-in toggle is off by default, which hides tools that run inside the agent itself — bookkeeping such as tracking its task list or recording a hypothesis. These touch none of your systems, and hiding them keeps the feed focused on work that reached your infrastructure.
Anything that resolves to a connected integration is always shown. Sandbox bash is always shown too, because it executes real commands.
While built-ins are hidden, the row counts describe the filtered view. If you are reconciling totals or need a complete record of everything the agent did, turn the toggle on first.
Time range and how far back you can look
The feed opens on the last 7 days. Presets run from the last hour to the last 30 days, and a custom range can be set within that window.
The date picker will not accept dates more than 30 days old. Records older than that still exist — they are simply not reachable from this page. To retrieve them, use the API described below.
Exporting
Download JSON exports the rows matching your current filters, including the built-in toggle state. The export is capped at 5,000 rows; if your filters match more, you get the most recent 5,000 and a notice telling you to narrow the range. There is no CSV export.
The same data is available programmatically from the documented REST endpoint GET /api/v1/tools/call, using a bearer token. The API returns up to 200 rows per request and takes the same filters as the UI. Two differences from the page matter:
- The API has no 30-day limit, so it is the way to reach older records.
- The API includes built-in tools by default — the opposite of the UI. Pass
exclude_builtin=trueto match what the page shows.
See API Credentials for issuing a token.
Retention
Tool call records are kept indefinitely. There is no retention period, no automatic expiry, and no purge control. Records are removed only if the agent session that produced them is deleted.
Scope and access
The feed is organization-wide and shows every user's agent activity. There is no per-user filter; the narrowest scope available is a single agent session.
Viewing requires the tool:read permission, which all three built-in roles hold — Viewer, Responder, and Admin can all read the full audit trail.
Arguments and output are stored unredacted. There is no masking or secret scrubbing. If an agent passes a credential, token, or personal data as a tool argument, it is stored in full and visible to anyone who can open this page. Output is stored up to the first 10,000 characters. Treat the audit trail as sensitive, and scope roles accordingly.
See Roles & Permissions for the full permission model and Governance Policies for requiring approval before sensitive calls run.