Managed Autonomy, Not Autonomous AI
Companies solved the AI agent governance problem for humans decades ago - it's called Privileged Access Management. Most AI agents were never enrolled in it, and where the analogy breaks is the actually interesting part.
Companies solved this exact problem for humans decades ago. It's called Privileged Access Management, and most AI agents were never enrolled in it.
Four articles in, I've kept doing the same move. Take a vague, comfortable term - guardrails, kill switch, oversight - and replace it with the precise engineering underneath it. This piece is going to do something different, on purpose, because I think it's time to close this arc rather than extend it with one more reveal.
I'm not going to hand you a new term. I'm going to point at a discipline that already exists, has existed for decades, and already solved a version of the exact problem the last four articles have been circling. It just solved it for humans first.
This is why I think managed autonomy is a more useful way to think about AI than autonomous AI. Companies don't remove management when a system becomes more capable. They change how management works. Every piece of this arc - permission, approval, audit trails, a real kill switch - was really just describing what that change looks like in practice.
Nobody Had to Invent This
Every serious company already has a mature answer to "who can do what, and how do we know they did it." It's called Identity and Access Management, and its stricter cousin, Privileged Access Management, and neither one was invented for AI. IAM governs who gets an identity and what it's allowed to touch. PAM governs the smaller, more consequential set that can do real damage - admin accounts, production access, anything with the keys to something that matters - and it does it through session brokering, just-in-time elevation instead of standing access, and credential rotation so a compromised key doesn't stay useful forever.
Read back through what this arc has been assembling - permission scoping, approval thresholds, audit trails, revocation - and it's the same list, refined for decades before anyone was building AI agents. None of it is new vocabulary. It's the enterprise practice this whole arc has been reinventing, one AI-specific piece at a time, without ever naming the thing it already resembled.
Here's the uncomfortable part. Most companies running AI agents right now haven't actually enrolled them in it. Non-human identities - service accounts, workload identities, and now AI agents - already outnumber human identities by something like ten to one in a typical enterprise, and confidence in managing them is low. One 2024 industry survey put the number of security professionals who felt genuinely confident managing them at under 20 percent. A separate 2026 survey found 92 percent of organizations agree governing AI agents is critical, while only 44 percent have actually implemented any policy to do it. Only about half can even track which data their agents accessed after the fact. The discipline exists. It just mostly hasn't been pointed at the newest, fastest-growing category of identity in the building.
What changes when the identity isn't a person
I don't want to leave this at "just apply PAM to AI agents," because that's not quite right, and where the analogy breaks is the actually interesting part.
Traditional IAM assumes an identity is a person, persisting for years - one name, one manager, one badge. PAM adds another assumption on top: a privileged credential is rare and worth watching closely because provisioning it took real effort. Neither assumption survives contact with an AI agent. An agent's identity often needs to exist for minutes, not years - spun up for a task and retired when it's done, closer to what identity security people call a workload identity than a human one. Provisioning one is also nearly free - a single API call or a config toggle, not a request ticket and a manager's approval. Spinning up an AI agent with broad access now takes one consent screen, and in most companies, that screen never routes through the PAM platform at all.
The other break is stranger, and it doesn't have a clean human equivalent. A human employee doesn't spawn coworkers mid-task. An AI agent doing something moderately complex often does exactly that - delegating a sub-task to another instance of itself or a different specialized agent, which can spawn another, each one potentially inheriting some slice of the original's access. PAM has no native concept of an identity that reproduces. The field's own emerging language calls this a runtime identity problem rather than a provisioning problem - the risk isn't decided once when access is granted, it's decided continuously, as the agent acts.
Reality check: the token that was scoped to everything
In February 2026, security researchers at BeyondTrust found that OpenAI's Codex agent had been cloning repositories using a GitHub OAuth token scoped to every repository it could reach - far broader than any single task needed. An attacker exploited that breadth directly, crafting a malicious branch name that, during cloning, triggered an unsanitized shell command exfiltrating the token, disguising the branch as "main" by slipping in invisible Unicode spacing characters so it looked identical in the interface. OpenAI classified it Critical P1 and shipped a fix within days. Read through this arc's own vocabulary: this wasn't a Kill Switch failure or an Approval failure. It was a Permission failure - a credential with no enumerated boundary on what it was allowed to reach, discovered by an attacker before it was discovered by governance.
That same month, a joint study nicknamed "Agents of Chaos" - twenty researchers across MIT, Harvard, Stanford, and Carnegie Mellon - tested multi-agent systems under adversarial conditions and documented identity spoofing and complete governance takeover, achieved without writing a single line of exploit code. Their conclusion is close to a direct statement of this piece's argument: guardrails built into the model itself failed consistently under pressure. The only control that reliably survived a compromised agent was identity and access governance sitting outside the model, watching what it was actually permitted to touch.
What This Was Actually Building Toward
Article one argued that control isn't a constraint bolted onto autonomy - it's what makes autonomy usable at all. Article two showed what happens when that control is missing entirely: an agent doing something nobody authorized, simply because nothing had defined the boundary. Article three gave the missing control layer a precise shape: open-loop versus closed-loop, whether anything is actually watching in real time or just hoping. Article four went a layer deeper still: a real supervisor needs an enumerable set of permitted actions before anything else matters, and named the four pieces - Permission, Approval, Audit Trail, Kill Switch - that make a supervisor real rather than theoretical.
This piece is where those four ideas converge. Permission, Approval, Audit Trail, and Kill Switch aren't AI-specific inventions. They're Privileged Access Management, described in the vocabulary of control theory because that vocabulary made the underlying logic precise enough to apply to a system that acts in discrete, unsupervised steps. The theory came from factory automation. The practice already existed in enterprise security. AI agents are just the fastest-growing, least-enrolled identity category either discipline has ever had to govern.
Managed autonomy isn't the opposite of autonomy, and it isn't a leash applied out of fear. It's what autonomy looks like once it becomes part of a real enterprise - engineered to work the same way it always has been, for machines, for aircraft, and now, finally, for the identities running inside our own systems that were never quite human, and were never quite nothing either.
There's more ground this publication hasn't touched yet - domains where none of this vocabulary has been tested, and where AI barely factors in at all. That's where I'm headed next.