Audit trails

Disco Parrot writes down what happened, and it does so in three complementary places. The audit log records discrete events: every change to a record, every agent-authored edit, every action a policy blocked at the sandbox edge, every credential lease granted. Sessions records the full transcript of every agent execution: every message, every tool call, every file edit, alongside the metadata of where the work ran. Version history records full snapshots of each entity at every meaningful save. The three together are the evidence trail, the agent's edits are marked apart from your team's across all of them, and the audit log is exportable as a CSV you can hand to an auditor.

What is recorded

The audit log spans the work, the configuration, and the security boundary. The shape of what lands varies by event type, but the categories are stable:

• Entity lifecycle. Creates, updates, deletes, and restores on initiatives, plans, bugs, projects, portfolios, teams, sprints, goals, key results, and test cases.
• Configuration. Edits to skills, agent instructions, sandbox profiles, environments, MCP server configurations, AI runtime configurations, and workflows.
• Membership and authorization. Invitations, role changes, scope denials, license events, and access-control changes on sandbox profiles.
• AI authoring. Every time an agent writes or edits a skill, an agent instruction, a plan, an initiative, or a sandbox profile, alongside the AI-authored marker on the record itself.
• Credential leases. The full lifecycle of every lease (requested, granted, denied, consumed, completed, expired), with the resource and audience the lease was scoped to.
• Blocked actions at the sandbox boundary. Secrets the platform refused to inject into a container, recorded by name only so the evidence shows the block without leaking the credential. These rows carry the entity type sandbox-secret-policy, so filtering by that type pulls just the blocked attempts when you need them.
• Managed commands. Requests, denials, and completions of named commands the agent ran inside a sandbox.

What an agent did step by step, every tool call and every file edit, is the Sessions story below. The audit log is the right place to answer "who changed what, when, and was it a person or an agent."

Who, what, and the AI mark

Every entry carries an edit source, one of three values: user, ai, or system. A user mark means a person changed the record through the product. An ai mark means an agent wrote the change through a guarded, permission-checked path. A system mark is reserved for the platform itself; the type allows it for scheduled jobs and webhook syncs, but no current emitter sets it, so the practical filters today are Human and AI, with system waiting in the schema for when the platform's own writers start declaring themselves explicitly.

The edit source is the same field that stamps version history, so the audit log and the version history of a given record agree about who or what made a change. The mark is forward-only; entries written before the field existed do not retroactively gain one.

The shape of an entry

Each row records:

• Who. The actor's id and display name.
• What. The action, one of: created, updated, deleted, restored, rejected, denied, assigned, revoked, changed, requested, granted, consumed, completed, expired.
• Which record. The entity type, id, and a human label so the row reads without a lookup.
• What changed. For an update, a small map of the fields that moved, with the before and after values.
• A summary. A one-line human-readable description.
• A content hash. For changes that produced a new version of an entity, the hash of the new content, so you can correlate the audit row with the version it produced.
• When. A timestamp.
• Edit source. The user / ai / system mark above.

Filter, view, and export

The audit log has its own page at Platform → Audit Log, with two views you switch between: AI-authored skills, the default, a focused view on agent edits to your skill library, and All, which is exactly what it sounds like. You filter by source (Human, AI) and by entity type. The list is sorted newest first.

For a lighter, day-to-day read of the same record, the activity feed under Settings shows the workspace's recent changes with avatars, action badges, and the fields that moved. It reads from this same tenant-wide log and is gated by the same audit.read; the difference is that it is built for catching up rather than for export and investigation.

Beyond the global page, every record's detail view carries its own filtered audit feed. Open an initiative, a project, a plan, a bug, or a sandbox profile, and the rows that touched that record are right there, already scoped without anyone setting a filter.

Export

Anyone with the audit-export permission and the audit-export entitlement can export the log to CSV. The button on the page produces a file scoped to your filters, so you can hand an auditor the rows that matter to them instead of a year of everything.

The export is capped at ten thousand rows per file. If a filter would match more, the file contains the most recent ten thousand rows and the response sets an X-Audit-Export-Truncated: true header so an operator wiring an automated export can detect the cap and rerun with a tighter filter. The CSV carries the row identity, timestamp, actor, source, entity type and id, action, summary, and content hash. The per-field before-and-after map stays in the in-product view, where it is easier to read.

Running an export is itself an event the platform records: the action, the filters you used (entity type and source), and the number of rows produced. The export rows themselves are not duplicated into a "someone exported these" record, but the act of exporting is.

Sessions: the transcript layer

The audit log is one half of the audit story. The other half is Sessions, where every chat, Flow run, and background task lands with a full transcript of what the agent actually did. Where the audit log says "the agent updated initiative INI-073 at 10:42," Sessions says exactly what the agent typed, which tool it called, the parameters it passed, the file edits it produced, how many turns it took, and what it cost.

Every session is captured with the metadata that describes where it ran:

• The sandbox the work happened in, with its isolation key and the profile it launched from.
• The AI runtime powering it: the provider, the model, and the configuration that resolved at run time.
• The repository and branch the agent had checked out, and the pull request the work ended up on, if there was one.
• The entry point: whether the session was opened in the web app, attached from the VS Code panel to a running sandbox, or scheduled as a Flow step on the platform's run scheduler.
• The MCP connections that activated for the run and the AI spend broken down by model, by turn, and per call.

The transcript captures file edits at diff-fragment level: the path, a small window of context, the before text, and the after text the agent wrote. A credential-redaction pass runs over these payloads before they are persisted, so a token that flashed through the work for a moment is recorded by its name rather than its value.

The right answer to "what did an agent actually do on this initiative" is to read the session. The right answer to "did anyone change this record between Monday and Thursday" is to read the audit log. Both records carry the same user, ai, or system edit-source tag, so a row in either record is honest about who acted. The two records do not link to each other today: an audit row does not point at the session that produced it, and a session row does not point at the specific audit entries it produced. You correlate them by the AI mark and the initiative or plan the work was about.

The three records, side by side

The audit log is one of three complementary records the platform keeps about your work. Each answers a different question, and each is needed for a different reason.

The audit log records what changed. Sessions records how it happened, step by step. Version history records what each entity looked like at every save, so a restore returns to the same state rather than an approximation. The audit log without sessions cannot tell you what the agent's reasoning looked like; sessions without version history cannot bring an entity back to a prior state; version history without the audit log cannot tell you who made the change. The three together are the evidence.

Restoring a version is non-destructive: the platform writes a new version row, marks it as a restore from the chosen prior version, and records the restore as its own audit entry, with the version number that was restored from on the entry itself. Nothing is overwritten, and nothing is lost. Reviewable autonomy covers how the three records work together.

Retention

Audit entries are retained for a year by default, with the platform enforcing a per-container time-to-live on the records so anything past its retention is removed automatically. A separate security event stream carries the platform-level boundary events (policy denials, key blocks) for the operator side of the platform, with its own retention contract the platform enforces. The two are designed to agree on the facts: the audit log is the tenant-facing view sized for everyday operations, and the security event stream is the operator-facing view that meets the retention agreements your security team needs. For workspaces that need a longer compliance archive than the audit log carries, the security event stream is the channel to wire into your archive of record.

Who can read and export

The shipped admin roles (Admin, Owner, BillingManager) carry both audit.read (view the page) and audit.export (download the CSV). The other built-in roles (Member, Viewer, Lead, Planner, Workspace Operator) do not see the audit log at all. The export specifically also requires an entitlement, which depends on your plan; the button is hidden when the entitlement is absent so people do not run into a 403 they cannot explain.

Why it matters

For your team, the audit log answers "who did that and when," fast. The AI mark means an agent's edits never blend in with your team's, so a record changing on its own is never a mystery. When you need the step-by-step instead of the headline, Sessions carries the full transcript: every message, every tool call, every file edit, plus the metadata that says where the work ran.

For security, compliance, and audit, the three records are the evidence trail an enterprise needs. Every meaningful change is captured with its actor and a source mark, agent work is enumerated apart from human work, blocked credential attempts and granted credential leases are recorded, the audit log is exportable to CSV, version history is restorable, sessions carry the agent's actions in detail with credentials redacted, and the platform manages retention. The governance view of all of this, what you can attest and the security-evidence pipeline behind it, is audit and evidence.