The AI agent governance layer MCP leaves you to build

Build the agent, demo it to the business, then work out which systems it may touch. Permissions arrive as a follow-up ticket, usually because someone in security asked a question nobody had prepared for. That sequence is backwards, and it explains why an agent pilot can work perfectly in a demo and still be unshippable.

An AI agent governance layer is the part the demo skipped. It answers four questions at the instant an agent tries to do something: which agent is this, whose authority is it acting under, is this specific action permitted, and where does that decision get recorded. Model Context Protocol has made tool discovery and invocation a solved problem, and it answers none of those four.

Does MCP handle agent authorization?

MCP describes how a client discovers the tools a server exposes and how it calls them, and it specifies how that client authenticates to a remote server. What no part of it decides is which identity the server presents when it reaches Salesforce or Postgres on the other side, or whose entitlements get checked there. That is left to whoever wrote the connector.

The path of least resistance is one credential per server: a Salesforce integration user, a Postgres role. Every call the agent makes runs as that credential, for every person who ever talks to the agent.

That is a fully compliant implementation and it is the wrong shape. The agent’s authority becomes the union of everything the credential can reach, applied identically no matter who is at the other end of the conversation.

Why an agent should inherit the caller’s permissions

Take a support rep asking an agent to summarize a customer account. The agent calls the CRM server. The server authenticates as an integration user holding read access across all objects, because narrowing it would have broken other tools that share it. The rep now reads fields their own login would not render — legal notes on an open dispute, another rep’s commission on the account. Nothing was breached. The access log shows the integration user reading the CRM, which is what it does all day, so the review comes back clean.

The fix is mostly plumbing. The agent has to carry the caller’s identity through the tool call, and the tool has to make its authorization decision against that identity instead of against the connector’s own credential. Token exchange at the gateway, then the caller’s entitlements evaluated at the point of execution. Two subjects on every call, both checked, so an agent can never be a route to data its user could not open directly.

Most of that work lands in your API layer rather than in agent code, which is why the scoped endpoints and auth layer has to be in place before an agent is issued anything at all. Endpoints that have only ever run behind a trusted internal network carry assumptions an agent will not honor, so audit those before you hand over a token.

Where the AI agent governance layer has to sit

Between the agent and the tool servers, as a component the agent cannot talk its way around. It holds a registry of agents and the tools each may reach, and it evaluates a policy decision per call from the agent identity, the caller identity, the tool being called and the arguments passed. Every outcome goes to a trace keyed by run.

It goes there rather than into prompts because a prompt is an instruction to a probabilistic system and a gateway check is a condition. A model that has been talked into asking for the wrong thing still gets refused, and the refusal is written to the trace under the run that produced it. Denial by entitlement, not by persuasion.

One agent can be governed by hand. Nobody needs a registry for a single agent whose tools were granted over Slack by whoever held admin that week. The layer earns its cost at the second agent, when the same CRM connector serves a support agent and a sales agent with different tolerances, and a revoked permission has to take effect in both without a redeploy of either.

Who should own the agent permission registry

Data platform vendors, CRM vendors, service management vendors and the hyperscalers are all shipping agent control planes. Assume enforcement works; it is the feature they compete on. Authoring is the question nobody is competing on.

If the registry of agents, tools, thresholds and approvers exists only inside a vendor console, every new use case has to pass through that vendor’s permission model and their release schedule. A platform change then costs you the authorization model itself, because the only complete copy of it was in their UI.

Policy belongs in files in your own repository — agent identities, tool allowlists, approval thresholds, escalation targets, retention on traces. The vendor’s control plane becomes an enforcement point you can swap out. You maintain that config yourself and you write tests for it, and a console with a tidy permissions matrix would have been less work up front. What it buys is that switching platforms becomes a deployment change.

What agent governance costs when you scope it in early

Governance is most of the price difference between an agent that reads and an agent that acts. Our cost guide for AI agent development puts a staff-facing, read-only agent behind your SSO at ₹4L – ₹6L, and a customer-facing agent that writes to a system of record — approval path above your limit, full run tracing, a scored evaluation set, a staged rollout — at ₹14L – ₹18L. The gap is the approval queue and its timeout behavior, idempotency keys so a retried run cannot refund twice, per-tool scoping, and a trace complete enough to settle a dispute with a customer.

Retrofitting those controls onto a running agent means re-authenticating integrations that already work in production and re-testing every action path against a permission model that moved underneath them.

Worth settling before any of it: whether the job needs an agent. A fixed sequence with fixed rules has a governance story you already own, because it is a service with static permissions and a deterministic log. The choice between agents and automation comes down to whether the path varies. Where the deterministic option fits there is no authorization model to design, because the permissions never move.

Where an agent is the right answer, the guardrail config belongs in the scoping week, as a written decision, before anyone builds the thing it is supposed to constrain. On the AI agent builds we take on, that means naming the tools the agent may call, the spend ceiling per run, the actions that stop for a person, and who that person is.

What it costs to retrofit agent governance later

Agents accumulate faster than the controls around them. The first goes live on a credential someone provisioned by hand. The next team reuses that credential, because it already works and requesting a new one means opening a ticket. Nobody records who approved what. Then somebody asks which agents can write to billing, and the answer takes a developer reading source code, and the engineer who wired the first one has moved on.

The question does not arrive on your schedule. It arrives with a customer disputing what an agent told them, an enterprise buyer’s security questionnaire that gates a contract, or a regulator asking which automated systems process personal data. Each wants a trace of one decision on one date. That trace either exists from the moment the action ran or it does not exist, and there is no reconstructing it from logs that recorded a service account doing its usual work.

The cost curve runs the wrong way as well. Every integration standing on a shared credential is another thing that breaks the day you finally issue each agent its own identity, and every month of unlogged runs is a month of questions you will never be able to answer. Put the governance layer in before the second agent and you pay for it once, on your own schedule, against a scope you chose. Leave it, and the bill arrives during an incident, with someone else’s clock running.