Audit

Open Audit to inspect activity available to your role and project. The audit API is GET /audit/events; use its supported filters and pagination when collecting a larger history. There is a matching POST /audit/events, which is how the agent records its own tool invocations - the trail is written by the product as it works, not compiled afterwards from logs.

What to look for

Audit events can record the actor or session, tool, time, target, outcome and a bounded description or digest of inputs. Masking runs add reports containing policy and key fingerprints, counts and warnings without embedding raw values in the report.

Start with a run or operation you recognize, then correlate its identifiers with the scenario logs, data job and resulting artifacts. A scenario log describes execution output; the audit trail describes recorded activity. Neither is a substitute for inspecting the actual target result.

Plan decisions

Approving a plan, running it, cancelling a run, running a readiness check, signing one off and deleting a plan are recorded on the audit trail alongside agent activity. The decision that authorizes a write into a customer system is now auditable in the same place as the write itself, rather than only in the plan's own history panel.

Each of these acts targets the plan, runs included, so filtering by a plan returns its whole authorization history in one query; the run id travels in the event's digest. An approval names the version of the specification it accepted, so it cannot be read as blessing a definition nobody saw. Deleting a plan does not erase these events: the record that it existed, and who removed it, outlives the plan.

The actor is resolved on the server. A run started with an API key is attributed to the key rather than to the person who owns it, and an act with nobody behind it - a run the agent finalized itself, or one swept after going stale - records no principal rather than borrowing one.

This is a record of decisions, not a guarantee about their effects. Read it with the run's own result and the target system to establish what an approved run actually produced. See Plans and Approvals.

Investigate a failure

1. Find the relevant time window and project.
2. Inspect the tool or operation and outcome.
3. Check for a missing permission, denied approval, rejected input or target error.
4. Follow the associated run and inspect failed or skipped rows.
5. Retain the reviewed evidence needed by your team.

Do not assume every action in arbitrary Python code is separately audited, or that all sensitive strings printed by a script are automatically redacted. Keep raw values and credentials out of logs.

Retention and export arrangements depend on your deployment. Ask your administrator for the applicable policy rather than relying on a fixed Free/Pro retention table.