Why Your Audit Trail Starts Too Late

Your AI agent just modified a production database. The SIEM caught it 6 minutes later. The incident report asks: what exactly did the agent do in those 6 minutes? If your audit trail starts at the SIEM, the answer is: you don't know.

That gap — between "agent executes action" and "log system records it" — is where repudiation risk lives. An agent that leaves no trail of its reasoning, its instructions, or its policy decisions cannot be held accountable. And if you cannot hold it accountable, you cannot prove to a regulator, an auditor, or your board that you actually had control over what it was doing.

What is repudiation in agentic AI?

Repudiation risk is the ability of an actor to deny involvement in an action. In security frameworks, it's one of the core threats models (STRIDE), and it matters profoundly for agents.

OWASP's AI Agent Threats guide (T8 — Insufficient Logging of Agent Actions) flags exactly this problem: agents operating without sufficient logging for forensic reconstruction. The risk isn't theoretical. If an agent makes a consequential decision — grant access, move money, execute a deployment, delete records — and there is no immutable record of why that decision was made, how it was authorized, or what policy governed it, then you have a denial-of-responsibility problem.

The agent can claim (via its logs or behavior) that it was following instructions. The LLM provider can claim it was a user instruction, not an agent error. Your security team can claim it wasn't in the policy. Your engineering team can claim the policy was misconfigured. And all of you can be technically correct, because nobody has a complete chain of evidence.

Repudiation risk in agents means: if something goes wrong, you cannot produce an irrefutable audit trail proving what happened, who decided it should happen, and whether it was allowed to happen.

Why current logging isn't enough

Most organizations have two logging systems in place when agentic AI arrives: cloud logs (CloudTrail, Azure Activity Logs) and SIEM (Splunk, Datadog, Wiz). Neither captures what you actually need.

Cloud logs capture API calls after the fact. If an agent makes an API call to your database, AWS logs it — after the call succeeds or fails. But they don't log what the agent was instructed to do, what it decided internally, or what policy was applied before the call was made. The log entry says what happened at the API boundary, not why the agent decided to make that call.

A SIEM correlates events from cloud logs, endpoint logs, application logs, and network logs. It looks for anomalies, detects threats, and alerts on suspicious patterns. But SIEMs are reactive systems. They work on data that has already been generated elsewhere. The event is logged by the system that performed it, then the SIEM consumes that log. By the time the SIEM sees it, the action has already executed, the damage (if any) has already occurred.

The critical gap is the chain between instruction and execution. The chain is:

Prompt instruction → Agent reasoning → Tool call formation → Execution → Result

Most logging starts at "execution" or after. The SIEM catches the API call. The cloud log records the database write. But what was the prompt? What did the agent reason through? What policy was checked? Did the agent even receive authorization to attempt this action? Those details are invisible to traditional logging.

You have logs of what happened. You do not have logs of what was supposed to happen, what the agent decided to do, or how that decision was authorized.

Compliance implications: proving control you don't have

Regulatory frameworks are catching up to agentic AI. SOC2 Type II requires organizations to demonstrate "continuous monitoring and observation of the computing environment." ISO 27001 requires demonstrable evidence of access control enforcement. If an auditor asks: "Show me every action your AI agent took last quarter and the policy decision for each one" — can you produce that evidence?

Most teams cannot. Here is what a typical response looks like:

That conversation is failing because you have logs of execution, but not logs of authorization. SOC2 Trust Services Criteria CC6 (Logical access controls), CC7 (System monitoring), and CC8 (Change management) all require demonstrating that systems behaved according to policy. If you cannot produce evidence that an agent's action was evaluated against policy before execution, you fail the control. You cannot claim control where none was actually exerted.

ISO 27001 Section 8.2 (Access control) requires that "access by users and other entities is restricted in accordance with a business requirement for information security." If you cannot demonstrate that the agent's action was restricted (evaluated against policy) before execution, you cannot claim compliance.

The gap between "we have policies" and "we can prove policies were enforced" is a compliance failure waiting to be found.

What a proper audit trail looks like

A complete audit trail for agentic AI has a very specific structure. Every entry must contain:

• Timestamp: Precise moment the decision was made.
• Agent identity: Which agent attempted the action (not just the service account it runs under).
• Model and version: Which model was used, in case behavior changes across versions.
• Intended action: What the agent asked to do, in full detail.
• Threat category match: What type of action was detected (data access, infrastructure change, credential use, etc.).
• Severity score: How risky this action was considered to be.
• Policy decision: The verdict — allow, deny, or escalate.
• Policy rule matched: Which rule in your policy was evaluated.
• Result: What actually happened — did the action execute, was it blocked, was it escalated?

This log must be append-only and immutable. New entries are added, but existing entries can never be modified or deleted. It must be tamper-evident — if someone attempts to modify the log, that tampering must be detectable. It must be exportable to CSV, JSON, or other formats your auditors expect. And it must be stored outside the control of the agent itself — on infrastructure the agent cannot compromise.

This is what true agent audit logging looks like. Most organizations do not have this today. They have cloud logs and SIEM dashboards and that is not sufficient.

Building vs. buying: the governance layer

You can build this audit trail yourself. Add logging to your agent framework. Write audit entries to a database. Export them to your SIEM. But doing so requires sitting between the agent and the LLM API it calls, intercepting every request and response, evaluating every tool call block, and making policy decisions in real time. This requires infrastructure, operational overhead, and continuous maintenance as LLM APIs evolve.

Alternatively, you can deploy a governance proxy — a service that sits at the network boundary, transparent to the agent, and handles all of this enforcement and logging automatically. The proxy intercepts the agent's API requests, reads the LLM's response, parses the tool call blocks, evaluates each one against your policies, and logs the full decision chain before sending the response back to the agent.

With a proper governance layer in place, you get the audit trail you actually need: every action pre-authorized, every decision logged with full context, and every log entry tamper-resistant and externally stored.

---

The question is not whether you need this audit trail. If you are running agents in production with access to production systems, you need it. The question is whether you want to build and maintain it yourself, or deploy a tool designed specifically for this.

How Intercis closes the gap

Intercis is a governance proxy designed specifically to solve the repudiation risk problem. When an agent calls Claude or OpenAI, the request goes through Intercis first. We read the LLM's response, inspect every tool call block, evaluate it against your policies, and log the full decision — what was requested, what policy rule was checked, whether it was allowed or denied, and why — before returning the response to the agent.

Every decision is written to an immutable, append-only audit log. You can export the full log at any time in CSV or JSON format. Each entry contains the agent identity, the intended action, the policy decision, and the result. When an auditor asks "show me every action your agent took," you have that evidence, with timestamps and decision details, ready to provide.

Integration takes minutes. Point your agent at the Intercis proxy instead of directly at the LLM API, and governance is active. Zero code changes to your agent. Zero changes to your tools.

Starting with evidence

Repudiation risk is not abstract. It is the gap between "something happened" and "I can prove why it was allowed to happen." If that gap exists, your audit trail starts too late. You have logs of execution, but not logs of decision. You have monitoring, but not governance.

The question to ask is: if an auditor, a lawyer, or a board member asks "prove that this agent's action was authorized before it executed," what evidence would you show them?

If the answer is "I don't have that evidence," you have a repudiation risk problem. And it needs to be solved before the incident happens, not after.