Runtime Governance Series
Why 'Impossible to Control' AI Doesn't Mean You Can't Govern It: 3 Steps for CISOs
Advanced AI may be impossible to fully contain, but agents can still be governed at runtime through per-action controls, approval gates, and signed evidence
Published on
Why 'Impossible to Control' AI Doesn't Mean You Can't Govern It: 3 Steps for CISOs
Computer scientists have proven that a superintelligent system cannot be fully contained. That is the case for runtime AI governance, not against it: you constrain what an agent does instead of trying to predict what it will do.
A board-level question is now landing on the CISO’s desk: if researchers have formally shown that advanced AI cannot be controlled, why are we deploying agents at all? The honest answer is that the proof is real, and it points the opposite way from the panic.
You cannot predict everything a capable agent will do. You can still decide, action by action, what it is allowed to do. Those are different problems, and treating them as one is the mistake. This piece separates them, then gives CISOs three steps to govern agents they will never fully predict.
The control problem is real, and most CISOs draw the wrong conclusion from it
The impossibility results are settled, and they are narrower than the headlines suggest. They constrain prediction, not enforcement.
In 2021, six computer scientists led by Manuel Alfonseca proved in the Journal of Artificial Intelligence Research that total containment of a superintelligence is, in principle, impossible. The argument reduces to the Halting Problem: strictly containing such a system would require simulating a program that cannot be simulated. Roman Yampolskiy reaches a similar conclusion, arguing that the controllability of advanced AI has never been formally established.
Read the proofs precisely. They rule out perfectly predicting or verifying the behavior of an arbitrary program in advance. They do not rule out stopping a specific action at the moment it is attempted, and they do not preclude practical safety work on specific, bounded systems. That narrower scope is the whole opportunity.
Two ideas usually get fused into one. Keep them apart. Predictive control means knowing in advance everything a system will do and proving it safe; in the general case that is undecidable. Runtime governance means evaluating each concrete action against a policy as it happens, then allowing, limiting, or stopping it; that is a bounded check you can run inline, in the moment.
For a CISO, the consequence is freeing: you are not being asked to solve the Halting Problem. You are being asked to put a gate in front of each action. One is impossible. The other is routine engineering.
Step 1: Govern actions, not predictions
Stop trying to forecast the agent and start gating its actions. The unit of governance is the action, not the model and not the deployment.
Most of what gets sold as “AI governance” today is observability: dashboards, traces, and telemetry that tell you what an agent did. None of it stops anything. OpenBox draws the line as the difference between a security camera and a lock on the door. The camera is necessary and insufficient.
The timing is the problem. Risk in agentic systems emerges during execution, not at deployment. By the time an unauthorized data transfer surfaces in a trace, the data has already left. A model is assessed once and then runs; an agent reasons, calls tools, and chains decisions at machine speed, and each link is a fresh chance to do something it should not.
So the first step is a reclassification, not a purchase. Treat every tool call, API request, and inter-agent message as a governable event with its own decision point. Once the action is the unit, the question stops being “is this agent safe?” and becomes “is this action permitted, right now, under our policy?” That second question has an answer.
Step 2: Enforce policy at runtime, before the action executes
Put a policy decision in the path of every action, and make it block by default when a rule is violated. This is where the impossibility result stops mattering.
OpenBox wraps the agent so that every tool invocation, workflow step, sub-agent call, and inter-agent message is evaluated against the agent’s policies, guardrails, and behavioral rules and resolved into one of four governance decisions before the action runs:
ALLOW: the action proceeds.
REQUIRE_APPROVAL: a human signs off before it continues.
BLOCK: the action is refused.
HALT: the session is stopped.
Limits short of a hard block matter most for capable agents, because you rarely want a binary yes or no. You want “yes, but read-only,” “yes, but not that customer’s records,” “yes, but rate-limited.” In OpenBox those limits live in guardrails and policies rather than in a separate decision: a guardrail can redact or transform a payload before it passes, and an OPA policy can permit an action only within a defined scope. A pure allow-or-deny gate forces you to either over-permit or break the workflow. This scoping layer is what makes runtime governance usable.
Policies are written once and applied across agents, expressed as policy-as-code (OpenBox uses OPA policies alongside guardrails and behavioral rules), and enforced before execution rather than reconstructed afterward. The check sits inline, ahead of the action, so the gate adds a bounded step rather than a bottleneck. You are not predicting the agent. You are checking one concrete action against a rule and deciding in the time it takes to make the call.
Step 3: Make every decision provable, not just logged
A log a vendor can edit is not evidence. Attestation is. This is the part that turns governance from an internal comfort into something a regulator or board will accept.
When someone asks “who authorized this agent action, and under which rule,” a reconstructed application log is a weak answer, because nothing about it proves it was not changed after the fact. OpenBox closes that gap by hashing each session’s events with SHA-256 into a Merkle tree and signing the tree’s root, producing a proof certificate that shows the record was not altered. Signing runs through AWS Key Management Service using ECDSA NIST P-256 by default, or through your own external attestation service, such as a Trusted Execution Environment.
Two details make this useful rather than ceremonial. Blocked decisions are recorded as governance events and folded into the same signed Merkle tree, so the trail captures denials, not just the successful calls. And because the structure is a Merkle tree, you can prove what one agent did against one data source without exposing every other event in the session. The proof is built when the session completes, off the action’s critical path, so it never slows the agent down.
This maps onto law, with one caveat worth stating precisely. Under a provisional political agreement reached on 7 May 2026, EU lawmakers agreed to defer the AI Act’s high-risk obligations for standalone Annex III systems to 2 December 2027. As of 15 June 2026 that amendment is not yet adopted: the file cleared the Parliament committees on 2 June 2026, but the plenary vote, Council adoption, and Official Journal publication are all still pending, expected to conclude before 2 August 2026. Until it enters into force, the original deadlines in Regulation (EU) 2024/1689 remain legally binding. If adopted, the change would move the deadline; it would not reduce the underlying obligations, three of which speak directly to what runtime governance does.
How runtime governance helps address three high-risk EU AI Act requirements:
EU AI Act provision | What it requires | Runtime governance capability |
|---|---|---|
Article 14 Human oversight | High-risk systems must let people effectively oversee them and intervene or interrupt operation. | A pre-execution gate with REQUIRE_APPROVAL, BLOCK, and HALT, plus human-in-the-loop sign-off on high-stakes actions. |
Article 12 Record-keeping | Automatic logging of events across the system’s lifetime, for traceability. The Act sets the outcome, not the method. | A tamper-evident, attested audit trail that records every action and verdict and proves it was not edited. |
Article 15 Accuracy, robustness, cybersecurity | High-risk systems must resist misuse and stay resilient against attempts to alter their behavior. | Per-action evaluation against policies, guardrails, and behavioral rules, with stricter controls for lower-trust agents, adds a runtime layer of resilience. It supports, but does not replace, the design-time accuracy and resilience testing that Article 15 requires. |
Two honest caveats. No tool “guarantees compliance,” and the EU AI Act does not mandate Merkle trees or any specific cryptography. And each of these articles reaches past any runtime tool: Article 14 expects trained, competent human overseers, Article 12 sets log content and retention rules, and Article 15 calls for design-time accuracy and resilience testing. Runtime governance supplies enforcement and defensible evidence for part of that work. It is not a compliance product for all of it.
What runtime AI governance gives security leaders
The uncontrollability proofs are not a reason to stop deploying agents, and they are not permission to pretend you can predict them. They are the case for moving control to where it still works, which is runtime. Govern each action, enforce policy before execution, and keep proof that stands on its own.
That is what runtime AI governance is for, and it is what OpenBox is built to do. See how OpenBox’s policy enforcement gives CISOs real control over AI agents: book a demo.
Frequently asked questions
Can AI be controlled?
Not in the strong sense. Computability results show that perfectly predicting or fully containing a superintelligent system is, in principle, impossible. But controlling individual agent actions at runtime is a different, tractable problem: you evaluate each action against a policy and allow, limit, or stop it as it happens.
What is the difference between AI observability and AI governance?
Observability records what an agent did through traces and dashboards. Governance decides what an agent may do and enforces it. Observability is a camera; governance is a lock. A camera helps you investigate a breach after the fact, while a lock prevents the action that would cause it.
What are OpenBox’s runtime governance decisions?
OpenBox evaluates each agent action against its policies, guardrails, and behavioral rules and returns one of four governance decisions: ALLOW, REQUIRE_APPROVAL, BLOCK, or HALT. Finer limits such as read-only access or a restricted data scope are applied through guardrails and policies rather than a separate decision, so you avoid choosing between over-permitting and breaking the workflow.
Does runtime governance make an AI system EU AI Act compliant?
No single tool makes a system compliant. Runtime governance is designed to support specific high-risk obligations: human oversight under Article 14, record-keeping under Article 12, and the accuracy and cybersecurity requirements under Article 15. It supplies enforcement and attested evidence, but compliance depends on your full process, documentation, and risk management.
What is a cryptographic audit trail for AI agents?
It is an agent activity log you can prove was not altered. OpenBox hashes each session’s events with SHA-256 into a Merkle tree and signs the root, producing a verifiable proof certificate. Blocked decisions are folded into the same signed tree, so the record captures every decision rather than only the successful calls.
Sources
Alfonseca, M., Cebrian, M., Fernández Anta, A., Coviello, L., Abeliuk, A., & Rahwan, I. (2021). Superintelligence Cannot be Contained: Lessons from Computability Theory. Journal of Artificial Intelligence Research, 70, 65-76. https://jair.org/index.php/jair/article/view/12202 Accessed 15 June 2026.
Yampolskiy, R. V. On Controllability of AI. arXiv:2008.04071. https://arxiv.org/abs/2008.04071 Accessed 15 June 2026.
OpenBox AI and Mastra Bring One-Line Runtime Governance to Every TypeScript Agent (4 May 2026). PR Newswire. https://www.prnewswire.com/news-releases/openbox-ai-and-mastra-bring-default-runtime-governance-to-every-typescript-agent--as-enterprises-brace-for-an-agentic-security-reckoning-302759944.html Accessed 15 June 2026.
OpenBox AI Launches First Enterprise AI Trust Platform, Backed by $5M Seed Round (31 March 2026). OpenBox (openbox.ai). https://www.openbox.ai/blog/openbox-ai-launches-first-enterprise-ai-trust-platform-built-for-everyone-backed-by-5m-seed-round Accessed 15 June 2026.
Attestation & Cryptographic Proof. OpenBox (docs.openbox.ai). https://docs.openbox.ai/administration/attestation-and-cryptographic-proof Accessed 15 June 2026.
OpenBox platform overview. OpenBox (docs.openbox.ai/llms.txt). https://docs.openbox.ai/llms.txt Accessed 15 June 2026.
Regulation (EU) 2024/1689 (EU AI Act), Articles 12, 14, and 15. EUR-Lex. https://eur-lex.europa.eu/eli/reg/2024/1689/oj Accessed 15 June 2026.
Digital Omnibus on AI. European Parliament, Legislative Train Schedule. https://www.europarl.europa.eu/legislative-train/package-digital-package/file-digital-omnibus-on-ai Accessed 15 June 2026.
