Make agent logs tamper evident by sending them off the agent's host as they are written, storing copies on read-only media, restricting and monitoring who can read or change them, and building in checks that reveal gaps or edits. The agent must never be able to rewrite its own history.
Why this matters more for agents
Two things make agent logs a target. First, a hijacked agent may try to hide what it did, or its injected instructions may tell it to. Second, some tools let an agent write files, so a log stored where the agent can write is a log the agent can edit. OWASP's logging guidance warns that attackers prevent writes or damage logs to cover their tracks, and may cause the wrong identity to be logged to conceal their actions.
What OWASP recommends
For storage at rest, the guidance says to build in tamper detection so you know if a record was modified or deleted, store or copy log data to read only media as soon as possible, record and monitor all access to logs, and restrict and periodically review the privileges to read them. For data in transit, use a secure transmission protocol over untrusted networks and consider whether the origin of events needs to be verified.
It also notes honestly that true non-repudiation is hard to achieve for logs, because trust usually rests on the logging party being audited properly. Treat tamper evidence as strong evidence, not mathematical proof.
Steps
- Separate the writer from the reader. The agent's identity may emit events but should have no permission to read, change or delete the log store.
- Ship events off host immediately. A copy that left the machine before an incident cannot be edited by an intruder on that machine.
- Write to append only or write once storage where your platform supports it. Copy to read only media on a schedule.
- Add sequence numbers or hash chaining per source, so a missing or altered record shows up as a break.
- Alert on silence. If an active agent stops producing events, that is a signal, not a quiet day.
- Log access to logs. Reads and exports of the audit store should themselves be recorded and reviewed.
- Synchronize clocks. Records from different systems need trustworthy times to line up in a timeline.
- Record approver and administrator actions in the same stream, so changes to policy are as visible as the agent's calls.
What to test
| Test | Expected result |
|---|---|
| Agent identity tries to delete a log entry | Denied and alerted |
| Delete a record at the source host | Off host copy remains |
| Remove one entry from a chained sequence | Check reports a break |
| Stop the agent's logger | Silence alert fires |
| Read logs without a logged reason | Access recorded |
Run these in a safe environment, and repeat after changes to the logging pipeline.
Beware of log injection
Untrusted text from tools or users can be written into logs. OWASP refers to log injection and CWE-117. Encode values and use structured fields, so an attacker cannot forge a record that looks like a legitimate approval.
A realistic target
You do not need a perfect system on day one. Start with off host shipping and no write access for the agent. Those two steps stop most casual cover ups, and the rest can follow.
Safeguard offers compliance and evidence automation for keeping audit records organized. A free scan is at https://gold.safeguard.sh/scan.
Quick check
Is hashing each log line enough?
It helps detect edits, but chain or sequence the hashes and store copies off host, or an intruder could rewrite everything.
Why alert on missing logs?
Attackers and failures both create silence. A gap is a signal.
Sources
Last reviewed: 19 October 2026.
