Skip to main content

Why 'I Trusted the AI' Isn't an Audit Trail

Audit trails that record AI actions without human attribution don't satisfy governance requirements. Understanding what audit trails actually need to contain.

Published: 2026-03-21

After an incident involving an AI coding tool, the worst thing an engineering team can say during a post-mortem is: "The AI did it."

This answer is increasingly common. AI coding tools can modify files, execute commands, and push changes—and many of these actions leave logs that show the AI's activity without attributing it to a human approver. The result is an audit trail that shows what happened, but not who authorized it.

This is not an audit trail. It is an activity log.

The difference matters

An audit trail answers the question: "Who made this decision and what did they approve?" An activity log answers: "What happened in the system?"

For governance and compliance purposes, the first question is the one that matters. When an auditor asks why a production database was modified, the answer "the AI did it" is not sufficient. The auditor wants to know: who sat in front of the AI, reviewed the proposed action, and clicked approve?

If your audit trail cannot answer that question, it cannot satisfy governance requirements—even if it captures every action the AI took.

What Syndicate Code's event store records

Syndicate Code maintains an append-only event store that records every significant state transition in the system. For each event, the following attribution fields are captured:

  • Initiator identity: The human who initiated the session
  • Approver identity: The human who approved the specific action
  • Actor identity: The AI system that proposed the action
  • Session identity: The session context in which the action occurred
  • Turn identity: The specific turn in which the action was proposed
  • Policy version: The policy rules in effect at approval time

This means that for any recorded action, you can reconstruct: the human who approved it, the AI that proposed it, the arguments that were approved, and the outcome.

The problem with AI-first logs

Most AI coding tools generate logs that look like:

[14:32:15] AI: Proposed edit to auth.go
[14:32:18] AI: Executed edit to auth.go
[14:32:20] AI: Proposed commit
[14:32:22] AI: Executed commit

The human's involvement—the approval decision—is missing. This is because many AI tools implement approval as a notification, not a gate. The AI proceeds regardless of whether the human clicks approve; the approve button is advisory.

When these logs are exported to SIEM systems or reviewed during audits, they show AI activity without attribution. The AI became the actor; the human became invisible.

What genuine attribution requires

Genuine attribution requires that:

  1. Human approval is a gate, not a notification: The action does not execute without explicit approval
  2. Approval is bound to exact arguments: The approver reviews and authorizes specific parameters, not summaries
  3. The approval record is immutable: The approval cannot be retroactively modified or deleted
  4. The event captures the approver's identity: Not just "approval given" but "approval given by [email protected]"
  5. The event chain is continuous: There are no gaps between approved actions and executed actions

Syndicate Code implements all five of these requirements through its control plane architecture.

What Syndicate Code does not do

Syndicate Code's event store provides attribution for actions that route through the Syndicate Code control plane. Actions that bypass the control plane—whether through direct execution paths or tools that do not route through Syndicate Code—are not recorded.

Syndicate Code does not retroactively attribute actions taken before Syndicate Code was installed. The event store records events from the time of installation forward.

Syndicate Code does not provide real-time alerting or automated response. The event store is an immutable record; how that record is used depends on your operational processes.

FAQ

Does Syndicate Code's audit trail satisfy SOC 2 requirements?

Syndicate Code provides audit trail infrastructure for AI-initiated actions. Whether this satisfies SOC 2 requirements depends on the specific Trust Services Criteria your audit program addresses. Syndicate Code's event records include the elements that compliance frameworks typically require: who authorized the action, what exactly was approved, timestamps, and outcome. Consult your auditor for specific compliance questions.

Can audit events be tampered with?

Syndicate Code's event store uses hash-chaining: each event includes the SHA-256 hash of the previous event. This creates a tamper-evident chain—if any event is modified, the hash chain breaks and the modification is detectable. This does not prevent modification by an actor with access to the storage layer, but it does detect tampering that occurs after the fact.

How long are events retained?

Event retention is configured at deployment time. The immutable event store uses SQLite with WAL mode; retention policy is an operational parameter, not a product constraint.

Can the AI modify or delete events?

No. The event store is append-only. The AI cannot modify or delete events through the control plane API. Events can only be added, not altered or removed.

What happens to events when the control plane is offline?

When the Syndicate Code control plane is unavailable (offline or degraded mode), governance controls are not enforced and events are not recorded with standard attribution. This is a documented operational exclusion. Actions that execute during offline mode are not captured in the event chain.