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 is the R in 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 record of why that decision was made that the agent could not have written itself, 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

Two logging systems are usually in place before the first agent arrives: cloud logs (CloudTrail, Azure Activity Logs) and SIEM (Splunk, Datadog). Neither holds what you need here.

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

Logging usually starts at "execution" or after. The SIEM catches the API call. The cloud log records the database write. What policy was checked before it, and whether anything checked one, is not in either log.

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

SOC 2 and ISO 27001 work both come down to showing that a control was in force and that you can prove it after the fact. We are not quoting either document here; read the criteria you are being audited against. 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?

Ask what policy was evaluated before the call and what the result of that check was, and the CloudTrail entry cannot answer either. It holds the call, at a timestamp, and nothing about the decision in front of it. The gap between having a policy and showing it was applied is the gap an auditor asks about.

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.
• Category matched: What kind of action it was (data access, infrastructure change, credential use).
• Policy decision: The verdict: allow, deny or observe.
• Policy rule matched: Which rule was evaluated.

This log must be append-only. Entries are added; the client roles hold no UPDATE and no DELETE on them. It must be tamper-evident, so that an edit which does not also recompute everything chained after it is detectable. And it must be written somewhere the agent process cannot reach.

We do not know how many teams log at this level, because we could not find a number. Cloud logs and SIEM dashboards do not carry it.

Building vs. buying: the governance layer

You can build this audit trail yourself. Add logging to your agent framework, write entries to a database, forward them to your SIEM. Doing it properly means sitting between the agent and the LLM API, reading each response, judging each tool call before the runtime can act on it, and keeping that working as the provider APIs change.

The other route is a proxy between the agent and the provider API. It reads the response, parses the tool call blocks, evaluates each one against policy, and writes the decision before the response goes back to the agent.

What you get is one row per call the proxy sees, written before the agent runtime can act, hash-chained per tenant in our database, and tamper-evident rather than tamper-proof.

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 each tool call block, run the deny list over it, and log the 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 governed decision is written to an append-only audit log, hash-chained per tenant. That makes an edit detectable, not impossible: anyone holding database-owner rights can rewrite rows and recompute the hashes, or drop the newest rows, and nothing outside the database anchors the chain to catch it. Each row holds the agent identity, the tool and a short excerpt of what it carried, the policy that matched and the verdict. The rows sit in our Supabase database and are queryable from the dashboard.

Point your agent at the Intercis proxy instead of at the provider API and governance is active. That is one line of configuration; nothing else in your agent changes.

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.