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 point Claude, Copilot or ChatGPT at it. 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.
So the real question has two halves: who decided which tools your agents can use, and can anyone go round that decision. Today the first answer is usually "whoever built the MCP server," and the second is "anyone holding the credential behind it." Neither is a decision your organisation actually made.
Most organisations already have some controls here. Admin approval for new app registrations, short-lived tokens, network restrictions, API gateways — all of it helps. It stops unapproved applications from connecting.
It does 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. Share one key across several agents and you cannot revoke one without breaking the others.
This is common. VentureBeat's June 2026 research (107 organisations, weighted to the mid-market) found 69% run agents with shared credentials somewhere, and only 32% give every agent its own scoped, managed identity. Gravitee's 2026 survey of more than 900 practitioners found 45.6% rely on shared API keys for agent-to-agent authentication. It matches what we see in client estates: shared service accounts and long-lived keys are the norm, and agents are being wired straight into them.
None of this is new in principle — a person with an API key could always write a script. What's changed is the effort, now close to zero; the speed, now machine speed; and the source of instructions, which now includes any content the agent happens to read. The safe working assumption: every approved credential becomes an agent credential the moment a model can reach it.
OAuth decides whether a caller can connect. It says nothing about what the caller does once it's 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's 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 clean example — an attacker dropped a crafted message into a public comment field, the agent read it as an instruction, queried SharePoint and emailed the data out, all through connections it was authorised to use.
The scale of the gap is measured, not guessed:
📉 63% of organisations cannot enforce purpose limits on AI agents, and 60% cannot terminate one that is misbehaving (Kiteworks).
📉 Only 18% have high confidence their identity and access management can handle agent identities (Cloud Security Alliance).
📉 Gartner expects around 40% of enterprise applications to include agents by the end of 2026, up from under 5% in 2025 — and 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 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 named the principle: Least Agency — the agentic counterpart to least privilege. It limits what an agent is capable of attempting, not just what it's permitted to do.
Most enterprises reach first for something they already own. None of it quite fits.
An API gateway controls who can call which endpoint. The endpoint is still the raw API, so an agent allowed to update a record can update any record, in any way the API permits. The gateway sees the call, 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. Useful, but anyone with a credential can still stand up 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," not "write to the vendor table." The difference is in what the enforcement point understands — not in buying another box.
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's better to know that before anything else is bought.
The 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.
It's a trade-off. An agent limited to defined operations can't improvise new multi-step work against your ERP that nobody has built yet. For systems of record, that's 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 — a design decision, not a model decision.
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 and see only the tools the organisation has decided to offer; the integration layer holds the connections to the systems behind them; every call is logged. Workato Enterprise MCP is one implementation — recipes (Workato's deterministic workflows) published as tools on enterprise-controlled MCP servers, with the platform holding the connections underneath. For an organisation already running Workato, the integrations it has built become the starting catalogue of what agents are allowed to do.
But Enterprise MCP 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. Take them deliberately, up front — not one ticket at a time.
🪪 The identity boundary. Each call should trace to the person the agent is acting for: delegated (on-behalf-of) tokens rather than a shared "the bot" service account, delegated scope that never exceeds the person's own, and a separate identity per agent so one can be revoked without touching the rest. Most estates can't do all of this today, which is why it's a design decision, 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's enforced for the paths that pass through it. Agents built into SaaS platforms like Copilot Studio or Agentforce act through the vendor's own path — a separate control surface, assessed on its own terms.
💥 The blast radius. What a credential could reach in the wrong hands, and how fast 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, 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's usually where a control plane either keeps working or quietly decays.
🪪 Identity boundary — every call traces to a real person, so you can revoke one agent without breaking the rest.
⚙️ Execution boundary — decide which operations exist at all, and which systems are never reachable with a raw credential.
🎚️ Least Agency — each agent gets only the authority its task needs, enforced at the layer the calls pass through.
💥 Blast radius — know what a leaked credential could reach, and how fast you can shut it down and account for it.
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. The 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 visible from platform records, plus a sample of shadow paths — desktop MCP configs, 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's 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 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, not a decision.
📊 A baseline and roadmap. Where you stand today on three measures — can you revoke one agent, can you say what it did, 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 — including 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 their 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 last, 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.
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?
If 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