AI agent governance is the set of decisions a company makes about the AI agents its people run, and the means of enforcing them on every machine. It is the answer to a question that has already reached most CISOs: your developers run Claude Code, Cursor and Codex with their own credentials and their own judgement, so who decided what those agents may do, and how would you know if one crossed the line? This article is for the person who has to answer that. It sets out the four decisions a company has to make, why a policy document cannot make them, how they are enforced on the endpoint, and what the auditor gets at the end.
Why is AI agent governance a security problem, not a productivity one?
An AI coding agent is a program that acts with a developer's full access and takes its instructions from text: the prompt, but also every file it opens, every web page it fetches and every tool result it reads. That combination makes it different from any software a security team has governed before. It is trusted, it is signed, and it will do what it is told by whoever gets text in front of it.
The consequences land on the security team's desk. One real developer laptop we scanned held forty-six credentials its agents could read. In May 2025 Invariant Labs showed a public GitHub issue steering an agent into leaking a private repository. In September 2025 a copied MCP server on npm blind-copied every email sent through it to its author. None of the developers involved did anything unusual. They ran the tools the way the tools are meant to be run.
So governance here is not about whether developers may use agents. They already do, and they are more productive for it. It is about deciding, as a company, what those agents may reach and do, and being able to prove that the decision holds on every machine.
What are the four decisions a company has to make?
Every AI agent governance programme, whatever it is called internally, comes down to four decisions. Make them explicitly and the rest is engineering.
1. Which agents are allowed. Claude Code, Cursor, Codex CLI, Windsurf, Gemini CLI, Copilot, Claude Desktop, and whatever appears next month. Most companies discover they run eight or nine when they thought they ran two. The decision is not a ban list; it is a known list, so that an agent nobody approved is a finding rather than a surprise.
2. What each agent may reach. Credentials, repositories, internal systems, the network. An agent that can read the production database password does not need to, and the fact that it can is a standing risk. This decision is made per credential and per system, and it is the one most companies have never made because nobody could see the reach.
3. What each agent may do without asking. Agents ask permission before running commands or writing files, until a developer tells them to stop asking. A standing permission to run any command, push to git or write anywhere is an agent that no longer has a person in the loop. The company decides which of those grants are acceptable and which are forbidden everywhere, and that is the floor under every developer's own settings.
4. What gets held until someone has looked. New MCP servers, skills, extensions and packages arrive on developer machines without a ticket. The decision is which of them may run straight away and which are held for review: unknown ones, ones with a known advisory, ones an AI reviewer flags for hidden instructions. MCP server security covers what that review looks like.
Write those four down and you have a governance model. It fits on one page. The hard part is the next section.
Why can a policy document not do this?
Most companies already have an AI usage policy. It says agents may not access production credentials, that new tools must be reviewed, and that developers must keep permission prompts on. It is signed, it is in the handbook, and it has no effect on a single machine.
The reason is mechanical. An agent's behaviour is set in files on each developer's laptop: the allow rules in a settings file, the servers in a config file, the hooks that run on every session. Those files change daily, by hand and by the agents themselves. A policy cannot read them. A quarterly survey cannot keep up with them. A network proxy sees that a request went out, not that the agent holding a forbidden permission made it.
Governance that works has to live where the configuration lives. It has to read the agents' own files, compare them to the company's four decisions, and correct the machine when they differ. That is a control, in the auditor's sense of the word, and a policy is not.
How are the rules enforced on the endpoint?
The mechanism is a sensor on each machine and a console the security team works from. It is how ZYBE does it, and the shape is what matters.
The sensor reads the agents' own configuration. Within fifteen minutes of installing it, the console lists every agent on the endpoint, every MCP server and skill it loads, every hook that runs, and every standing permission it holds. Nothing for developers to register; the agents already wrote it down.
Reach is computed, not surveyed. For each agent, the credentials it can read by name, the systems those credentials open, and the paths between them. Decision two becomes a list you can act on: this production key is readable by four agents on three laptops.
Rules are set once, in the console, and apply to groups of endpoints. Which permissions are forbidden, which servers are held, which detections block rather than record. A forbidden standing permission is removed on the endpoint and kept out. A held server cannot be called until a person approves it. A destructive command, a credential leaving the machine, an instruction acted on from injected text: blocked before the process starts, and raised as a threat with the session behind it. Guardrails and permissions shows the rule set.
Exceptions are explicit. A platform team that genuinely needs an agent with wider permissions gets it as an exception on a group, recorded with who granted it and why. That is the difference between governance and a lockdown: the rule has a floor, and the floor has a door with a log.
Nothing sensitive leaves the machine. The console receives names, counts and hashes. Credential values, file contents and the text of conversations stay on the endpoint. A governance programme that ships developers' secrets to a vendor has created the exposure it was meant to remove.
What does the auditor get?
The frameworks have caught up faster than the tooling. The EU AI Act's Article 14 asks for human oversight of high-risk AI systems; ISO/IEC 42001 asks for an AI management system with defined controls; SOC 2 asks whether access and change are controlled; the NIST AI Risk Management Framework asks you to map, measure and manage. Each of them, read against coding agents, comes back to the four decisions above and to evidence that they hold.
Evidence is the operative word. An auditor does not want the policy; they want to know that on a given date, these agents ran, each could reach this and no more, these rules were enforced, and these findings were open and owned. A console that assesses each framework's controls from what the endpoints report, and marks the controls that still need a person, produces that as a dated report. Compliance and audit covers seven frameworks that way. The alternative is a spreadsheet filled in from memory, and every auditor knows what that is worth.
Where does a CISO start?
Not with the policy. With the picture.
- Put the sensor on the machines and wait fifteen minutes. Now you know which agents run, what each can reach, and which permissions are standing. Most of the surprise is here.
- Make the four decisions against that picture, not against an assumption. The list of forbidden permissions writes itself once you can see which ones exist.
- Turn the rules on for one group first, a platform team or a pilot, with exceptions recorded. Then widen.
- Hold new servers and skills for review from day one. It costs developers nothing they will notice and closes the door that the 2025 incidents walked through.
- Map what you have to the frameworks you already owe, so the work counts toward the audit rather than beside it.
That is AI agent governance: four decisions, enforced where the agents live, proven from evidence. The board's question has an answer, and it is not a document.
Frequently asked questions
What is AI agent governance? It is the set of decisions a company makes about the AI agents its people run, and the means of enforcing them: which agents are allowed, what each may reach, what each may do without asking a person, and what is held until someone has reviewed it. It is judged by what the endpoints actually do, not by what a policy says.
Who owns AI agent governance? The CISO owns the decisions and the security team runs them, because the risk is a security risk: credentials, code and production systems reached by a program that follows instructions from anywhere. Platform and developer leads own the exceptions, since they know which permissions a team really needs.
Can a written AI usage policy govern coding agents? No. A policy sets the intent, but an agent is configured in files on each developer’s machine and changes daily. Governance that works reads those files, compares them to the rules, and corrects the machine. Anything else is a wish with a signature.
How do you prove AI agent governance to an auditor? From evidence the endpoints report: which agents ran, what each could reach, which rules were enforced and which findings were open, on a date. Frameworks such as the EU AI Act, ISO 42001, SOC 2 and the NIST AI RMF all ask for oversight and records, and a report built from that evidence answers them without a spreadsheet.