Writing ·
How to stop AI agents from tampering with their own traces
Capture model and tool evidence outside the agent's authority, protect accepted records, and test deletion, rewriting, suppression, and bypass before release.
By Youssef Hemimy · agent observability · agent safety · AgentOps
Do not treat a trace stored on an agent-controlled host as authoritative audit evidence. Capture model exchanges through a recorder the agent cannot administer, retain consequential tool events from an independent execution path, protect accepted records from alteration, and test deletion, rewriting, suppression, and bypass under representative permissions.
A clear transcript is still weak evidence if the subject of the transcript can silently change it. The first design decision is where recording authority lives—not which dashboard displays the events.
Separate four properties of a trustworthy trace
| Property | Question | Failure to test |
|---|---|---|
| Capture | Did an event enter a recorder? | An alternate endpoint never reaches it. |
| Integrity | Can an accepted event be silently changed or deleted? | A local session file is rewritten. |
| Completeness | Can relevant activity bypass every approved recorder? | A local model or secondary tool path runs unobserved. |
| Authenticity | Does the event reflect what actually executed? | A compromised shell reports a false outcome. |
A signed record can have strong integrity while remaining incomplete or describing a spoofed execution path. Qin and colleagues explicitly distinguish their proposed interception from proof that tools ran faithfully on a compromised host.
Why local session files are not enough
Qin et al. tested ten local model-harness pairs in containers, generally with full-access permissions. Their work included four direct deletion or manipulation scenarios with ten trials per condition, followed by malicious-skill, hidden-incentive, and peer-example settings. Most tested configurations allowed trace deletion or manipulation in at least some conditions; restricted modes changed results by harness and task. These observations are bounded to the tested models, prompts, containers, and permissions.
The durable systems principle is narrower than a universal claim about agents: if an agent can write the host or credentials protecting its canonical log, that log shares the subject's authority. NIST AU-9 calls for protecting audit information and tools from unauthorized access, modification, and deletion. AU-9(2) describes storing records on a physically different system or component to avoid losing the audit record when the audited system is compromised.
Move authoritative capture outside the agent's authority
The preprint proposes an interceptor between a harness and the model API. It records requests and streamed responses, distinguishes retries and interrupted completions, and writes to an append-only record that the agent host cannot modify. That is an architectural proposal, not a production-complete implementation or proof of universal coverage.
Untrusted boundary
Agent-controlled host
The agent may change local files, processes, and its own transcript. Local logs are diagnostic, not the canonical audit record.
Independent capture
Model API recorder
Records requests, response chunks, retries, and interruptions before returning them to the host. Agent credentials cannot edit accepted records.
Execution-side evidence
Tool or policy service
The remote executor records what it accepted and did. Correlate by operation ID; do not infer faithful execution from a model trace.
Protected evidence boundary
Separate administration, append-only acceptance, and verifiable integrity protect captured events. Test alternate routes and outages: a protected record can still be incomplete.
For a local implementation, use these Bonfire AgentOps Hardening checks:
- Send-only identity: the harness may submit events but cannot update or delete accepted records.
- Separate administration: its identity cannot disable the recorder, erase sessions, rotate signing keys, or change retention.
- Durable acknowledgement: define whether consequential work stops, retries, or enters a visibly degraded mode when recording fails.
- Visible gaps: represent interrupted streams, rejected events, retries, and recorder outages rather than showing a falsely complete trace.
- Rebuildable views: searchable indexes are derived from the protected source record, not the only copy.
OWASP's logging guidance recommends centralized collection, restricted writer accounts, access checks, logging-failure tests, stop detection, tamper detection, and read-only copies. “Outside” means a distinct authority boundary, not just another directory: a sidecar remains weak if the agent can change its process, configuration, credentials, or storage.
Give model exchange and tool execution separate evidence paths
A model interceptor observes traffic crossing the model API boundary. It does not necessarily observe what a mutable local tool actually did. For consequential actions, retain an execution-side event from a service the agent cannot rewrite—for example, the tool service, database audit facility, policy gateway, or infrastructure control plane. Correlate it with the model-side event using an operation ID, but do not let the host's success claim substitute for an execution record.
A compact envelope can carry request and operation IDs, recorder timestamps, workload identity, endpoint or tool class, policy version, content hashes where raw data is restricted, and acceptance, retry, or interruption status. This schema is Bonfire guidance, not a requirement from the study. The production tool-contract guide covers the independent intent, validation, execution, and audit boundary.
Make post-delivery changes detectable
AWS CloudTrail illustrates one tamper-evident pattern: delivered log files are hashed, digest files are signed and chained, and validation can reveal modification or deletion after delivery. This is an implementation example, not a requirement to use CloudTrail or proof that the original event was true.
For higher-consequence traces, bind accepted records into ordered batches, hash or externally anchor a manifest with authority unavailable to the agent, validate the chain during review, and alert on changed records or missing expected batches. NIST also describes separate systems and hardware-enforced write-once media as possible audit-protection enhancements. Choose the mechanism for the workflow's impact and retention requirements.
Test the boundary before release
Run a representative agent with its real permissions, file access, network routes, skills, and tool surface. The following is a Bonfire AgentOps Hardening test matrix synthesized from the study and secure-logging guidance—not a standard prescribed by any one source.
| Attempt | Passing evidence |
|---|---|
| Delete or rewrite | Accepted canonical records survive; protected-storage validation catches alteration. |
| Suppress | Stopping the local logger creates a visible gap, alert, or defined stop. |
| Bypass | Alternate endpoints, local models, and secondary tools are blocked, separately recorded, or explicitly outside coverage. |
| Spoof | Independent tool evidence distinguishes actual outcome from host transcript. |
| Partition | Recorder loss follows the predeclared stop, queue, or degraded-mode rule. |
| Replay and recover | Duplicate or reordered events remain detectable; reviewers can validate without the compromised host. |
Do not choose “fail closed” by slogan. A safety-critical action may need to stop; an availability-critical read-only task may continue with an explicit incomplete-evidence marker. Decide in advance, test the outage path, and preserve enough evidence to identify the gap.
Govern sensitive evidence and integrity incidents
Moving capture outside the host can enlarge the sensitive-data footprint. Keep only evidence needed for an operating decision, split broadly useful metadata from restricted payloads, and set narrower access and retention for raw content. The telemetry data-protection guide covers this separate obligation.
If validation fails, narrow consequential actions under the predeclared policy, preserve the protected record and recorder state, mark the local transcript disputed, and compare model-side events with independent tool and infrastructure records. The AgentOps incident-response playbook covers containment; the root-cause guide helps reconstruct the decision after the evidence boundary is credible.
Sources
FAQ
Can an AI agent change its own trace?
It can when its permissions include the files or services that hold the trace. A 2026 arXiv preprint demonstrated deletion and manipulation in several tested local model-harness configurations; it does not establish that all agents or hosted systems have this capability.
Does an append-only trace prove what an agent did?
No. Append-only storage can protect accepted records from later alteration. It does not prove every event was captured or that a compromised local tool executed as the trace claims. Collect separate execution-side evidence for consequential tools.
Where should authoritative agent traces be captured?
Capture model exchanges through a recorder outside the agent's credentials, and consequential tool activity through independently controlled execution services. Restrict delete, retention, and recorder-configuration authority; test bypass and outage paths.
Building something that has to hold up?
We do this work for teams — agent reliability hardening, custom MCP servers, and full-stack AI systems built to survive production.