How do you govern what AI agents can access across many MCP servers and connectors?
Standardise a short approved set of connectors, give each agent only the tools its job needs, and keep a record of every grant. Connecting a system does not grant access by itself.
Pick a short approved set of connectors for the company, then give each agent only the tools its job needs. Connecting a system does not grant access by itself. Agents cannot create tools or widen their own access. Record every grant and every run so you can see what an agent was allowed to reach when it acted.
Why the question comes up
Companies that adopt AI quickly often switch on every connector and every MCP server they can find. That gets people using agents. A few months later the same company has dozens of servers, each with its own view of who may see what, and nobody can say which agent may reach which system. On one call, a mid market software company described about forty MCP servers and wanted a standardised set, plus one authoritative workflow for creating a quote. The question was not how to add another connector. It was how to govern the ones already there.
What goes wrong when every connector is on
Three problems show up together.
Nobody owns the list. Each team adds the MCP servers its tools need. The company ends up with overlapping servers for the same system, and retired tools that still have credentials.
Permissions drift. Each connector has its own view of who may see what. When an agent gives a wrong answer or takes a bad action, there is no single place that says what it was allowed to read.
Costs and noise grow. Every open connector is another place an agent can search. The same documents are read again and again, and answers mix official pages with drafts.
A company context layer fixes the "many tools, no shared source" problem for answers. Governance of connectors is the twin problem on the access side: which servers exist, who may use them, and which agent gets which tools.
Five rules for governing connectors and MCP servers
- Keep one approved catalogue. List every MCP server and connector the company allows, who owns it, which system it reaches, and whether it is read only or can write. Anything not on the list is off. Review the list on a fixed cadence and remove servers that nobody uses.
- Standardise before you customise. Prefer one approved way to reach each system (one CRM connector, one wiki connector, one quoting workflow) over a private server per team. A standardised set is what the buyer with about forty servers was asking for.
- Give each agent only the tools its job needs. Connecting a system does not grant access by itself. Scoped tools, not open computer access, are how an agent reaches a system. An agent that drafts quotes does not need the same tools as an agent that reads the wiki. Detail is on the platform.
- Separate read from write, and keep writes behind a person by default. Agents stay read only until a write is granted. Actions that leave the company, such as sending an email or an invoice, wait for a person unless your team has allowed that specific action to run on its own. See approvals and control for AI agents.
- Do not let agents widen their own access. Agents cannot create tools or grant themselves access. Text in your data or in a model's answer cannot change their permissions. Every run, action and approval is recorded so you can see what was reached.
| Decision | Who owns it | What "done" looks like |
|---|---|---|
| Approved catalogue of MCP servers and connectors | Named owner (often platform or IT with the business) | One list, reviewed on a cadence, unused servers removed |
| Which agent gets which tools | The person who owns that piece of work | Each agent has the minimum tools for its job |
| Read vs write and outside actions | Same owner, with approvals by consequence | Reads recorded; writes and outside actions wait for a person by default |
| Private or sensitive sources | Workspace owner with the business | Sources everyone in the workspace may see only; see [how AI agents handle private information](https://ortelian.com/notes/how-ai-agents-handle-private-information-in-chat-and-meetings/) |
A practical way to cut the list
Start from what agents and people actually use, not from what is installed.
- Inventory every MCP server and connector with an active credential.
- Mark each one: required for a live agent or workflow, used by people in an AI tool, or unused.
- Collapse duplicates into one approved connector per system.
- Turn off unused servers and rotate their credentials.
- For each live agent, rewrite its tool list from the approved catalogue so it only has what its job needs.
- Put the catalogue and the per agent tool lists where the team already works, and assign a named owner who can pause a grant without a deploy.
Who keeps that catalogue current after launch is a separate decision, covered in who owns the AI platform after launch.
How Ortelian approaches it
On the platform, agents reach your systems through scoped tools, never with open computer access. Each agent gets only the tools its job needs. Connecting a system does not grant access by itself. Your own AI tools, such as Claude, ChatGPT and Copilot, can connect over MCP and still reach the business only through those scoped tools. Agents are read only until a write is granted. Outside actions wait for a person by default. Agents cannot create tools or grant themselves access. Every run, action and approval is recorded.
On Trust, each customer sits in its own workspace, and inside a workspace every user sees all imported data. Connect only data that all of your workspace users may see. Credentials never reach a model. Models run with zero retention and do not train on customer data. The workspace, world model and backups stay in the EU; sign in and agent mailboxes run in the US. EU only model routes are available on request.
We agree access, model providers and data handling for your deployment before work starts (how we work). The same work that cuts a sprawl of connectors also feeds the company context layer: one approved source of definitions and documents, with permissions enforced in one place.
Questions people ask
How many MCP servers should a company run?
As few as the work needs. One approved connector per system is a better default than a private server per team. Count live agents and workflows first, then keep only the servers those jobs require.
Does connecting an MCP server give every agent access?
No. Connecting a system does not grant access by itself. Each agent gets only the tools you assign for its job.
Can an agent add its own MCP server or tool?
Not with Ortelian. Agents cannot create tools or grant themselves access. New connectors are added by people through the approved catalogue.
How do you govern connectors when people also use ChatGPT or Copilot?
Point those tools at the same scoped access path the agents use, not at a separate pile of connectors. A company context layer is how answers stay consistent across tools; the catalogue is how access stays consistent.
Who owns the connector list after launch?
Name a person who can approve, pause and remove grants without a deploy. How that role sits next to the business owner of each workflow is covered in who owns the AI platform after launch.
