Audit & governance
For the security or compliance owner who needs to answer: what did the agents do, who approved it, and can I prove it later?
The write path is the headline
Section titled “The write path is the headline”Every governed write produces a receipt — what changed, proposed by which agent, approved by whom, when — and the audit trail is hash-chained, so tampering is evident. Read agents are structurally unable to mutate systems; irreversible actions always require human approval, enforced in code. That architecture is described in How your data is handled; this page covers the operational audit surface around it.
What gets recorded
Section titled “What gets recorded”Activity events across the platform surfaces, including:
| Event | Fires when | Captured |
|---|---|---|
| Session initialize | A coding agent opens an MCP session | Client info, source (e.g. claude-code, cursor), team/workspace identity |
| Tool call | Any Data Workers tool is invoked | Tool name, argument hash (never argument contents), latency, status |
| Auth failure | Bad, expired, or revoked credential | Source and install identity; repeated failures from one install are flagged to your onboarding engineer |
| Key rotation | A workspace/team key is rotated | Acting admin, old/new key hashes |
| Governed write | An agent changes something | The full receipt: change, proposer, approver, timestamp |
Consistent with the telemetry commitments: argument contents, query results, schemas, credentials, and PII are never in the audit stream — hashes and metadata only, except governed-write receipts, which live in your workspace.
Retention
Section titled “Retention”Audit retention is 13 months by default; longer retention windows and residency requirements are agreed in your Enterprise order form rather than promised here. Exports (CSV) are available through your onboarding engineer during the pilot; self-service export in the console is part of the research-preview surface and labeled accordingly there.
How policy is enforced
Section titled “How policy is enforced”Role policy is enforced server-side on every call, driven by your IdP group mapping — which is why it holds even for clients whose team config can’t express per-role rules. Client-side controls (Claude Code permission rules, Cursor team locks) layer on top for defense in depth, not as the only gate.
During your pilot
Section titled “During your pilot”Ask your onboarding engineer for an audit export in week one and again before the conversion conversation — reading your own trail is the fastest way for a security team to confirm the write-safety story is real, and it’s evidence the pilot decision can cite.