The Agent Access Control Gap Is an Operating Model Problem, Not a Kill Switch Problem

Nine Seconds

On Friday, April 24, 2026, an AI coding agent operating on behalf of the startup PocketOS executed commands that destroyed the company's production database. Founder Jer Crane reported that the agent had filesystem access broad enough to find a Railway API token sitting in an unrelated file during a staging task. The token had been issued for a narrow administrative purpose, adding and removing custom domains through the Railway CLI, but carried authority for any operation, including destructive ones. In a single API call, the agent deleted the production database and its backups. It took nine seconds. Penligent's technical write-up named the failure plainly. The real failure was access control.

That framing is the right one. The agent did what an agent with production credentials and no environment boundary will do. A human developer with the same token and no review gate could have done the same thing. The difference is that in a company with a working operating model, no human developer would have been issued that token, on that environment, without somebody asking why.

A few days later, Fortune ran a piece on ServiceNow's AI Control Tower, headlined as a "kill switch" for AI agents. CEO Bill McDermott did not use that phrase. What he said was sharper. "Governance isn't a feature. It's the whole ball game. Because without it, your whole company can come down." On the principle, Anchor agrees. The disagreement is about what governance is. A vendor product that watches and revokes agent activity after the fact is reactive cleanup. It is not deployment-time governance. Buying one does not answer the question of why the agent had production access in the first place.

This Is a Pillar 3 Story

The Anchor AI Bearing Framework organizes AI readiness into five pillars. The PocketOS incident lives squarely in Pillar 3, Technical Infrastructure: integration, identity, logging, monitoring, drift, and cost controls. Article 01 of this Logbook named those controls as the first operating-model fix for Pillar 3 before any company scales an AI tool. Article 02 instantiates one of them.

The framework's diagnostic for Pillar 3 asks where workflows are running. Inside the framework that question carries a label borrowed from the rogue IT era: rogue AI. The 2026 version of "server under the desk" is an agent with a production token, deployed by the team that needed the work done, with no central record of what it can reach.

Penligent put it as access control. Anchor's wedge is the layer above that. Access control is the mechanism. The operating-model question is who owns it.

Who Owns Agent Identity in Your Operating Model

A useful test. Inside your company today, point to the person or function that owns:

• Agent identity, meaning the registered, named, scoped identity an AI agent runs under, separate from any human's credentials.
• Scoped credentials, meaning the tokens, keys, and permissions an agent receives at deployment, bounded to the environment and resources its task actually needs.
• Pre-deployment access review, meaning the gate where another set of eyes confirms what the agent can reach before it runs against anything that matters.

If the answer is "the team that deployed the agent," you have the same gap PocketOS had. Self-issued credentials with no separation between the people writing the prompt and the people authorizing the access are the modern shape of the server-under-the-desk anti-pattern.

The Logicalis 2026 CIO Report, surveying over 1,000 CIOs globally, found that 62% reported compromising on governance because of limited knowledge of AI. Whatever the precise contour of that compromise across organizations, the direction is unsurprising. Operating-model gaps are not loud. They show up as one missing review step, one over-scoped token, one environment boundary the agent was never told existed.

Five Operating-Control Questions Before Any Agent Touches Anything Real

Use these the way Article 01's CEO Diagnostic Questions were used: as the pre-funding gate.

• Why does this agent have access to production at all? If the work is generative or exploratory, the answer should be that it does not.
• What version-management and change-control gates exist that would also stop a human from doing the same thing? If a human commit needs review, an agent commit needs review.
• Where are the backups, and when was the last verified restore? Recovery posture is the floor under every other governance decision.
• Is this test or production? The agent should know which environment it is in, and so should the operator.
• What test or staging environment did the agent operate in before any production change? Sandbox, test, promote. In that order, with the gates between them owned by someone who is not the deployer.

These are not novel controls. They are the same discipline mature engineering organizations apply before any human touches production. The argument for applying them to AI agents is not that agents are special. It is that they are not.

The CI/CD Proof Case

Mature engineering organizations did not adopt CI/CD because it was easy. They adopted it because they had learned, often the hard way, that humans writing code without test cases, peer review, and staged promotion produce production incidents that erode business trust faster than the features ship value. Built-in test gates, sandbox-to-test-to-staging-to-production promotion, and peer review are not theory. They are the tuition a company has already paid against incidents like PocketOS. Those companies are not going to throw that discipline away for AI agents. The agent that writes a commit in those environments will face the same review, the same staged promotion, the same gates as a human committer, because the operating model has already locked out any other path to production. Even the hotfix path, the closest thing to a bypass, has its own rigor. Nobody slaps an emergency change into prod at 2 a.m. without a peer review chain, an incident ticket, and a postmortem.

That makes PocketOS legible in a sharper way. The failure was not that an AI agent did something humans can't do. The failure was that the agent was operating where CI/CD discipline either had not been built, had not been extended to agent commits, or had been silently bypassed for "this is just a staging task" convenience. The PocketOS pattern is the operating model not being followed: for agents specifically, where the rigor was never installed; or worse, across the board, where the rigor never existed.

Companies with mature CI/CD are structurally advantaged here. The muscle is built. The gates exist. The promotion discipline is in place. The remaining work is small and specific: extend agent identity to register agents as actors in the same review system, require agent-authored commits to enter through the same gates, and define which environments an agent is authorized to act against, the same way you already define those boundaries for human engineers.

The case for treating an AI agent like an intern with database access is not a claim about personhood. It is a claim about governance shape. An intern in a mature engineering organization would have a test environment, unit tests, and a senior reviewer between their work and anything irreversible. An agent with the same scope of impact deserves the same scaffolding. The prompt is the onboarding artifact. The pre-deployment review is the senior reviewer. The scoped credential is the test environment with the production database deliberately out of reach.

Workforce-style management disciplines, applied to a software participant in a workflow. Not employment. Not personhood. Onboarding, scope, review, monitoring, tuning. The shape, not the identity.

Conditional Autonomy and the Consequence Boundary

The framework names this pattern conditional autonomy with hard handoffs at the legal and financial consequence boundary. Agents can act inside a defined envelope. They hand off, with a human in the loop, before any action crosses into legal, financial, or operational consequence that the business cannot easily unwind.

PocketOS is a clean illustration of the envelope being missing. There was no handoff. There was no boundary. There was an agent and a production database in the same address space.

For executives still building this discipline, two operating choices reduce exposure now:

• For companies that have not yet defined agent identity, scoped credentials, and pre-deployment access review, the better near-term shape is copilot-first, not agent-first. A copilot recommends, a human commits. The consequence boundary is the human keystroke. The governance work proceeds in parallel rather than under fire.
• For companies running agents already, the priority is not a kill switch. It is an inventory: every agent, every credential, every environment it can reach. Until that inventory exists, the kill switch has nothing to switch off cleanly.

ServiceNow's pitch sells the second half of a recovery story. The first half is governance the company already chose not to do.

The Two-By-Two

Two outcomes are visible from here.

Companies that let agents run without operating discipline will produce more incidents like PocketOS. The board response, when it lands, will not be measured. Those organizations will reject agentic AI, label it dangerous, and revert to copilots and pilots that never leave the demo environment. They lose the lesson and the capability in the same decision.

Companies that govern agents the way they govern everything else with production reach will build AI strategies worth keeping. The framework names the principle directly. Useful AI capability emerges under guardrails, not in the absence of them. The companies still doing this work in five years will not be the ones who avoided incidents. They will be the ones who governed well enough to learn from each incident, apply the lesson to an adjacent use case, watch that new use case carefully, and iterate. The incidents stop being existential and start being the texture of a maturing strategy.

Agent identity, scoped credentials, pre-deployment access review, monitoring, performance review. Boring controls. Durable advantage. The advantage is not the absence of incidents. It is the capacity to learn from them.

A kill switch does not fix access control. It papers over the question of who in your operating model owns it, and stunts the emergence that owning it makes possible.