Your AI agent needs an audit trail, not just guardrails

Guardrails vs audit trails

Guardrails are input filters. They check whether an agent should take an action before it happens — budget limits, content policies, role-based access controls. They're essential. But they answer a different question.

A guardrail tells you the agent was permitted to make a purchase under $500. An audit trail tells you it made a purchase of $347.50 for item X at timestamp Y, after considering 3 alternatives, with reasoning Z, on behalf of user W.

When a customer disputes a transaction, a regulator investigates, or an internal review flags anomalous behaviour — guardrails have nothing to say. The event already happened. You need the trail.

The regulatory reality

The EU AI Act doesn't just require that AI systems behave well — it requires that you can prove they behaved well. Article 13 mandates transparency. Article 14 mandates human oversight. Both assume the existence of detailed records.

The enforcement deadline for high-risk AI systems is August 2026. Penalties reach 35 million euros or 7% of global turnover. When regulators ask "show us what your agent did," the answer cannot be "we had guardrails." They will ask for logs. Event logs. Timestamped. Immutable. Complete.

What a proper audit trail captures

An audit trail for AI agents needs to record more than just "action taken." It needs context. A complete audit event includes:

• 01The action itself. What the agent did — mutation type, target entity, parameters.
• 02The context. What session this belonged to, what the human asked for, what constraints were active.
• 03The reasoning. Why the agent chose this action over alternatives (if the LLM provides reasoning traces).
• 04The correlation chain. How this event relates to other events in the same workflow.
• 05Immutability guarantees. Proof that the record hasn't been altered after the fact.

// Reconstruct everything an agent did in a session
const trail = await tes.query(`{
  eventsByEntity(entityId: "ses_7f2a", limit: 100) {
    eventType
    timestamp
    payload
    source
    clientId
  }
}`);

// Export for EU AI Act compliance
const report = await tes.audit({
  jurisdiction: "EU",
  regulation: "AI_ACT",
  session_id: "ses_7f2a",
  include: ["transparency_logs", "human_oversight_events"]
});

Building audit trails with event sourcing

The reason event sourcing works so well for audit trails is that they're the same thing. In an event-sourced system, the audit trail isn't a secondary system that mirrors the primary database — it is the primary system. State is derived from events, not the other way around.

This eliminates the most common failure mode of audit systems: drift. When your audit log is a separate system from your source of truth, they inevitably diverge. Events get missed. Formats change. The audit log becomes an approximation rather than a record.

With event sourcing, there is no drift — because there is no separation. The events are the source of truth. The current state is the projection. The audit trail is a query over the same data.

Both, not either

This isn't guardrails versus audit trails — you need both. Guardrails prevent harm in real time. Audit trails provide accountability after the fact. Together, they form a complete governance layer for AI agents.

The Thing Event System provides the audit trail half. Every agent action is an immutable event. Every event triggers AI enrichment. Every entity has a complete, queryable history.48 event types across 8 categories cover everything from session lifecycle to settlement to compliance.

Guardrails decide what agents can do. Event sourcing records what they actually did. When the regulators come knocking, you'll want both.