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. But a security architect bringing AI into the stack eventually runs into a quieter question — one that detection and response were not designed to answer. When a model gates a tool call, redacts a payload, or denies an agent an action, what independently checkable record exists for that covered event? That gap is the missing evidence layer this piece addresses.

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 asks did something suspicious happen. Response asks what did we do about it. Both are essential. Neither necessarily preserves a portable signed record of what a configured control reported for one covered action, with a disclosed procedure for checking supported properties.

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. Operator-controlled logs can be valuable operational evidence, but an outside reviewer must also assess their integrity, retention, selection, and coverage. A signed record can make changes to covered bytes detectable; it cannot establish that the underlying claim is true or that every relevant event was recorded.

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. A signed record can preserve which enforcing component and configuration the system reported for a specific covered action (permit, deny, override, escalation, response), while deployment, routing, timing, and control-testing evidence must corroborate that report. The organization also needs a defensible account of what was in scope versus excluded and how 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 independently checkable event records, the fix is an evidence layer integrated with the configured enforcement path — not a separate reporting exercise bolted on afterward. Three properties make that layer more useful than merely verbose telemetry.

Tamper-evident, not operator-trusted

The record should be tamper-evident telemetry — signed so that later alteration of covered bytes is detectable. The test is concrete: hand the record and verification procedure to another party and let them check supported signatures and covered fields. A successful signature check establishes integrity and signer correspondence for those fields, not the truth or completeness of the event claim.

Independently verifiable, with provenance disclosed

Independent verification means another party can run a disclosed checking procedure without relying on a proprietary dashboard. Organisational independence is a separate property: the record should identify its signer and any witness so the reviewer can assess their relationship to the operator. A second signature or service-operated witness does not, by itself, make the signer independent of the governed party.

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 data-minimizing evidence path can preserve fingerprints, outcomes, signatures, and bounded verification metadata while protected content stays inside the operator’s configured boundary. The result can support post-incident reconstruction without turning the evidence trail into a second store of prompts or outputs. The deployment’s actual data flow still has to be inspected; the record is not proof that no other path exists.

Put those three together and you have a scoped operational evidence layer: a record an outside party can independently check, with its covered fields, provenance, and data-minimization limits made explicit.

OVERT: an open standard for the layer

This does not need to be proprietary plumbing. OVERT is an open standard, published with a royalty-free patent covenant, for signed operational records. For covered events on a configured path, a receipt can expose supported signatures, selected fields, and a reported control outcome to third-party verification. A data-minimizing configuration can keep protected content inside the operator’s boundary, but the record does not prove that no other data path exists, that collection was complete, or that the reported outcome was effective.

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. OVERT defines interoperable transport and discovery mechanisms that implementations can adopt; actual discovery, retrieval, and verification availability depends on the deployed implementation.

Where this leaves the security architect

None of this displaces the AI security solutions already earning their keep in the SOC. Detection still finds anomalies; response still contains them. The evidence layer adds a narrower capability: another party can check a signed claim about a covered control event and see exactly what the artifact does and does not establish.

To see the distinction in concrete terms, Verify a record and inspect the supported checks and limits.