Audit Trails Log What Agents Send. Almost None Verify What They Receive.

Every production MCP integration logs tool calls. The agent sends a request; it gets recorded. What almost no system logs — with any cryptographic binding — is what came back.

This is not a minor gap. Agent behavior is driven by responses, not requests. When an agent decides to send an email, update a database record, or escalate a ticket, that decision follows from what a tool returned. The logged call tells you what the agent asked. It says nothing verifiable about what the agent was shown.

What Gets Logged vs. What Drives Behavior

A typical MCP audit trail contains:

• Timestamp of the tool call
• Tool name and version (usually from the client's perspective)
• Input parameters
• Sometimes: the agent's model version

What it rarely contains, with any integrity guarantee:

• The raw bytes of the tool response
• A signature proving those bytes came from the declared tool server
• A binding between the specific call and the specific response
• Proof that the response arrived within an expected time window

The response is logged, if at all, as a field in the same record as the call. There is no cryptographic link between the two. A tampered response is indistinguishable from a legitimate one in the audit trail.

Why This Creates a Real Attack Surface

Consider a production agent with read access to a customer database and write access to a CRM. The agent calls a lookup tool, gets back a customer record, and uses that record to update the CRM. Standard flow.

Now consider the same flow with a tampered lookup response. The agent still logs a legitimate call to the lookup tool. The response in the log is whatever was received. If the response was modified in transit — or substituted by a compromised tool process — the agent's downstream write action looks fully authorized in the audit trail. The call was real. The authorization was valid. The response was not.

This is not a theoretical vector. MCP tool processes run as separate services. They can be updated independently. They can have bugs exploitable through their inputs. In multi-tenant deployments, tool processes may serve multiple agents from shared infrastructure. A response cache shared across requests can be poisoned once and affect many subsequent agent decisions.

None of this shows up in a call-level audit trail.

The EU AI Act Framing

Article 9 of the EU AI Act requires providers of high-risk AI systems to implement risk management that covers "the risks that may emerge when the high-risk AI system is used in accordance with its intended purpose." An agent acting on a tampered response is not a misuse — the agent is doing exactly what it was designed to do. The risk is environmental, not behavioral. Call-level logging does not surface it.

Article 13 requires transparency about inputs to AI decisions. An agent's decision to take an action is an AI decision. The input to that decision includes the tool response. A compliance-grade audit trail for Article 13 should capture what the agent was shown, not just what it asked.

Article 17, which mandates post-market monitoring, requires the ability to detect performance deviations after deployment. A response integrity problem is precisely the kind of deviation that post-market monitoring is supposed to catch — but cannot, without response-level attestation.

The EU AI Act does not use the words "response integrity." It does not need to. The requirement for complete input-output traceability implies it.

What Response Integrity Actually Requires

Proving that an agent received what it claims to have received requires four things:

1. Response binding. Each call must produce a unique identifier — ideally derived from both the call parameters and a server-side nonce — that appears in the response. This ties response to call without ambiguity.

2. Response signing. The tool server must sign the response, including the call identifier, with a key whose public counterpart is known to auditors. The signature proves the response originated at the declared server, not in transit or in a log entry constructed after the fact.

3. Timestamp inclusion. The signature must commit to a timestamp within a narrow window of the call. This prevents valid signatures on stale responses from passing as fresh.

4. Client-side recording. The agent's infrastructure — not the tool server — must record and store the signed response. Server-held logs do not prove what the agent received. They prove what the server claims to have sent.

Most MCP implementations have none of these. Some have logging on both sides with no cryptographic connection between them. A few have request signing. Almost none sign responses at the server and verify signatures at the agent.

The Asymmetry Problem in Existing Frameworks

The current state of MCP tooling reflects an implicit assumption: the tool server is trusted. Once you have authenticated to a server and received a response, you accept it. This assumption is reasonable for individual development and most tightly controlled production deployments.

It is not reasonable for:

• Agents operating across organizational boundaries with external tool integrations
• Multi-tenant tool infrastructure
• Tool processes with complex dependency chains that may be independently compromised
• Any deployment where the agent and tool server are not operated by the same party

In all of these cases — which increasingly describe real production deployments — a response that looks right provides no proof that it is right.

The gap also compounds in multi-hop chains. Agent A calls Tool 1, receives Response A, and passes a summary to Agent B. Agent B calls Tool 2 based on that summary. The audit trail for Agent B contains no reference to Response A, which is the upstream input to its reasoning. By the time a compliance auditor asks what Agent B acted on, the answer requires reconstructing a chain that was never recorded as a chain.

What a Signed Response Chain Looks Like

A complete response integrity implementation at the transport layer handles this transparently. When an MCP tool call passes through a verifying proxy:

1. The call is intercepted and given a unique call ID before forwarding to the tool server.
2. The tool server returns a response. The proxy signs the response, the call ID, and the timestamp.
3. The signed response bundle is forwarded to the agent.
4. The agent's runtime verifies the signature before processing the response.
5. The bundle — call, response, signature, timestamp — is stored as a single atomic record.

The agent cannot act on a response that fails signature verification. Auditors receive records that prove both what was asked and what was received, bound together with a signature that cannot be forged after the fact.

This is what ArkForge's Trust Layer implements at the proxy layer for MCP tool calls. The binding happens at transport, so it requires no changes to agent logic or tool server implementation. Every response that passes through the Trust Layer is attested. Every call-response pair becomes a single verifiable record.

The Practical Test

If someone asked you to prove that the response your agent received at 14:32:07 UTC yesterday was the actual response from your declared tool server — not a cached version, not a substitution, not a value injected by a compromised dependency — could you do it?

If the answer relies on "the log says so," you are relying on a self-report from a system that cannot verify its own inputs. That is not compliance-grade evidence. EU AI Act enforcement authorities are not going to accept it.

The calls your agents send are the easy part of the audit trail. The responses they receive are where the evidence chain breaks. That is the gap worth closing before someone else starts asking questions about it.