AI Agent Audit Log Integrity: Is Append-Only Enough?

After an AI agent does something it shouldn’t have, the first artifact anyone asks for is the log. Auditors ask for it. Customers ask for it. Your own incident lead asks for it. The uncomfortable follow-up question is rarely “do you have logs?” but “how do you know this log is complete, and that nobody changed it?”

An AI agent audit log is the per-call record of which agent called which tool, with what authority, and what came back. For agentic AI the integrity question has teeth. Agents call tools at machine speed, often through MCP or A2A, and the log is the only way to reconstruct what happened after the fact. If it is missing rows or editable by the same system that made the mistake, it is a diary, not evidence.

This post covers what an agent audit trail has to contain, the four ways it quietly fails, and how to design for integrity without overclaiming.

What a useful agent audit record contains

A line saying “POST /payments 200” is not enough. For each agent action you want to answer five questions later:

Who acted? The agent principal, and the human it acted for.
What did it call? Tool name, method and upstream host.
With what input? Ideally a hash of the arguments, so you can prove two calls were identical without storing sensitive payloads.
With what authority? Which credential references were used (never the values), and which approval or signed request authorised it.
What came back? Upstream status, latency and any error.

Fullmakt’s broker audit entry records exactly these fields: principal, tool, method, upstream host, a SHA-256 hash of the canonical arguments, the credential references touched, upstream status, latency, and the signed envelope that authorised the call when one was used. Secret values are never written. The reasoning is in why audit logs should never hold the secret.

Four ways agent audit logs fail

Gaps from the side door. If an agent can reach an API without going through your gateway, that call is not in the log. This is the core of the shadow AI agents problem.
Lossy pipelines. Logging done asynchronously can drop rows under load or during shutdown. A full buffer that silently discards events looks fine until the one event you needed is gone.
Mutable storage. Anyone with write access to the table, including the application’s own database role, can edit or delete history.
No link between decision and action. A log that records the call but not the approval, policy decision or signed request behind it cannot prove the call was authorised. See signed task envelopes.

Design rules for audit integrity

Log at the choke point. Put the write on the one path every agent call must take, so completeness does not depend on each agent behaving.
Never drop on backpressure. If you buffer writes for speed, fall back to a synchronous write when the buffer is full, and drain the buffer on shutdown.
Separate the writer from the editor. The service that appends entries should not be able to rewrite them. Enforce this in database permissions, not in convention.
Ship a copy elsewhere. Stream or export entries to storage the application cannot modify, such as write-once object storage or your SIEM.
Record the authority, not just the action. Store the principal, the credential reference and the approval or envelope identifier together.
Alert on the log itself. Rules on spikes, denied calls or unusual hosts turn the log from a record into an early warning. This links to runaway spend caps and kill switches.

How Fullmakt approaches it

Fullmakt is a credential broker for AI agents. Agents connect over MCP or A2A, and every brokered call passes policy and is audited.

One choke point. Broker calls are audited where they execute, so coverage does not depend on the agent. Calls an agent makes around the broker can be reported through a side-channel endpoint and are flagged as externally reported, so you can see the difference between brokered and self-reported activity.
Queue capacity never drops a row. The audit writer can run in the background for throughput (Broker:AuditWriteMode; the default is synchronous). When its queue is full or the host is shutting down, the broker writes synchronously instead, and the queue is drained before stop. Audit is best-effort on write failure: a failed database write is logged and does not block the call, so monitor those errors.
Hashes, not payloads. Arguments are stored as a canonical SHA-256 hash and credentials as references, so the log is useful without becoming a second place secrets can leak.
Alert rules and a live timeline. Declarative alert rules run against recent entries and can notify by webhook or show a banner in the web app, and an audit timeline and summary are available for review.

Honest limits: audit entries are append-only by application convention, and they are deleted when a sandbox account is cleaned up. There is no cryptographic hash chain in the product today. If your auditors require tamper-evidence, restrict the database role so the application can insert but not update or delete audit rows, and export entries to immutable storage. Allow for the sandbox cleanup job in those permissions. Treat the broker log as the authoritative source and the export as your integrity anchor.

The business case

Audit evidence is what turns “we think the agent behaved” into “here is what it did.” That has direct commercial value:

Faster security reviews. Enterprise buyers ask how you log and review agent actions. A per-call record with authority attached answers it in one page. See audit controls for SOC 2.
Shorter incidents. With attributed, complete records, forensics takes hours rather than days. See incident forensics.
Regulatory readiness. Logging and traceability obligations under the EU AI Act and ISO 42001 are far easier to meet when the record already exists.
Less to build. A durable, secret-free audit pipeline is real engineering. Compare it in build vs buy for an agent credential proxy.

Checklist

[ ] Every agent call passes through one logged choke point.
[ ] Records include principal, tool, host, argument hash and credential reference.
[ ] No secret values or raw payloads in the log.
[ ] Buffered writes fall back to synchronous writes instead of dropping.
[ ] Application database role cannot update or delete audit rows.
[ ] Entries are exported to storage the application cannot alter.
[ ] Alert rules exist for spikes, denials and unknown hosts.

FAQ

How do you make an AI agent audit log tamper-evident? Restrict the database role so the application can insert but not update or delete, export entries to write-once storage, and optionally hash-chain rows.

Why can an agent audit log lose rows? Side-door calls that skip the gateway, buffers that drop on overflow, and swallowed write errors. Fall back to synchronous writes and alert on failures. What should an AI agent audit log contain? The acting principal, tool and upstream host, a hash of the arguments, the credential references used, the result, and the signed request that authorised the call. Never the secret values.

Is an append-only log the same as a tamper-proof log? No. Append-only by convention relies on the application behaving. Tamper resistance needs database permissions that forbid edits and an export to immutable storage.

Does Fullmakt use a blockchain or hash chain for audit entries? No. Entries are append-only by application convention. Use restricted database roles and an export to write-once storage if you need tamper-evidence.

Can an agent bypass the audit log? Not through the broker. An agent that calls an API directly is outside it, which is why scoped credentials held by the broker, rather than the agent, matter.

Does Fullmakt support MCP and A2A? Yes. Agents connect over MCP or A2A, and every call passes policy and is audited (best-effort on write failure).

What does Fullmakt cost? Usage-based pricing per operation, with no plans or minimums, plus a no-card sandbox for trying it with your own agents.