Verify an AI Security Agent Actually Did What It Reported

Verify an AI security agent by capturing a tamper-evident record of each action through an external gateway, anchoring that record outside operator control, and checking real system state against claimed outputs. Cryptography proves record stability over time. It leaves correctness to direct system verification.

Open full-size image (opens in new tab)

Why must you audit agent actions outside the agent?

Local agents can hallucinate completed tasks or rewrite editable local logs. Relying on an agent's private summary leaves you with self-reported claims instead of confirmed executions. An external observer isolates execution facts from model self-assessment, capturing what ran on the host.

I have watched local runs report clean completions while the target file remained untouched on disk. You must verify what an agent actually produced directly. The IETF Internet-Draft draft-kuehlewind-audit-architecture-00 (Network Working Group, published 18 May 2026, expiring 19 November 2026) explains this boundary. Section 4.3 states the auditor "is not required to trust the Agent." If you give an agent a file, not a memory, you can inspect disk files, yet an agent with write access can overwrite plain text files. Independent verification demands an immutable record.

What record types establish an agent audit trail?

An agent audit trail captures structured events across interactions, discrete tool actions, cross-agent delegations, and authorization changes. Storing these records in an append-only sequence separates authentic authorship from timeline integrity. Auditors inspect this chronological record after an agent completes its run.

The IETF draft draft-kuehlewind-audit-architecture-00 is an informational working document rather than an RFC. It defines four record types:

• Interaction: Stores incoming user prompts and system inputs.
• Action: Details specific tool invocations and execution parameters.
• Delegation: Maps task handoffs between agents across an execution chain.
• Authorization Transition: Records permission updates and privilege changes.

Example fields include event_id, trace_id, parent_id, timestamp, actor, on_behalf_of, and delegation_chain. The draft separates two properties. Attestation confirms record authenticity through signatures such as JWS or COSE. A Transparency Log proves records existed in an append-only, non-equivocating sequence. Section 9 recommends hashing tool-call outputs instead of saving large bodies inline. The draft defers receipt verification details to WI-7.

How does a cryptographic hash chain verify executed actions?

A cryptographic hash chain links every record to the previous entry using SHA-256 hashes. Any altered, skipped, or reordered log entry breaks the mathematical chain instantly. Verification checks sequence numbers from zero, counts total records, validates individual hashes, and matches the root hash against an external fingerprint.

Vikas Luthra, creator of open-source AgentLedger, detailed this mechanism in a 16 October 2026 article on HackerNoon. In that system, each SHA-256 hash covers the record's canonical content plus the previous record's hash.

The verification process uses four checks:

Use tools like BMD, see what your agents actually did to inspect tool calls directly on your host machine. Inspecting the raw sequence of calls exposes what ran before an error occurred.

Where do tamper-evident logs reach their limits?

Tamper-evident logs prove that stored records remained unchanged after creation. They confirm sequence preservation, but leave target system accuracy unverified. If an agent accesses tools outside the gateway, unrouted actions remain unrecorded. Reconciling records against real system configurations confirms whether changes actually occurred.

Luthra clarifies that this architecture is tamper-evident rather than tamper-proof. The design avoids judging whether an agent acted correctly. Several operational limits exist:

1. Gateway bypasses: Unrouted network commands bypass the proxy and produce zero log entries.
2. Reconciliation gaps: Tool outputs recorded in a log can diverge from actual system state.
3. Restoration attacks: A value altered and later restored passes every hash verification step.
4. Local administrator control: A privileged administrator holding local records and root keys can rewrite the full history consistently. External root anchoring addresses this administrative risk.

Both sources examine general agents rather than security agents specifically. Neither source provides misreporting rates, and our own measurements have none on file for this specific gap.

What should you do with this?

Verify your agent by isolating its execution environment from its audit storage. Route tool calls through an append-only logging proxy, anchor the resulting hash-chain root outside the operator environment, and reconcile logged actions against real host state. This approach provides mathematical proof of sequence alongside practical verification.

Follow three steps in your setup:

1. Route agent commands through a logging gateway: Force tool invocations through a proxy that records event_id, actor, and SHA-256 hashes of outputs into a hash-chained ledger before execution.
2. Anchor the root fingerprint externally: Store the Merkle root hash in a separate system outside the agent operator's control.
3. Reconcile target system configurations: Query target systems directly to confirm that reported configuration changes exist in live infrastructure.

Accompanying prompt

What the prompt does: This prompt audits an AI security agent's reported actions against raw tool logs and target system state.

Copy/paste this prompt:

Copy-ready prompt

Paste the exact block into your coding agent.

No article chrome, no footnotes, no formatting drift.

Copy promptSelect text

Role: Security audit verification assistant. Context: An AI security agent finished an operational run and generated a completion summary. You must verify whether the reported actions match the recorded audit chain and real system states without trusting the agent's narrative. Inputs: - Agent summary path: __ - Audit log path: __ - Root hash fingerprint: __ - Target system config path: __ Task: 1. Parse the record count, sequence numbers, and SHA-256 hashes in Audit log path. 2. Verify that sequence numbers start at zero with no missing indices. 3. Compare the calculated root hash against Root hash fingerprint. 4. Compare each action reported in Agent summary path with the corresponding entry in Audit log path. 5. Identify any claimed change that is missing from Target system config path. Output: - Discrepancy report detailing verified actions, missing log records, and unconfirmed target system states. Constraints: - Rely strictly on facts present in the provided input files. - Reject any reported action that lacks a corresponding hash-chained log entry. - Mark any sequence gap or root hash mismatch as an immediate audit failure.

26 lines/1152 chars

Ready

This prompt and every other one we publish live in the free prompt library.

Copy the block above.

Weekly measured local runs: https://bmdpat.com/5090-reports