There is a style of AI agent security posture that, under pressure, reduces to a single claim: "we have comprehensive logging." The implicit argument is that observability is security. It is not. Logs are evidence. Evidence is useful. Evidence is not a control over whether the action happened. For AI systems that commit irreversible actions - payments, data exports, EHR writes, grid operations, infrastructure mutations - "we logged it" is the operational admission that the action got through. Whatever you learn from the log, the action already executed.
Key concepts
This post makes the line between evidence and control sharp, walks through the specific ways "logging as security" fails, and shows the posture that actually prevents the events that matter. For the foundational model see runtime authorization for AI agents.
The distinction, as sharp as it can be drawn
Logs have three useful properties:
- They tell you what happened, approximately.
- They let you reconstruct timelines after the fact.
- They provide material for post-incident review, compliance reporting, and threat detection.
Logs do not have these properties:
- They do not stop actions.
- They do not refuse unauthorized requests.
- They do not provide any structural guarantee that bad events will not happen.
The word "security" covers both control and evidence in ordinary usage, which is part of the confusion. In engineering terms, control and evidence are different concerns. A firewall is a control. A SIEM is evidence. Rotating credentials is a control. Alert correlation is evidence. Both matter. They are not substitutes. Telling a regulator "we have evidence" when asked for "we have a control" is not a satisfying answer; it is a reveal that the control was not in place.
Why AI sharpens the problem
Before AI agents, most consequential actions had a human in the loop. That human was the de facto prevention layer. Their click, their ticket, their signature - that was the control. The log was a record of what they approved.
When an AI agent replaces the human, the click is gone. The log is now a record of an action the system committed by itself. The inference some teams make is "the log tells us what the system did, so we are covered." It does not follow. Without the human's click there is no prevention layer, only an evidence layer. The action reached the external system because nothing stopped it. The log is a postcard arriving after the event.
This is the heart of why "logging is not AI security" is worth saying out loud. The intuition from pre-AI systems - "if we log it, we can always chase it down" - was implicitly counting on the human-in-the-loop for prevention. The human is no longer there. The log is all that is left, and the log is not enough.
Specific ways logging-as-security fails
The irreversible action problem
A customer export commits. The log records the export. The data is in the external address. You have a forensic record and a data-breach notification to issue. The log did not help the data stay internal.
This is the shape of every irreversible action failure: the log is complete, and the event still happened, and there is no recovery that undoes it. For this class of action, post-hoc evidence is not a safeguard; it is a document for the after-action report.
The reconstruction problem
An incident is discovered thirty days later. You open the logs. The relevant log lines are missing because the logger was behind on disk, or the log level was wrong, or the retention policy aged them out, or the service was rotated and the log stream was not captured. The investigator reconstructs a partial picture and the rest of the story is guesswork.
Application logs are operational artifacts. They were not designed for defensibility. Their retention, integrity, and completeness are whatever the ops team's discipline happens to provide. When you need them most - an incident, an audit, a regulator - they are sometimes adequate and sometimes not, and you find out which at the worst possible moment.
The integrity problem
Even when the logs are complete, nothing about their content is tamper-evident. An attacker who reaches the log stream can modify it. A buggy deployment can overwrite it. A well-meaning operator can redact it "for privacy" in a way that removes the relevant context. The entity that produced the action is usually the same entity that wrote the log, so an internal defect can manifest simultaneously in the action and in the record of the action.
Evidence without integrity is a narrative with decoration. It is useful when everything is working; it is not useful when the claim is contested. Signed receipts, produced at decision time by an authority holding a private key, are the fix. See verify for the receipt verification flow that closes this.
The semantic problem
Even when logs are complete and untouched, they often do not capture the information needed to answer the question that matters. "Was this action authorized?" is a question about policy, not about event sequence. Typical application logs record what happened, not what was decided and under which rule. Reconstructing the decision from operational logs is a research project, not a lookup.
This is the specific reason signed receipts matter: they record the decision, the rule, the policy version, and the outcome, not just the event. The receipt is a decision artifact. The log is a side-effect artifact. Only the decision artifact can answer "was this allowed."
The scale problem
AI agent deployments produce log volume at a rate that dwarfs human-driven systems. An agent doing a hundred tool calls per task, across thousands of tasks, produces millions of log lines per day. The useful signal - the rare unauthorized action - is a needle in a silo. Even if the log captures it, nobody finds it in time.
Alert engineering can compensate to a point, but alert engineering is itself probabilistic. False positives desensitize the responders. False negatives mean the action is committed and nobody notices for days. The alert layer is valuable; it is not a prevention layer.
What a prevention posture looks like
The inversion of "log it and hope" is pre-execution authorization: the action does not commit unless a deterministic decision returns PERMIT. The log is still there, for the operational reasons it was always there, but the control on the event has moved upstream of the event.
A prevention posture has four properties that a logging-only posture does not:
- It stops the event. Pre-execution means the decision is in the critical path of the action. Without
PERMIT, no dispatch. - It produces evidence as a byproduct of the decision. Signed receipts are issued at decision time and are the authoritative record. Operational logs continue, but they are supplementary.
- It is defensibly binary per action. Every action has a receipt. Either it has a
PERMITreceipt and committed, or it has aDENY/SILENCEreceipt and did not commit. The state space is small, and every element of it is documented. - It is independent of the producer. Receipts are verified by a separate surface using a public key. You do not have to trust application logs, application servers, or the agent runtime to believe the receipt.
Every one of those is a structural property. None of them requires operator discipline to hold. Discipline is required to enforce them, but once enforced, the system's correctness is not on the operator's shoulders.
Responses to the usual objections
"We can add real-time alerting on the logs."
Alerting still fires after the event. For reversible actions, after-the-event is a useful threshold. For irreversible actions, after-the-event is "we know the money is gone and we are escalating." The speed of the alert does not change whether the action committed.
"We use structured logs and a SIEM, not just text files."
That improves log quality, which is worth doing. It does not change the category. Structured logs are better evidence, but they are still evidence, not control. A SIEM can correlate signals and raise useful alerts, but the alert fires after the event.
"Logs are required for compliance. Isn't that enough?"
Compliance frameworks require evidence. They do not define evidence as sufficient to replace controls. A good auditor asks what control prevented the event; if the answer is "nothing, but we have logs," the auditor writes it up. The frameworks expect both layers.
"Our agents are low-risk; logging is fine."
This is a reasonable position for agents whose actions are reversible and low-value. A chatbot that summarizes documents does not need pre-execution authorization; the "actions" are ephemeral. The argument stops applying the moment an agent can commit an action that affects external systems in a way that costs money, reputation, or regulatory exposure to reverse.
"We are adding logging to a regulated pipeline."
Then you also need a pre-execution control. Regulated AI pipelines - financial services, healthcare, critical infrastructure - are specifically the cases where the "logging is enough" argument does not survive a first audit. See EU AI Act and execution governance and why SR 11-7 isn't enough for generative AI for industry-specific arguments.
The "but we already have logs" trap
A pattern worth calling out, because it shows up in almost every engagement. The team has operational logs. They describe the logs as security. Asked what happens if an agent commits an unauthorized action, they describe the investigation process. Asked what prevents it, they describe the content filter or the prompt instruction.
Both of those items are doing some work. Neither of them is the control that prevents an authorized-looking action from committing. The control is missing. The logs are filling the conceptual slot the control should occupy.
The trap is that fixing this looks expensive - now we need a gate, a policy engine, a receipt store, a verifier - so teams lean on the logs until an incident forces the conversation. The cost of the incident is usually much higher than the cost of the gate. The order is: add the gate on high-stakes surfaces first; keep the logs; treat the logs as what they are (evidence, supplementary).
What changes when you flip the posture
A team that moves from logging-as-security to prevention-plus-evidence notices specific differences in day-to-day operations:
- Post-incident reviews get shorter because the receipts cover most of the reconstruction work.
- Auditors finish the authorization section of their review faster.
- Engineers have fewer "we think this is what happened" meetings, because the receipts are deterministic.
- The operational log volume becomes less load-bearing - still important for debugging, not the authoritative record.
- Alerts shift from "action committed, was it allowed" to "authorization rate changed, is the policy wrong." The first class of alert asks evidence-shaped questions of logs; the second class asks control-shaped questions of a control.
That last shift - from alerting on events to alerting on control behavior - is the clearest signal that the posture has moved. Control-shaped alerts are cheaper to engineer, have lower false-positive rates, and point to the right action ("review the recent policy change" instead of "investigate the transaction").
Frequently asked questions
Are we saying "don't log"?
Absolutely not. Logging is essential; we are saying logging alone is not a control. A production AI agent needs both the gate (the control) and the operational logs (the evidence). Receipts are the authoritative record for authorization specifically; operational logs are the record for everything else.
How do receipts relate to our existing audit logs?
Receipts are a new source, issued by the authorization authority, covering decisions. Audit logs typically cover actor-surface-action events, often without the decision context. The two are complementary: audit logs say what happened, receipts say what was decided. Most mature programs keep both and cross-reference them by request ID.
Can we use receipts as audit logs?
You can, for the subset of events that are authorization decisions. Receipts are narrower than audit logs; they do not cover login, session management, internal service calls, or most of the operational activity audit logs collect. Use receipts for what they are designed for (decisions) and audit logs for the rest.
Next step
For the conceptual frame see runtime authorization for AI agents and pre-execution security for AI systems. For the receipt and verification shape see verify. For the broader production posture see securing AI agents in production.
Related architecture
Next step
Shift from evidence-only posture to prevention-plus-evidence for your irreversible AI actions.