AI in Cyber Security: The Missing Evidence Layer

Joe BraidwoodCo-founder & CEO

June 2026 · 6 min read

The conversation about AI in cyber security has, for a few years now, been a conversation about speed. Faster triage. Faster correlation. Models that read a million log lines and surface the three that matter. That work is real, and it has made the SOC measurably better. But a security architect bringing AI into the stack eventually runs into a quieter, harder question — one that detection and response were never designed to answer. When a model gates a tool call, redacts a payload, or denies an agent an action, can you prove, independently and after the fact, that the control actually executed? Most teams cannot. That gap is the missing evidence layer in AI in cyber security, and it is the layer this piece is about.

It is a strange omission. We have spent the discipline’s whole history learning to distrust the system under examination — that is the entire reason for separation of duties, for write-once audit trails, for independent review. Yet the newest, most autonomous components in the environment are largely governed by controls that report on themselves. The control runs inside the same boundary it is meant to police, writes to a log the operator can edit, and asks everyone downstream to take its word. For a stateless web app that was tolerable. For systems that act — that call tools, move data, and make decisions at machine speed — it is not.

Detection and response answer a different question

It helps to be precise about what the existing layers do and do not cover. Detection answers did something suspicious happen. Response answers what did we do about it. Both are essential. Neither answers which control was in force at the moment of the action, and can an outside party confirm it without trusting us.

Consider an agent that is permitted to read from a database but never to write. A guardrail enforces that boundary at the tool-call layer. Six weeks later, an auditor — or a regulator, or an internal incident team — asks a reasonable question: on the third Tuesday of last month, when that agent touched the customer table, was the write-block actually active, and which version of the policy was loaded? The SIEM has a line that says the action was denied. But that line lives in storage the operator controls. It is an assertion. A determined reviewer is right to ask why they should believe it, and the honest answer reduces to “trust our logging” — which is exactly the answer that does not survive scrutiny.

This is the heart of it. Detection and response generate telemetry. Telemetry, as normally implemented, is reducible to operator-controlled logs — and a record the operator can quietly alter is a recollection, not evidence. The distinction sounds academic until the day it is the only thing standing between a team and a finding it cannot rebut.

Why AI agent security raises the stakes

The need sharpens with autonomy. AI agent security is not a rename of application security; the unit being governed has changed. A traditional control sat in a request path a human initiated. An agent initiates its own actions, chains them, and can take a great many before anyone reviews a single one. The blast radius of a control that silently stopped working is far larger, and the window in which it goes unnoticed is far longer.

So the assurance bar has to rise to meet it. For agentic systems it is not enough to assert that a permission boundary exists — what is needed is trustworthy evidence of which enforcing component, in which configuration, was active when a specific governed action occurred (permit, deny, override, escalation, response), together with a defensible account of what was in scope versus excluded and how the denominators were derived, so “we cover the agent fleet” becomes a number an auditor can reproduce rather than a reassuring adjective. Coverage you cannot account for is coverage you cannot defend.

What AI in cyber security still cannot prove

If the gap is the absence of proof, the fix is a layer that produces proof as a by-product of enforcement — not a separate reporting exercise bolted on afterward. Three properties make that layer trustworthy rather than merely verbose.

Tamper-evident, not operator-trusted

The record has to be tamper-evident telemetry — signed at the moment of enforcement such that any later alteration is detectable, and not reducible to a log the governed party can edit. The test is simple: hand the record to someone who has no reason to trust you and let them check it. If verification depends on trusting the operator’s storage, it is not evidence. If the signature stands on its own math, it is.

Independent by structure

Whoever attests must be separate from whoever is governed. Self-attestation is not independent attestation — a system vouching for itself carries exactly the weight of the incentive to look clean, which is to say none that a serious reviewer will credit. Independence cannot be a promise in a policy document; it has to be a property of how the architecture is wired, so that the party producing the proof is structurally distinct from the party being examined.

Verifiable without re-exposing the data

This is where most teams expect a catch, because the obvious way to prove what happened is to keep a copy of what happened — and a forensic store of decisions over sensitive content is a fresh breach waiting to be discovered. A workable evidence layer reconstructs an event history after the fact without routine content disclosure. Only cryptographic fingerprints and signatures cross the boundary; the protected content never leaves the operator’s environment. The result is post-incident reconstruction that does not turn the attestation trail into a new egress channel — proof and confidentiality at the same time, rather than a trade between them.

Put those three together and you have what the SOC has been missing: runtime proof. Not a better dashboard, not a richer log — a record an outside party can independently check, that is silent about everything it need not disclose.

OVERT: an open standard for the layer

This does not need to be proprietary plumbing, and it should not be. OVERT is an open standard — published with a royalty-free patent covenant — for exactly this: producing independent, tamper-evident proof that a runtime control executed, without protected content leaving the operator’s environment. Its framing is plain. Governance has always been able to say what ought to be done; it has rarely been able to prove what was. Policies and self-reported logs record intentions and recollections. OVERT makes a governed action yield a receipt a third party can check — evidence, not a claim it is asked to trust.

The 1.1 release, published in June 2026, is additive and backward-compatible with 1.0 — an implementation conformant to 1.0 stays conformant without modification — and it leans directly into the wiring that makes the evidence layer practical to operate. A new normative annex specifies content-addressed storage for retrieving and retaining evidence with integrity, an HTTP transport binding for carrying attestation across a boundary, an automated auditor-discovery protocol via a well-known endpoint, and a reference schema for the ControlAction artifact the standard already requires. The plain reading: cross-boundary attestation stops being a bespoke integration and becomes something a reviewer’s tooling can simply find, fetch, and verify.

Where this leaves the security architect

None of this displaces the AI security solutions already earning their keep in the SOC. Detection still finds the anomaly; response still contains it. The evidence layer sits underneath both and answers the question they were never built to answer — which control held, and can an outsider confirm it — turning enforcement into something provable rather than merely asserted. For regulated and agentic deployments, where the cost of an unfalsifiable claim is measured in findings, fines, or lost trust, that shift from assertion to proof is the part of the AI in cyber security story that is still being written.

If you want to feel the difference in concrete terms, verify a receipt and watch a control prove itself — without the underlying data ever leaving home.