Building tamper-evident evidence for every request and tool call in-house: what it takes

What tamper-evident means for a single request or tool call

Tamper-evident does not mean tamper-proof. A privileged user may still attempt to change a record. The requirement is that the change cannot go unnoticed. For an individual request or tool call, that implies three properties. The record is complete enough to show what the AI was allowed to do and what it did. It is protected at or near the moment it is created. And an outside party can check it without relying on the system that wrote it.

NIST guidance on agent identity describes this as immutable evidence: an unbroken, tamper-evident chain of custody and an append-only body of evidence covering the agent's identity, the delegated intent and the resulting actions. The same guidance warns that if an agent can access or modify its own activity logs, a compromised agent could delete or alter its actions. An NCCoE concept paper on agent identity and authorization still lists verifiable, tamper-proof logging of agent actions as an open question. Teams should expect to design this themselves, not follow a settled reference.

Why the capture point decides the quality of the evidence

Application logs, gateway records and observability data are written to help engineers debug. They are usually mutable, spread across models, agents, tools and MCP servers, and rarely record which policy applied to a call or what it decided. Assembling evidence from them means reconstructing the decision afterward, which is inference, not a record.

Evidence produced at the enforcement point records the decision as it is made. NIST states that individual tool invocations, API calls and resource access should undergo continuous runtime verification based on current state, context and risk. A capture point in that path can record the verification outcome. A capture point elsewhere can only observe traffic that happens to pass it. The practical test is whether you can detect a call that bypasses capture. If you cannot, your coverage is unknown, and an auditor will ask about it.

Engineering and operational risks

Most of the cost sits in operating the system, not in writing the first version. These failure modes are the ones to plan for, based on general engineering practice.

• Coverage gaps: A new tool, MCP server or agent path that skips the capture point produces no evidence, and nothing signals the omission.
• Anchors in the wrong trust domain: If the same administrators can edit records and the hashes that protect them, tampering is no longer detectable.
• Key compromise: A leaked signing key lets an attacker produce records that verify. Rotation and revocation must be designed in advance.
• Schema drift: Fields change as policies and tools change. Older records must stay verifiable and interpretable.
• Storage and volume: Per-call records, hashes and separately stored payloads grow quickly, and retention multiplies the cost.
• Verifier decay: Verification tooling needs versioning, documentation and maintenance, or old exports become hard to check.

How Trussed approaches the capture point

Trussed enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants. Each interaction or tool call is allowed, redacted, blocked, rate limited or escalated for human approval. Because policy is enforced at runtime, not reviewed after the fact, the audit-ready evidence is generated by enforcement itself and is continuous. It is mapped to HIPAA, NAIC, NYDFS, the EU AI Act and NIST. The scope is individual interactions and tool calls.

Trussed deploys self-managed in the customer cloud, with configurable retention and data residency. Production experience includes 18+ months of continuous operation in a regulated enterprise, 99.95% uptime on live production traffic, 100+ models under one policy plane and 30+ GB of audit evidence generated per day. Whether you build or adopt, judge the result by the criteria above.