A control nobody can prove is not a control
Naming a control is easy. Proving it holds is the hard part. Every Apeiris control carries three proofs: is it configured, does it survive an attack, and what artifact says so on an ongoing basis.
This is the line I kept coming back to while building the control corpus, and it became the rule the whole thing is organized around. It is easy to write down a control. "Filter the agent's outbound traffic." "Require a human to approve irreversible actions." Anyone can produce that list. The hard part, the part most matrices skip, is showing that the control is real: that it is switched on, that it survives contact with an actual attacker, and that you can prove both to someone who was not in the room.
So every control carries three separate proofs. I think of them as three different questions, because they fail in three different ways.
The three proofs
Is it configured? This is the design check. It asks a yes-or-no question about how the system is built: is the egress filter set to default-deny, is the approval gate enforced by the platform rather than requested politely of the model, is agent memory volatile by default. A design check is cheap and it catches the most common failure, which is that the control was never actually turned on. But it has a blind spot: a thing can be configured exactly right on paper and still fold the moment someone leans on it.
Does it hold under attack? This is the runtime test, and it is the one control programs most often underweight. It does not ask whether the control exists; it asks whether it works when an adversary is actively trying to defeat it. You replay a stolen token after it expires and confirm it is rejected. You prompt-inject the agent toward an action the user never authorized and confirm the gate fires. You open a booby-trapped repository and confirm the agent does not execute it. The difference between a design check and a runtime test is the difference between reading the lock's specification and trying to pick it.
What proves it on an ongoing basis? This is the evidence, the artifact that someone who was not there, an auditor, an investigator, a regulator, can look at later and trust. A broker's token-issuance log. An append-only approval record. A per-release evaluation report with a go or no-go decision. Evidence is what separates "we are confident this works" from "here is the record that shows it worked, on this date, for this action." Without it, a control is a belief, not a fact.
You need all three because each one covers the others' blind spots. Configured-but-untested fails the first time it is attacked. Tested-once drifts out of compliance the next time the model or the prompt changes. And both of those are invisible to anyone outside your team unless there is an artifact they can hold.
One control, all three proofs
Take short-lived, task-scoped keys, the control that says an agent should hold no permanent secret and instead get a credential that is scoped to one job and expires in minutes.
- The design check scans the agent's host, environment, repository, and config for any credential whose lifetime is longer than your policy allows, and asserts the count is zero. It is checking that the control is configured: no long-lived secrets lying around.
- The runtime test takes a captured token and replays it after it has expired, then again against a tool outside its scope. Both must be rejected. It is checking that the control holds: a stolen credential is genuinely useless, not just supposed to be.
- The evidence is the broker's issuance log, every token, which agent asked for it, what scope it got, for how long, which is also the kind of record the EU AI Act's Article 12 calls for (whether it satisfies the obligation depends on the system's classification and how it's implemented, a question for counsel). It is the artifact that proves the control kept working, call after call.
Three questions, three answers, one control you can actually stand behind.
Proof gives you numbers, not vibes
One thing the runtime test does that is worth calling out: it turns "is the agent safe?" into a measurement. For prompt-injection defenses, the natural metric is an attack-success-rate, the percentage of injection attempts that get through, run with an evaluation suite before and after the guardrail. In practice, you stop arguing about whether the guardrail is good and start comparing a number against a threshold. A demo that looks clean tells you nothing. A red-team report that shows the measured rate falling below a predefined launch threshold, against multi-turn scenarios, tells you something you can ship on, or block a launch on.
That is the same instinct behind gating a release on continuous validation: you do not test once and call it done, because an agent's behavior can change whenever the model, prompt, tools, or configuration change. You re-run the proof on every release and block anything that regresses. The proof is not an event; it is a habit.
Why this is the part that will matter most
Validation is where security quietly turns into compliance, and that boundary is about to get a lot of traffic. The EU AI Act frames risk management as a continuous duty and requires the kind of logging that only the evidence facet produces. And readiness is not there yet: in a 2026 CSA survey, 84% of organizations doubted they could pass an audit of their agents' behavior. The gap that statistic describes is precisely the gap between having controls and being able to prove them.
That is why I refused to ship a corpus that only names controls. A list of controls reassures you. A control with a design check, a runtime test, and an evidence artifact lets you answer the only question that matters when something has gone wrong, or when someone official is asking: can you show it? If you cannot, on the day it counts, then for every practical purpose the control was never there.
A note on how to read the layer deep-dives that follow: each calls out the single most useful test for a control, to keep the prose moving. The corpus itself carries the full set, the design check, the runtime test, and the evidence artifact for every control. Those specifics live in the data, not the essays.
Every control carries all three proofs. You can see them, per control, across the twelve domains at apeiris.ai.