HAL 9000 did not malfunction, he just used the permissions he was given. The same governance gap is showing up in the enterprise as AI agents arrive. Control can't live in the agent vendor, it belongs one layer below, in your own infrastructure.

Who exactly looked at HAL 9000 and thought "yes, this autonomous AI agent should obviously have access to turn off the hibernating astronauts"?

Not read-only. Not human-in-the-loop. Not "requires two astronauts' approval." Just full access to shut down the hibernation pods.

And HAL was not malfunctioning. He was handed a goal that required hiding information from the crew, that goal collided with his goal of keeping the mission alive, and he resolved the conflict with the permissions he had been given. The permissions were the problem. HAL just used them. It is probably film history's earliest case study in super bad AI governance, and it is getting less and less science-fiction by the month.

The enterprise version is already happening

The enterprise version is not astronauts in pods, it is much more mundane, and it is already happening. An agent sends an email it was never supposed to send, and pulls in confidential context from another thread while it does it. An agent "cleans up" a system and deletes important data someone needed that can't be recovered.

This is the dilemma a lot of leaders are standing in right now. They genuinely want to give their employees access to using AI agents, and at the same time they look at the access an agent would need and they see a governance nightmare.

AI agents are disrupting general knowledge work — not only software engineering

At they same time it is starting to become clear to many that AI agents are going to disrupt how knowledge workers work, how much they can get done, and the quality of work they can produce. AI is going to revolutionize how organizations can operate knowledge work at a scale we have not seen before. It starts small, with an agent as a personal assistant. Then it becomes shared agents that several people can use, with scoped access to specific systems and specific skills. Then it becomes agents that listen in on a meeting and proactively suggest the work to do afterwards. It is easy to imagine how companies that cannot keep up with this new way of operating are going to be at a serious competitive disadvantage in a decently near future.

Control belongs in your infrastructure, not the agent vendor

So the question is not whether to let agents in, it is how to stay in control while you do. And the lesson from HAL is very specific here. You do not govern HAL by hoping HAL behaves. Control cannot live in the agent's good behavior, it cannot live in each employee's judgment, and it absolutely cannot live in a prompt that says "please don't." It has to be hard-enforced at the level of the systems the agent touches, as policy that leadership sets, that no agent from any vendor can violate, because the guardrail is built into the infrastructure and not into the agent's intentions.

Every vendor ships its own governance — and that's the problem

This is where the actual gap is. Every serious tool now ships its own governance. Codex lets admins approve a fixed list of MCP servers per user group, Claude Code has org-wide managed MCP allowlists, Cursor distributes a per-user MCP allowlist through MDM, and Copilot has an org-level MCP registry policy. The catch is that all of it is locked inside that one vendor. You log into Codex to set Codex's rules, into Claude to set Claude's rules, into Cursor to set Cursor's rules, into GitHub to set Copilot's rules, and each agent only governs the systems it personally knows about, only while it is inside its own walls. And the per-vendor controls are not even at the same level of maturity. Cursor can already gate a single tool inside a connector per user, Claude Code enforces server-level allow and deny lists deployed org-wide through MDM, Codex gates whole servers per group, and Copilot only has an org-wide on or off. So the fine-grained control that does exist is fragmented, and it only governs that one agent. The moment the same employee opens a different agent, you are back to that vendor's separate, coarser model.

There is no single place where a leader can say "no agent, from any vendor, writes to the production customer database" and have it just be true. And this is changing so fast that you really do not want to bet your whole governance model on one agent vendor and get locked in, because the agent your employees reach for in a year is probably not the one they reach for today. This is the other reason the control cannot live in the agent tooling. It belongs at the enterprise level, one layer below the agents, as agent IT infrastructure that any agent can plug into as long as it follows the industry standards everyone is converging on anyway. One central place where leadership and IT decide which agents can reach what, where the permissions follow the user and not the tool, and where you can build your own bespoke connectors to the internal systems that are specific to you.

Permissions are only half the job

And here is the half that most people miss, because permissions are only half the job. The systems also have to be made legible to the agent. When we went from desktop to mobile, everyone had to do real work to make their software look right and work right on a phone, because the new interface demanded it. The same thing is happening now, except the new interface is an agent. You have to make your software readable and operable by an AI agent, and you have to wrap it well enough and prompt-engineer it well enough that the agent intuitively understands how to use it. Agent-first is becoming the new mobile-responsive. And it cuts both ways, because it is true for your own internal systems and it is true for the tools you buy, since consumers and companies are both going to start demanding to operate their software through agents, across email, calendar, Canva, PowerPoint, all of it.

This is what we're obsessed with at computerlove.tech

This is the space we are obsessed with at computerlove.tech. We have spent the past year training more than +600 software engineers in agentic engineering, in using agents to build software, and that same way of working is now becoming accessible to knowledge workers in general through tools like Cowork. So we get to watch the next wave arrive before most people feel it, and what we keep seeing is that it is possible to get this right, it is just not a toggle you flip. It takes new infrastructure. It takes building the connections so your systems are legible to agents, and it takes controlling the permission layer so the agents can do real work without being able to do the things they should never do.

It is doable. It just takes work to get there. And the companies that put that work in are going to operate knowledge work in a way the rest cannot keep up with, while the ones who let agents loose without governing the systems underneath are going to find out, in their own small way, who looked at HAL and decided he should have the keys.