MCP is the easy part. The decision that matters is who gets to say which tools your agents can use, and whether anyone with a credential can go round that decision. Get that right and the rest is design.
Any capable AI model can now act on your systems, and MCP (Model Context Protocol) is simply the most convenient way to let it. An MCP server is a thin wrapper around an API. Anyone holding a credential can write one in an afternoon, choose which tools it exposes, and connect it to Claude, Copilot or ChatGPT. MCP isn’t even required: a coding assistant will happily write a script that calls the API directly.
The system on the other end sees a valid token and a permitted call. It has no way of telling whether a person, a script or an agent is behind it.
The question that matters is who decided which tools your agents can use, and whether anyone can go around that decision. Today the answer to the first is usually whoever built the MCP server, and the answer to the second is anyone holding the credential behind it.
Why the API is the real boundary
Most organisations already have some controls around this. Admin approval for new app registrations, short-lived tokens, network restrictions and API gateways all help. They stop unapproved applications from connecting.
They do very little once an approved credential is in use. A personal access token, a service account key or a shared API key carries its full permissions to whatever holds it, and if several agents share one key, you cannot revoke one without breaking the others.
This is common. VentureBeat’s June 2026 research, a survey of 107 organisations weighted towards the mid-market, found that 69% of organisations run agents with shared credentials somewhere in their deployments, and only 32% give every agent its own scoped, managed identity. Gravitee’s 2026 survey of more than 900 practitioners found that 45.6% of teams rely on shared API keys for agent-to-agent authentication. Those figures match what we see in client estates: shared service accounts and long-lived keys are the norm, and agents are being connected to them.
None of this is new in principle. A person with an API key could always write a script. What has changed is the effort, which is now close to zero; the speed, which is now machine speed; and the source of instructions, which now includes any content the agent happens to read. The safe working assumption is that every approved credential becomes an agent credential the moment a model can reach it.
The pain: connected is not the same as controlled
OAuth decides whether a caller can connect. It says nothing about what the caller does once it is in.
A traditional integration does the same thing every time it runs. An agent decides at runtime what to do with its access, based on whatever instructions reach it. Some of those instructions come from your staff. Some arrive inside a support ticket, an email or a web form.
That is the Confused Deputy problem: a privileged agent, using legitimate credentials, is steered by a less privileged party into using its authority for something it was never meant to do. The ShareLeak vulnerability in Microsoft Copilot Studio is a clear example. An attacker put a crafted message into a public comment field; the agent read it as an instruction, queried SharePoint data and emailed it out, all through connections it was authorised to use.
The numbers show how widespread the gap is:
- 63% of organisations cannot enforce purpose limits on AI agents, and 60% cannot terminate one that is misbehaving (Kiteworks).
- Only 18% have high confidence that their identity and access management can handle agent identities (Cloud Security Alliance).
- Gartner forecasts that around 40% of enterprise applications will include agents by the end of 2026, up from under 5% in 2025. It also expects more than 40% of agentic AI projects to be cancelled by the end of 2027, citing cost, unclear value and inadequate risk controls.
The standards bodies have reached the same conclusion independently. OWASP lists Agent Goal Hijack as the top risk for agentic applications. The Cloud Security Alliance says agent access should pass through an enforcement point that checks identity and policy and leaves an audit record. SANS has named the principle: Least Agency, the agentic counterpart to least privilege. It limits what an agent is capable of attempting, as well as what it is permitted to do.
The gain: the enterprise decides what agents can do
The safe position has two parts. The organisation, rather than whoever built a server, decides which tools agents can use. And that decision cannot be bypassed, because no credential in circulation reaches further than those tools.
In practice, that looks like this:
- Agents see a tool list the enterprise defined, made up of named operations against systems of record.
- The credentials behind those operations are held by the integration layer, and raw API access to systems of record is a recorded exception with an owner.
- Every action is tied to an identity and an audit trail.
- You can revoke one agent, see what it did, and leave everything else running.
Why not just a gateway?
Most enterprises will reach first for something they already have.
An API gateway controls who can call which endpoint. The endpoint is still the raw API, so an agent that is allowed to update a record can update any record, in any way the API permits. The gateway sees the call but not the business intent behind it.
Tighter OAuth scopes narrow which endpoints a credential can call. They say nothing about what the caller does with them, which is exactly where the Confused Deputy problem lives.
MCP gateways and registries control which MCP servers are approved. That helps, but anyone holding a credential can still build a server of their own, and a registry does nothing to define the operations agents should be calling.
Agent identity and runtime policy tools decide who an agent is and whether a given call is allowed. Both are needed. Neither defines the operation being called.
All of these have a place, and a mature estate will use several. What none of them does is turn a raw API into a business operation. That needs a layer that can combine calls, apply business rules and validation, and span several systems in one defined step: “create a supplier, with checks and approval” rather than “write to the vendor table”. The difference is in what the enforcement point understands, not in buying another box.
The solution: the integration layer becomes the control plane
That layer is the integration layer, and once agents arrive it becomes the control plane. Where an organisation runs a mature integration platform with a real practice around it, the layer already exists. Where the estate is an older ESB, some iPaaS and a pile of point-to-point APIs, it has to be built or consolidated first, and it is better to know that before anything else is bought.
The design principle is simple. The agent interprets; the integration layer executes. The agent can read a request however it likes, but what actually changes a system of record is a named, tested, deterministic operation, built and owned by the enterprise. Prompt injection can still happen. When it does, the most the agent can reach is the catalogue of operations, not the whole API.
This is a trade-off. An agent limited to defined operations cannot improvise new multi-step work against your ERP that nobody has built yet. For systems of record, that is usually the right trade in 2026: agents stay open-ended where they read, search and draft, and act through defined operations where they change things. New capability arrives by adding operations to the catalogue, which is a design decision rather than a model decision.
Enterprise MCP: presenting the control plane to agents
Agents find and call tools through MCP, so the control plane has to speak MCP too. The pattern is Enterprise MCP: the enterprise publishes its defined operations as tools on MCP servers it owns. Agents connect to those servers and see only the tools the organisation has decided to offer, the integration layer holds the connections to the systems behind them, and every call is logged.
Workato Enterprise MCP is one implementation of the pattern. Recipes, Workato’s deterministic workflows, are published as tools on MCP servers the enterprise controls, with the platform holding the connections to the systems underneath. For an organisation already running Workato, the integrations it has built become the starting catalogue of what agents are allowed to do.
Enterprise MCP is how the control plane is presented to agents. It only controls anything if the alternatives are closed off. Publishing operations as MCP tools achieves little while developers still hold personal access tokens, service principals sit in local config files, or a side route through another automation tool reaches the same systems. Retiring those credentials, or bringing them under the same rules, is the harder half of the work.
Four architectural decisions make the pattern real:
- The identity boundary. Each call should trace to the person the agent is acting for. That means delegated (on-behalf-of) tokens rather than a shared service account for “the bot”, delegated scope that never exceeds the person’s own, and a separate identity per agent so one can be revoked without affecting the rest. Most estates cannot do all of this today, which is why it is a design decision and not a setting.
- The execution boundary. Which operations are exposed at all, and which systems are never reachable directly with a raw credential.
- Least Agency in practice. Each agent holds only the authority its task needs. SANS names the principle; the integration layer is where it is enforced for the paths that pass through it. Agents built into SaaS platforms such as Copilot Studio or Agentforce act through the vendor’s own path, which is a separate control surface to be assessed on its own terms.
- The blast radius. What a credential could reach if it ended up in the wrong hands, and how quickly you can revoke it and account for what was done with it.
None of these is a one-off setting. Agents come and go, systems change and remits widen, so the identities, the operation catalogue, the credential inventory and the limits need an owner inside the organisation who keeps them current. The operating model matters as much as the technical design, and it is usually where a control plane either keeps working or quietly decays.
How Cloudorizon helps: the Agent Access Review
Cloudorizon comes from enterprise architecture and has spent years building complex ERP integrations. The Agent Access Review is where we start: a fixed, 10-day engagement on one system of record. Its output is evidence and decisions, not a strategy deck.
It depends on access and people being ready on day one: exports from your identity provider and app registrations, secret stores, integration platform connections and the relevant SaaS admin centres, plus time with the people who hold the answers.
The core engagement produces four things:
- An agent and credential inventory. Every agent, AI client, MCP server and credential we can see from platform records, plus a sample of shadow paths (desktop MCP configurations, personal tokens, pipeline secrets) gathered in interviews with engineering and operations. For each one: who owns it, how it authenticates, what it can do, and what happens if you revoke it.
- An integration layer fitness review. Whether your existing platform can become the control plane, and which existing integrations can be promoted to named operations. The test is written down: if there is no single place that can hold system credentials, run deterministic multi-step work and produce an audit record, the answer is no, and we say so.
- A decision record. The identity boundary, the execution boundary, how much authority each class of agent gets, and the exception policy, with named owners for the operation catalogue and the credential register. These are decided in working sessions that the system owner, the identity lead, the integration lead and someone able to accept residual risk must attend. Without them, the output is a recommendation rather than a decision.
- A baseline and roadmap. Where you stand today on three measures: can you revoke one agent, can you say what it did, and is raw API access the exception? Then the order in which to retire credentials and build the catalogue.
Two optional modules extend it:
- Identity readiness. Whether you can give each agent its own identity, stop an agent acting beyond the person it works for, and revoke one agent without affecting others. It includes a check of the agents built into your SaaS platforms for ShareLeak-type paths.
- Operation catalogue design. Up to five business operations specified in full, with the process owners: inputs, systems touched, validation, approval gates and who may call them, ready to build. A larger catalogue is a follow-on engagement.
After the review, the work follows a set order. First, retire or register the raw credentials and complete the catalogue. Then build the operations on the integration layer and publish them through Enterprise MCP. Finally, keep the catalogue owned and current. Publishing comes after the credentials are dealt with, because an Enterprise MCP server in front of the same shared service account looks like progress and changes nothing.
We work alongside your identity and security teams, and their partners, on the parts that sit with them.
Where to start
You don't need all of this on day one. You need one system of record and three questions:
Can you revoke a single agent?
Can you say what it did?
Is raw API access to that system the exception?
f the answer to any of them is no, the decision about what your agents can do is still being made by whoever built the last MCP server, and by anyone holding a key.
If you'd like help working through that list, or want to talk through an Agent Access Review, book a conversation with our team.
Related reading: Before You Scale AI Agents, Govern the Ones You Can't See
.png)
