MCP and the new authorisation surface nobody is reviewing

Model Context Protocol has done in eighteen months what enterprise integration vendors spent a decade trying to do — given language models a stable, ergonomic way to call internal APIs. The cost is that almost every team adopting MCP has also quietly stood up a new authorisation plane that their IAM and security teams have not seen.

The reasoning goes like this. The agent framework needs tools. Tools are functions. Functions read and write to systems. Someone wires up an MCP server in a few hundred lines, points it at the corporate ticketing system or the CRM, and the agent can now create tickets and update opportunities. The team ships. Then the audit question arrives — when the agent updated this opportunity, on whose authority did it act, and where is the record? — and the answer is uncomfortable.

The pattern we keep seeing in reviews is that the MCP server runs as a single service identity with broad scopes, and individual user identities are passed as parameters in tool calls. The downstream system records the service identity as the actor. The agent platform records the user prompt as the trigger. Neither end has the linkage. If the agent does something the user did not ask for — because of prompt injection, hallucination, or instruction conflict — the only forensic artefact is a service account doing routine work.

The fix is unglamorous and well understood from older identity work, just newly applicable. Three things, in order.

Bind the user identity into the call chain. OAuth on-behalf-of, SAML actor tokens, or signed user assertions; pick whichever your platform supports. The user’s identity must propagate through the agent runtime to the MCP server to the downstream API. The downstream audit record should show the user as actor and the agent as the means. This is the same pattern Microsoft Graph, Salesforce, and Okta have shipped for years for delegated access. The new surface needs the old discipline.

Scope the tools to the operation, not to the system. “Read CRM” is not a scope. “Read opportunity by ID” is. MCP’s tool definition surface lets you express each callable as a discrete capability. Use that. The agent should be issued only the tools it needs for a session, ideally short-lived. The “give the agent everything and trust the model not to misuse it” position is not defensible under any framework we operate against. ISO 42001’s Annex A.6 (operational planning and control) reads almost like an MCP scoping checklist.

Log the prompt, the tool call, and the response in the same record. Most MCP server implementations log the call but not the prompt that triggered it; most agent platforms log the prompt but not the resulting tool calls. Reconstruction requires both, joined by a correlation ID. Add the correlation ID to your standard log schema and require it across the agent runtime, the MCP server, and the downstream system. Without it, the answer to “why did the agent do this?” is forever speculation.

The deployment we reviewed last month had a fourth issue worth mentioning. The MCP server was internet-exposed for convenience during pilots, with a single static API key for authentication, the kind of thing that would never pass a security review for any other internal API. Internal MCP servers should sit behind the same identity-aware proxy or service mesh as everything else, and external MCP integrations (vendor-supplied, or community-maintained) should be treated as third-party connectors with full vendor risk review including data residency and revocation. Treat them as part of your supply chain, because they are.

The good news is that none of this is novel. The OAuth 2.0 token exchange RFC, the actor token spec, and standard SIEM correlation patterns all exist and are battle-tested. The bad news is that the speed of MCP adoption inside engineering teams is outpacing the security review cycle by about six months. If your organisation has agent pilots running, the practical step is a one-page architecture review of where MCP servers are deployed, what scopes they hold, what identity flows through them, and whether the audit record can answer “who authorised this action” in plain English. That is the question regulators will ask in the first incident, and it is much cheaper to answer it before there is one.