AI Agent Audit Trail
A tamper-evident, append-only record of what an agent did: the policy decision, the timestamp and the threat context. It is not tamper-proof.
- Measured: 40 of 47 payloads, our own corpus
- Not measured: latency
- Observed, not governed: hosted MCP tool calls
What it is
An audit trail is a log of the actions an agent takes, with the decision beside each one. Each entry captures: the agent identity, the action attempted (tool call), the policy verdict, the policy rule that matched, and the timestamp.
Critically, the audit trail is append-only and tamper-evident. New entries are added, and altering or deleting an existing entry is detectable, so long as whoever did it cannot also recompute every record chained after it. This is typically enforced by writing to a system the agent process doesn't control: a dedicated audit log service, a write-once storage system, or an external compliance database.
Why it matters
Two reasons: forensics and compliance. If something goes wrong, the audit trail provides a complete record of exactly what the agent attempted, in what order, and what policy decisions were made. This is essential for incident response: did the agent attempt the deletion or was it the human operator?
For compliance, an auditor asks you to show that a control was in force, not to describe it. An append-only, hash-chained trail is that kind of record. Read the criteria you are being audited against; we are not quoting them, and Intercis itself is not SOC 2 or ISO 27001 certified.
How it works
When the proxy makes a governance decision, it logs the decision on a best-effort basis: agent ID, action details, policy rule applied, decision, timestamp. The write never blocks the agent, so a failed allow or observe write is dropped and a deny record falls back to a local spool. The log entry is written to a system outside the agent's trust boundary, so a compromised or misbehaving agent cannot modify the audit log it doesn't control.
The logs are queryable and exportable. For forensics, you might ask: "What did agent-trading-bot attempt between 3pm and 4pm?" For compliance, you pull the window an auditor asks for.
How Intercis implements it
Intercis maintains an append-only, hash-chained audit log of proxy interception events. Each log entry includes: agent ID, tool call content, verdict, policy, timestamp, and a per-row SHA-256 event_hash that chains each entry to the one before it. The log is tamper-evident — entries have no UPDATE or DELETE path and each is hash-chained, so the agent process cannot alter entries it didn't write, and edits to written rows are detectable, unless whoever made them can also recompute every hash after them. Anyone holding database-owner rights can do that, or drop the newest rows, and nothing outside the database anchors the chain to catch it. Logging is best-effort, so the log is not a guarantee that every event is present.
The log is queryable from the dashboard, and the event view exports the currently-filtered records to CSV. SIEM integration and scheduled SOC 2 submission packages are not available today.
Related terms
What Intercis does not govern
Intercis judges the tool calls that cross the Anthropic and OpenAI API wire. When a hosted MCP server runs a tool for the model, that call has already run by the time the response reaches the proxy, so it is observed, not governed: it writes one observe row and is never judged or blocked. Being in path is also a configuration setting: a process that can change its own base URL can route around the proxy unless network egress control forces the traffic through it.