An Early Example of Super Bad AI Governance — computerlove.tech

← Back to blog<br>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...