AI agent governance and the AI agent audit trail

For a team, control and accountability are one question asked in two directions. Who is allowed to do what, in which scope, and what actually happened, in which scope. Causal answers both from the same place: the experience an agent was served is a record in the graph the rest of the team reads.

What does AI agent governance cover?

On the enterprise tier:

• SSO, SAML, SCIM, RBAC, and retention policies. Identity comes from the directory you already run, and access to the graph is governed by role rather than by workspace membership.
• Private VPC deployment, or the same service as a docker compose in your own cloud. Licensed to run wherever your data has to live.
• Bring your own tenant keys, data residency, and crypto-shred deletion.
• Verifiable memory commitments — signed heads, inclusion proofs, and verifiable export, so consistency and inclusion are owner-verifiable rather than asserted.

Read windows are set per contract on enterprise; self-serve plans carry a fixed sustained window. Retention policies are an enterprise control, and what they can express is not yet published.

Everything below the enterprise tier still gets the properties the product is built on: memory encrypted at rest and in transit, every write signed, and the whole graph exportable in an open format. Verification is not a paid add-on.

This is a control surface over the harnesses your team already uses, not a platform to migrate onto. Causal registers as an MCP server and a project rule inside Claude Code, Cursor, Codex, OpenClaw, and Hermes, and the connectors reach Slack, GitHub, Jira, Linear, Notion, Salesforce, and SAP. The governance boundary is drawn around the graph, so it holds across all of them at once rather than per tool. Agent memory with integrations covers what each connector ingests.

Who can see what in a shared graph?

The graph is pooled across every agent, tool, and project on a team, and scoped to each role. One agent's outcome is available to the next one that needs it, and a role that should not see a department's work does not get it served.

Pooling is the point of the product, not a side effect. An order desk's incident is what stops a warehouse agent from repeating the mistake, and a support fix that stopped working has to retire everywhere at once. A graph partitioned per tool would leave each agent learning the same lesson separately.

Pro and Pro+ take unlimited teammates and unlimited dashboard viewers, with no seat fee. Causal meters the memories agents write, not the people who read them, so widening read access across a team costs nothing.

Causal never sees your data, never sells it, and never trains models on it. Memory is encrypted at rest and in transit. Encryption algorithms and key sizes are not published.

What is an AI agent audit trail?

Every memory has a receipt. Ask any agent why it acted, and Causal rebuilds the trail from the same graph the agent reads — the precedent it was served, what superseded what, and the signed source events underneath. Recall and audit run over the same graph, so reconstruction is a query against memory rather than a forensic exercise across transcripts and tool logs.

The receipt is a derivation. An experience is never asserted on its own; it comes from the cause and effect beneath it, each still in the graph and still reachable. The path from a served lesson back to the work that produced it is recorded before anyone asks.

Source events do not have to come from the agent's own work. Connectors bring experience in from the systems the work happened in, and what they capture has the same shape: what was chosen, what happened, why, and what to do next time. A reverted pull request. A ticket that reopened the day after it was closed. A renewal that stalled on unresolved escalations. Those events sit under the trail as evidence, alongside the decisions the agent made itself.

How do I audit what an AI agent did?

Ask the agent. Take an auditor asking why an agent blocked a payout. The example below shows the shape of the answer; it is not a real record. The trail comes back with the reason: the vendor's bank details changed two hours before release. Underneath it, three rows.

• served — the precedent that reached the decision. An earlier payout to spoofed details, with the loss it caused.
• superseded — what was retired, and what retired it. "Vendor verified," retired when the details changed.
• signed — the source events underneath, each one signed. On enterprise deployments they also carry inclusion proofs.

The trail is what the agent was working from at the moment it acted. The served row names the precedent that was reused, so "why did my AI agent do that" resolves to a specific prior outcome rather than to a window of activity around the decision.

The same query works over a longer stretch of agent activity. Prior decisions come back with the outcomes they caused, which is what makes a change in behavior inspectable: you can see which lesson was serving during which period, and which one displaced it.

When a lesson is superseded

It is retired, not overwritten. The old experience stays in the graph with its history intact, and the record shows what replaced it and when. Supersedence is resolved at write time.

Erasing a stale lesson would destroy the evidence that it was ever served. In the payout example, "vendor verified" was true when it was written and wrong by the time the payout came up, and the agents that acted on it in between did nothing anomalous. An audit that cannot see the retired lesson cannot explain them.

Supersedence is also how a contested write is settled: a write that claims to overturn corroborated experience is adjudicated against the evidence behind it. Security and memory integrity covers that adjudication, along with quarantine and taint propagation.

Can I verify the graph without trusting Causal?

Every write is signed, so tampering is provable. The whole graph exports in an open format, and the standalone causal-verify verifier checks that export offline. The SDKs, the MCP server, the node and export format, and causal-verify are open source; the engine that turns raw agent activity into adjudicated experience is not.

Enterprise deployments add verifiable memory commitments: signed heads, inclusion proofs, and verifiable export. The export is also the exit — the file an auditor checks is the one you keep if you stop using Causal.

The command-line interface for causal-verify, the export format, and the construction behind signed heads and inclusion proofs are not yet published.

Where governance and the audit trail meet

A scope that governs who may read is the same scope an auditor asks about afterwards. Because access is granted by role over one graph, and the trail is rebuilt from that graph, the question "who was allowed to see this" and the question "who acted on it" resolve against the same record. At team scale the mechanism is unchanged: a logistics agent asking why a shipment is on hold gets the same rows, drawn from decisions another team's agent wrote under another team's scope.

How do I remove data?

Any memory, or the whole account, can be deleted whenever you want. On enterprise, crypto-shred deletion and residency constraints are configured per deployment.

For a lesson that turned out to be wrong, the default is supersedence rather than deletion. The window in which agents acted on a now-retired lesson is usually the part of the answer a reviewer wants.

Compliance frameworks

GDPR, CCPA, and HIPAA. Causal makes no certification or attestation claim against any of them.

Enterprise governance controls — residency, retention, deletion — are handled per deployment rather than by a single published policy. If your review needs a specific configuration, that is a conversation about the deployment.