Audit

Open Audit to inspect activity available to your role and project. The audit API is GET /audit/events, and 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.

The read API is deliberately small. It takes two query parameters, chatId and limit; limit defaults to 50 and is capped at 200. There is no pagination and no cursor, so the newest events are all it will hand back, and a longer history has to be collected as it accumulates rather than paged out afterwards. Results are already narrowed to the credential's team, and to its project when one is in scope. Any other query parameter is accepted and ignored rather than refused, so a filter that appears to have been applied may not have been: check the events you got back before concluding a narrowed query worked.

The agent records its tool calls for every role, including Members, Business users and read-only API keys. Recording needs audit:record, which every role and every API key role holds and which grants nothing else; reading the trail still needs audit:read. The server stamps who made the call, and in which team and project, from the session or key, so a caller can only add events about themselves and can never change or remove an existing one. Without audit:write a caller can only record the kinds of event the agent records; the events the product writes itself, such as input set pulls and plan decisions, cannot be posted this way. If an event cannot be written, the tool call still completes and the failure is reported to the deployment's error tracking.

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 a plan's whole authorization history shares one target rather than scattering across run ids; the run id travels in the event's digest. The API cannot filter by that target, though - see the parameters above - so read a window of events and select the plan's own yourself. 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.

Template edits

Creating a template, saving a change to it - a renamed template, an added, removed or retyped field - and deleting one are recorded on the audit trail. A template is the definition every later generation runs from, so the change of shape is now auditable in the same place as the generations that followed it.

Each act targets the template, so a template's whole authorship history shares one target. The event names what changed as field names and types; it never carries generated values or a field's options. A save that both renames the template and changes a field is one event, not two, with the previous name recorded alongside the new one. Deleting a template does not erase these events: the record that it existed, and who removed it, outlives it.

Not only the template editor. A sheet created from columns mints the template behind it, adding a column to a sheet appends a field to its template, deriving a template from a connection's entity creates one, and installing a pack creates one per template it carries. Each of these is recorded, and the event says which route it came from.

A save that changed nothing is not recorded. The editor autosaves while you work, and filing a row for every autosave would bury everything else on a page that shows the 200 most recent events.

Some changes can be reported only as "the fields changed" rather than named one by one - editing the children of a nested field, or changing a generator's options. The event still says the fields moved, so an event that names nothing specific never means nothing happened.

Two things are deliberately not recorded, so their absence is not a gap to investigate. Template folders are organisation - deleting one leaves its templates in place, at the top level - and reordering templates in the catalogue changes display position only. Neither can change what a generation produces. Moving a template into a folder from the editor is noted on that save, since it arrives with it.

As elsewhere, the actor is resolved on the server: an edit made with an API key is attributed to the key rather than to the person who owns it.

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.