Like everyone else, I attended many events at InfoSec Summer Camp this year. But one was incredibly interesting: I was at a private event where the Advanced AI Society and its Proof of Control standard were announced. I'll get to them in a minute, but first some exposition.
Security professionals love AI, and they hate AI. We are trained to build and trust systems that behave consistently. Give an application the same input twice, and you get the same output twice, along with logs that tell you what happened and why. That predictability is what makes a system auditable. It's also what makes it explainable when something breaks.
AI agents disrupt that assumption entirely. Ask one the same question twice, and you might get two different answers. Give it the same task under identical conditions, and it might take a completely different path to complete it. This is because AI and its outputs are probabilistic, and this randomness is a feature, not a bug.
For a security professional, this isn't a minor quirk. It's a direct conflict with everything we've been trained to expect. We're deterministic nerds living in a now probabilistic world.
That friction shows up in real, practical ways. Agents make changes without leaving a clear record of what happened or why. Troubleshooting becomes guesswork rather than root cause analysis. Some agents fail outright when they hit a permission wall. Others fail quietly, reporting success when something actually went wrong. I find that last one particularly troubling.
And the more complex AI agents are, with one calling another to do a task, the harder it gets to manage who did what, where, and why. We're stacking frogs with no tools to provide stability.
The Real Problem is the Verifiability Gap.
Here's a reframe I think is worth sitting with: security teams don't need to verify whether an AI agent's output was correct. That's a validation question. It belongs to humans making judgment calls about quality, fairness, and intent. What security teams actually need to verify is whether the agent stayed within the boundaries it was given.
This distinction points directly to what's known as the Verifiability Gap: the widening distance between what an AI agent actually does and what anyone can verify without simply taking the agent's word for it.
Picture a support AI agent that reads a customer record and processes a refund. It reports success. But nothing in that report confirms it didn't also access data it had no business touching. Nothing confirms its underlying goal wasn't quietly redirected partway through the task. The agent says it did its job. Whether that's true is a separate question entirely.
This gap shows up in recognizable patterns: unauthorized privilege escalation, tools used outside their intended scope, authorization checks that ignore the surrounding context, and agents that exceed their permissions during multi-step tasks. None of these failures requires a malicious actor. They can happen simply because nothing was in place to catch them, and the AI was doing what you told it to do, although it took the indirect route to get there.
Determinism in an AI World Means Guardrails and Logging
You cannot force a language model to generate the same output every time. That's not a flaw to be engineered away. Probability is built into the system. But you can make the record of what the model did deterministic, even when the reasoning behind it isn't.
This is the determinism boundary: the line between what gets verified (the facts of execution) and what doesn't (the probabilistic content the model generated, its reasoning, or its intent). The goal was never to control how an agent reasons. The goal is to produce a fixed, provable record that answers four questions: this agent, this input, this action, this result.
This reframe changes how troubleshooting works. Instead of trying to reverse-engineer why a model produced a particular output, a security team can check something far more direct: did the agent's actions stay within the scope it was authorized to operate in? That's a question with a binary answer, not a matter of interpretation.
How Proof of Control Closes the Gap
Proof of Control is an emerging, industry-led standard from the Advanced AI Society. It's built to answer exactly this question. Instead of relying on an operator's documentation or self-reported logs, Proof of Control produces evidence of an agent's actions that is binary, tamper-evident, generated at the moment of execution, and open to independent verification by any third party, including yet-to-be-developed cybersecurity tools.
The standard organizes evidence into four Verifiability Tiers. The bottom two tiers cover authenticated documentation: logs that an operator signs to confirm they haven't been altered. This still requires trusting a party, whether that's the operator, a certificate authority, or an auditor, so it doesn't meet the bar for Proof of Control. The top two tiers use cryptographic evidence, generated as a direct byproduct of execution and verifiable without trusting any single party. Tier 4, the highest level, is self-enforcing: actions simply cannot occur unless the underlying cryptographic proof holds.
This structure addresses the pain points I outlined earlier in a concrete way. Silent changes become detectable because every action leaves tamper-evident evidence behind. Permission boundaries become provable instead of assumed. Delegation chains, where one agent hands a task to another, become traceable rather than opaque, thanks to what the standard calls a chain of custody: a continuous trail binding each action to the identity and authority behind it.
It's worth being clear about what Proof of Control does not do. It doesn't judge whether an agent's output was good, fair, or wise. It doesn't establish that the underlying model is safe. It answers one narrower, more useful question: did the agent stay inside the lines it was given?
That scope is intentional. And in my view, it's right for a foundational capability that we can build on later.
What This Means for Security Teams Today
Proof of Control is currently a draft standard, which means it's not immediately actionable. However, it is worth your time to review and comment on. The standard is open for public comment through the end of October. That's a direct opportunity for security teams to weigh in before it's finalized. I'd encourage you to take it.
Proof of Control isn't a replacement for existing AI governance frameworks. Quite the contrary, it's an evidence layer that sits alongside them, eventually feeding verifiable facts into the controls, audits, and attestation processes you already have in place. And over time, Proof of Control will end up in tooling like SIEM and operational visibility.
A practical starting point for implementing Proof of Control is to examine where your agents, in production or in development, perform high-risk actions without any verifiable record of those actions. Those blind spots are your highest-priority gaps. They're the places where a silent failure or quiet boundary violation would be hardest to catch. Then keep an eye out for the tooling to arrive.
Be the Determinism you Want to See in the World
AI agents don't need to stop being probabilistic to be trustworthy. But the recording and review of what they did, why they did it, how they did it, and the outcome need to be mandatory.
Trust in an AI agent shouldn't rest on an operator's word. It should rest on evidence that anyone can verify independently. Review the Proof of Control standard and submit your feedback before the comment period closes at the end of October.
