What a Real AI Supervisor Actually Requires
AI agents move in discrete steps, and the question isn't how fast you catch a problem - it's how many unsupervised steps an agent takes before anyone is in a position to catch anything. Control engineering solved this in 1987.
Control engineering solved this problem decades ago. AI is only now discovering why it matters.
Last time, I left one thread hanging on purpose. Everything in that piece about open-loop and closed-loop assumed a system you can watch continuously - sample it fast enough and you catch the drift before it matters.
AI agents mostly don't work that way. They move in discrete steps, one tool call, then another, then another, and the question that actually matters isn't how fast you catch a problem. It's how many unsupervised steps an agent gets to take before anyone is even in a position to catch anything at all.
There's a decades-old branch of control engineering built for exactly this, and it comes with a word I think deserves wider use: supervisor.
Supervisory control theory for discrete-event systems
That discipline goes back to a 1987 framework by Peter Ramadge and W. Murray Wonham, built originally for factory automation - sequencing machines on a production line so they never enter an unsafe or undefined state.
In this framework, a system - the "plant" - generates a sequence of events, one after another. The first real move Ramadge and Wonham make is splitting those events into two kinds. Controllable events are ones a supervisor can prevent from happening - it can reach in and disable them before they occur. Uncontrollable events are ones the supervisor can only observe - it has no power to stop them, the plant does what it does. Almost everything interesting in the theory comes from that one distinction.
A supervisor, then, isn't a thing that reacts to bad outcomes. It's a function. After every sequence of events it's observed so far, it decides which subset of the controllable events gets enabled for the next step. The elegant part - and the part I think this publication has been circling without the vocabulary for four articles now - is what the theory calls the supremal controllable sublanguage. In plain terms: the least restrictive supervisor that's still provably safe. Not the most locked-down version that happens to work. The most permissive one that's provably still safe. That's not a loose metaphor for semi-autonomous. That's the literal, formal definition of it, arrived at independently, decades before anyone was writing about AI agents.
Where this gets tested, right now
I want to be direct about something. The clearest current example of this problem isn't a hypothetical, and it isn't some small vendor's failure. It's sitting inside the protocol most of the AI agent ecosystem now runs on.
In April 2026, security researchers at OX Security disclosed a systemic flaw in the Model Context Protocol SDK - the standard originally designed by Anthropic and, since being donated to the Linux Foundation's Agentic AI Foundation in December 2025, now the cross-vendor default, adopted by OpenAI, Google, and Microsoft among others. The flaw wasn't a coding mistake. It's how the protocol's STDIO interface was designed to work: any command passed to it executes, whether or not it originates from a legitimate MCP request. Anthropic confirmed the behavior was intentional and declined to change the architecture at the time, placing the responsibility for sandboxing and validation onto whoever implements it. The exposure was enormous - over 150 million downloads across the affected packages, an estimated 200,000 vulnerable server instances. By the NSA's count, more than 40 CVEs were filed against MCP implementations between January and April 2026 alone, something close to one every four days.
Here's where the formalism actually earns its keep. Every event in the Ramadge-Wonham framework is either controllable or uncontrollable - the theory doesn't allow a third category. MCP's core protocol effectively had no controllable events at all. Every tool call was treated the way an uncontrollable event is treated: something that simply happens once triggered, with nothing positioned to disable it first. That's not a Kill Switch problem, and it isn't really an Approval problem either. It's a Permission problem at the most basic level the theory has - there was no controllable event set to begin with, which means no supervisor, however well designed, could have acted on this system as shipped.
You cannot supervise a plant that hasn't defined anything as stoppable.
There's another complication supervisory control theory predicts, and MCP has it too. The theory assumes a supervisor can see every event clearly. Real systems often can't - a supervisor might only get a partial, ambiguous view of what actually happened. This is called supervisory control under partial observation, and it's a genuinely harder problem. A supervisor that can't reliably tell two events apart is mathematically forced to become more conservative - disabling more than necessary or catching less than it should. Imagine a supervisor watching a factory through frosted glass. And the partial observation problem shows up here as the actual identity gap I've been tracking since article two: a gateway that can't tell which agent, which credential, which session generated a given tool call is, formally, a partial observation supervisor - structurally less capable, by the same math.
Reality check: the supervisor that was never built - and the one now being bolted on
The NSA's own May 2026 security guidance for MCP asks developers to log every tool invocation with its exact parameters and the identity behind it, feed that telemetry into existing security monitoring, and treat every MCP server as an untrusted third party by default. That's a description of a supervisor that didn't exist yet in most deployments, built after the fact by security teams, because the protocol itself didn't include one. Worth noting: as of this writing, the protocol's governing body is closing part of that gap directly - a new specification finalizing July 28, 2026 adds Enterprise-Managed Authorization, already adopted by Anthropic, Microsoft, and Okta.
How do we close this gap?
A real fix means assembling four distinct layers, not picking one tool and calling it done.
Permission has to come first, and it has to sit in front of MCP itself, not inside it. This is an allowlisting gateway or proxy - something that intercepts every tool call before it reaches the model's execution path and checks it against a defined, enumerable set of allowed actions, refusing everything outside that set by default. This is the actual Ramadge-Wonham supervisor. Without it, nothing downstream matters.
Approval is a separate layer - routing the subset of actions that are permitted but still consequential, a financial transaction, a production deployment, a data deletion, to a human or a second system for sign-off before they execute. Useful and real. Just not a substitute for Permission.
Audit Trail is the record - every action tied to a specific identity, a specific decision, and a specific timestamp, held somewhere durable enough to survive the system it's watching.
Kill Switch, done properly, is the fourth layer. Industrial engineering already has a rigorous name for it: a Safety Instrumented System, governed by standards like IEC 61508 and IEC 61511. A real SIS isn't a button someone can press. It has a clearly defined safe state the system falls into. It has a proven response time, tested and certified. And critically, it has to be independent from the system it's monitoring - built on separate hardware and logic. Almost nothing currently described as an AI agent's "kill switch" meets any of those three conditions. Most of them are a config flag inside the same system they're meant to stop.
Where this leaves things
None of this - the supervisor, the enumerated permissions, the properly independent safety system - means much inside a company of any real size without one more piece underneath all of it: a way to say precisely which agent, which identity, which credential, was the one taking the action in the first place.
Companies solved that exact problem for humans decades ago. It has a name, and it's not new. That's next.