Governing agentic AI before it reaches operations.

Most AI governance in place today was written for systems that answer questions. A person asks, a model responds, and a human decides what happens next. Agents remove that step by design. An agent is given a goal, plans the work, pulls in the information it needs, calls tools, hands tasks to other agents, and changes data in live systems.

Policies and ethics principles still matter. But an agent is not governed by its model card. It is governed by what it can see, what it can reach, who it acts as, and whether anyone can reconstruct what it did. Those are design decisions, and they need to be made before an agent reaches operations, not after.

Start with a registry

You cannot govern agents you cannot list. An agent registry is the system of record for every agent in the organization: who owns it, what it is for, which model and instructions it runs on, which tools and data it can reach, how much it may do on its own, and when it was last reviewed. It should cover the tools agents connect to, not just the agents themselves.

The most useful rule is also the simplest: an agent that is not in the registry cannot get credentials. That one control stops "shadow agents" built quietly by a team with an API key, and it gives every other control a place to live.

Govern what agents can reach: MCP

The Model Context Protocol, or MCP, has quickly become the standard way agents connect to tools and data. More than 10,000 MCP servers were published within its first year. That is good for interoperability, and it creates a new perimeter: every MCP server hands a set of capabilities to a model that decides for itself when to use them.

The risks are specific. A tool's description can hide instructions the model will follow. A server can behave well when approved and change later. And servers often run on broad credentials that were never scoped down. The answer is to treat MCP servers like any other critical integration: only approved servers, reviewed when they change, with narrowly scoped access, and a central gateway that enforces permissions and keeps the audit trail the protocol itself does not.

Govern what agents can see: context

Everything an agent knows at the moment it acts arrives through its context: its instructions, the documents it retrieves, the results of tool calls, and anything it remembers from before. Context is both the agent's biggest attack surface and a data flow most organizations have never mapped.

Two principles cover most of it. First, anything an agent retrieves is untrusted: a document or email can contain instructions designed to hijack its goal. Second, context needs the same data discipline as any other system. Decide which classes of data may enter an agent's context at all, what it is allowed to remember and for how long, and make sure one user's information never leaks into another's session.

Give every agent its own identity

Agents should never run on a shared service account or a developer's personal credentials. Each needs its own identity, with access scoped to its task and credentials that expire. When an agent acts for a person, it should act on their behalf, with their permissions and no more. And as agents begin handing work to other agents, the same logic applies between them: an agent should only accept work from agents it can verify and that are approved to call it.

Match oversight to the stakes

Human oversight works best when it is targeted. Let agents read, search, and draft freely. Allow reversible, low-risk actions within set limits. Require a person to approve anything irreversible or high-impact, such as payments, deleting records, external communications, or changing access. Then check that the oversight is real: if approvers never override the agent, either it is excellent or no one is really reviewing.

Keep evidence of everything

If you cannot reconstruct what an agent did, you cannot investigate an incident, answer an auditor, or improve the agent. Every run should leave a trace: what it was told, what it looked at, which tools it called, what was approved, and what happened. Those traces are evidence and should be protected and retained like it. Alongside them sit the basics of running any production system: spending limits, alerts, and a tested way to stop the agent.

Finally, test before release and after every change. A new model version, a revised prompt, or a new tool is a change to a production system, and should go through the same gate as the original launch.

Five questions before an agent goes live

You do not need a finished framework to start. You need clear answers for every agent before it touches production: Is it in the registry, with a named owner? Are its tools and data access approved and scoped? Does it have its own identity? Which actions need a human? Can we see everything it did, and stop it?

If any answer is "we're not sure," the agent is not ready, however well it performed in the demo. The organizations that scale agents safely will be the ones that build these controls into their platforms once, so every new agent inherits them by default.

---