MCP governance is the work of deciding which tools each AI agent may call, under whose name, and with what record left behind. In one week in October, Google Cloud, Celigo, and Quantum Metric each shipped a piece of that work, and the pattern across all three is the same: agents get a permissions desk before they get the keys.
TL;DR
- Three October launches point to one pattern: register every MCP server, approve tools one at a time, and tie calls to a named user.
- Google Cloud's IAM Helper splits read-only discovery from policy changes, which still wait for a human approval.
- Celigo's gateway and registry show IT which servers exist and who may use each tool.
- Before your next agent ships, inventory its servers, cut its tool list to the job, and confirm its calls leave an audit trail.
One week, three launches, one pattern
On October 20, Celigo announced MCP Management at the Gartner IT Symposium/Xpo in Orlando. On October 22, Quantum Metric made its MCP server generally available. On October 27, Google Cloud introduced IAM Helper, a set of agent-facing skills and MCP tools for Identity and Access Management. The three products serve different buyers, but they answer the same question, and it is the question how we build custom AI automations starts from: what may this agent touch, and who answers for it?
Model Context Protocol, or MCP, is the standard way AI assistants and agents connect to business systems. Each MCP server exposes tools, the specific actions an agent can take in a system, such as looking up a customer in a CRM or checking an invoice in an ERP. The standard spread fast because it removes custom integration work. It also spread a problem: each server arrives with its own access model, and many are broad by default.
Broad by default means every connected person or agent gets the full tool set, rather than only what the job requires. Many servers also run on shared service credentials, so the system of record logs the application rather than the person. Security teams then face two gaps at once: they cannot say who acted, and they cannot limit what the agent may do next. That is the gap the October launches close, each from its own side.
Why shared credentials break the audit trail
An audit trail answers three questions: who acted, what changed, and under what approval. A shared credential answers none of them well. When five agents and forty employees use one service account, the log shows one actor for all of them. A reviewer tracing a bad invoice update or a deleted record cannot tell whether a person or an agent made the change, or which workflow ordered it.
Celigo's announcement states the point plainly. Its chief product officer, Matt Graney, said enterprises need to know who is behind every AI request, what it is authorized to do, and what actions it has taken. The company's fix is a gateway: every MCP server, built in Celigo or by a third-party vendor, runs behind one control point. Access is set at the level of the individual tool, tied to the organization's identity provider, and every action traces to a verified user.
The registry is the other half. Celigo's MCP Registry shows every MCP server in the organization, which assistants and agents use it, and who has access. Employees request the tools they need, and administrators approve specific tools. Each approval records who was granted access, which tools they may use, and who approved it. Shadow servers, the ones nobody registered, become visible, which is the point: you cannot govern a server you cannot see.
Google's version: discovery runs free, changes wait for a human
Google Cloud's IAM Helper, introduced October 27, 2026, packages IAM workflows as agent skills and MCP tools. The design draws one clear line: diagnostics and simulations run automatically, while any change to an access policy pauses for human confirmation, set by risk tier. Read-only discovery and policy change are separate operations, by construction.
The everyday case is a deployment agent hitting a 403 error. IAM Helper's troubleshooting skill identifies the missing permission, then its privileged-access skill requests a one-hour just-in-time grant through Privileged Access Manager, instead of handing the agent permanent broad access. For pipeline self-healing, the policy simulator skill tests a revised least-privilege policy against 90 days of access logs, then routes the change to an administrator for approval.
Underneath the skills sit atomic, read-only MCP tools on Google-managed servers, covering Policy Troubleshooter, Policy Analyzer, Policy Simulator, and the IAM v1 and v2 APIs. Agents query exact answers instead of parsing long policy documents in the prompt. The policy management skill also blocks risky configurations before they apply, including public access and broad basic roles such as owner and editor. The agent can propose a change, but the system checks it and a human approves it.
What Quantum Metric adds: context is also a permission question
Quantum Metric's MCP server, generally available October 22, 2026, connects MCP-compatible agents to digital experience context: which customers felt a breakage, and what it cost the business. Its five workflows include self-improving websites, where agents detect friction, diagnose it, fix it, and measure the result in a loop, and prioritized testing, where agents rank experiments by business impact.
Experience context sharpens the governance point. An agent that can see revenue impact can also act on it, and a self-improving website loop that runs without a human in it will change production pages on its own. The question for that loop is the same as for any other: which pages may it change, under whose approval, and with what record. Context makes agents more useful, and it raises the stakes of leaving their tools ungoverned.
That is why the three launches belong in one story. Celigo governs which tools an agent may call. Google governs how cloud permissions change, and who approves. Quantum Metric shows what happens when governed agents get rich context: they act on the work that matters, inside limits a team can audit. Identity was step one, covered in our earlier post on agent identity. Tool-level governance is step two.
Build the permissions desk before the agent ships
A team starting from zero does not need a new platform on day one. It needs four decisions, written down and enforced in the same place. First, a registry: list every MCP server the team uses, including the ones individual developers connected on their own. Second, per-tool grants: each agent gets only the tools its job requires, approved one tool at a time.
Third, a named identity: every call runs as a verified user or a dedicated service account for one agent, never a shared credential across agents. Fourth, a split between reading and changing: agents may query freely, but writes, deletes, and permission changes pause for approval, with the approval and the result logged. Review the log weekly at first, then monthly once the pattern holds.
Two traps deserve attention. The first is the prompt as policy: a sentence in the system prompt telling an agent not to delete records is not a control, because the tool still allows it. The control must sit where the tool is called. The second is the standing grant: temporary access that nobody revokes becomes permanent access. Just-in-time grants with automatic expiry, the model Google's privileged-access skill uses, close that gap. Teams running n8n can apply the same gate in front of workflow tools, as our n8n RAG support agent tutorial shows: the workflow calls a governed tool, or it does not call it at all.
The desk is the product decision
Vendors will keep shipping governance features, and teams will keep adding them after an incident. The cheaper order is the reverse: decide the permissions desk when the agent is designed, alongside its tools and data. That means the agent's tool list is part of its specification, its identity is part of its deployment, and its audit log is part of its acceptance test.
This is how BuzzinTech builds custom AI automations: agents ship with their permissions desk in place, not added after the first incident. A support agent answers from company docs through a retrieval workflow, with read-only access to the knowledge base and no path to customer records it does not need. A sales agent drafts outreach, but sending waits for a human. The desk is what lets a team trust the agent enough to leave it running.
October's launches show the industry converging on the same answer. Agents got their identity last week, in the sense that teams now issue and track agent credentials. This week, the question moved to what those credentials may do. Teams that answer it now will spend less time later explaining an agent's actions to a security reviewer. Teams that wait will answer it under pressure, after an agent does something nobody approved. The Ecovers automation build shows the same discipline on the marketing side: every quote request captured, answered, and followed up through one governed system, with a human picking up where automation stops.
Does your agent have a permissions desk yet?
If your agents connect to business systems through MCP servers, a short review of their tool access now beats an incident review later.
See how we build governed AI automations
Frequently asked questions
What is MCP governance? MCP governance is the set of controls over which tools an AI agent may call through Model Context Protocol servers, under whose identity, and with what audit record. It covers a registry of servers, per-tool approvals, named identities, and approval gates for changes. Without it, agents often run on broad default access and shared credentials, which leaves security teams unable to say who acted or what changed.
How is MCP governance different from agent identity? Identity answers who the agent is. Governance answers what that identity may do. Last week's identity work gave agents credentials and tracking. This week's governance work limits those credentials to specific tools, requires approval for changes, and logs results. Both matter, and identity alone does not limit a tool call.
What did Google Cloud announce with IAM Helper? On October 27, 2026, Google Cloud introduced IAM Helper, agent skills and MCP tools for Identity and Access Management. Skills cover policy management, 403 troubleshooting, policy simulation against 90 days of logs, and just-in-time privileged access. Diagnostics run automatically, while policy changes pause for human approval by risk tier.
What does Celigo MCP Management do? Announced October 20, 2026, Celigo MCP Management gives IT one gateway and registry for MCP servers. Teams connect each workflow only to the systems it needs, approve tools one at a time, and tie every call to a verified user instead of a shared credential. The registry shows every server in use and who may use each tool.
Do small teams need MCP governance? Yes, in proportion to what their agents can touch. A support agent that only reads docs needs a short tool list and a log. The risk grows with write access: an agent that updates records, sends messages, or changes permissions needs per-tool approval and a human gate on changes, whatever the team size.
Where should a team start? Inventory every MCP server in use, including unregistered ones. Cut each agent's tool list to its job. Give each agent its own identity. Split read access from write access, and require approval for writes and permission changes. Review the audit log weekly until the pattern holds, then monthly.