MCP Client Approvals Are Becoming the Real Implementation Bottleneck for Enterprise AI Agents

Tools & Technical Tutorials

13 April 2026 | By Ashley Marshall

The MCP protocol solved tool connectivity. Nobody solved who gets to approve what - and that gap is now the primary reason enterprise agent deployments stall before they reach production.

Why Everyone Solved the Wrong Problem First

Model Context Protocol (MCP) adoption has been one of the fastest enterprise standards rollouts in recent memory. By the first half of 2025, all ten of GitHub's top new agent-related repositories were either building MCP infrastructure or integrating directly with it. OpenAI officially adopted the standard in March 2025. Microsoft shipped MCP support for VS Code Copilot shortly after. Pinterest deployed a full internal MCP ecosystem running domain-specific servers for Presto, Spark, and Airflow - saving an estimated 7,000 hours per month as of January 2025 with 844 active users generating 66,000 server invocations monthly.

The protocol clearly works. Connecting a language model to a tool is now a solved problem. You stand up an MCP server, register it with a client, and the agent can call it. The developer experience around this is genuinely good, and tooling has matured rapidly.

But here is what nobody talks about in the press releases: permission models are a complete mess, and that mess is what is actually preventing enterprise deployments from going live.

The UK's AI Safety Institute made this concrete in a landmark study that analysed 177,436 agent tools created between November 2024 and February 2026. The finding that security and compliance teams are now quoting in board presentations is this: agents are rapidly shifting from passive observation to real-world action, and the security industry has not kept up. MCP servers with payment execution capabilities alone grew from 47 servers in January 2025 to 1,578 by February 2026. That is not a gradual evolution - that is explosive growth in the capacity for agents to do things with real financial and legal consequences.

What this means in practice is that when a CTO or CISO sits down to review an enterprise agent proposal, the conversation is no longer about whether MCP works. It is about who approved this tool call, what data did it access, is there an audit trail, and what happens when the agent does something wrong. These are not easy questions to answer with the current state of client-side approval tooling.

The organisations moving fastest on agentic AI are the ones who recognised early that the protocol was only half the problem. They invested as much in permission architecture as they did in capability. The ones that treated MCP as a finished solution are the ones stuck in security review cycles six months after their pilot.

What MCP Client Approval Actually Means - and Why It Is Harder Than It Looks

When people talk about MCP permissions, they often conflate two different problems that need separate solutions. The first is authentication - proving that the agent and the client are who they claim to be. The second is authorisation and approval - deciding what actions should be allowed, under what conditions, and whether a human needs to be involved before an action executes.

Authentication is largely solved. OAuth 2.1 with PKCE has become the standard for remote MCP server connections. Amazon Bedrock's AgentCore Gateway, Splunk's MCP Server 1.1.0, and ServiceNow's MCP implementation all support it. Short-lived access tokens, typically valid for 15 to 60 minutes, are now the norm. Existing enterprise identity providers - Okta, Azure AD, Google Workspace - can be integrated through tools like Scalekit so that MCP servers validate tokens the same way any other enterprise application does. This part of the stack is mature.

Authorisation is where things fracture. The core problem is that MCP's permission model is tool-scoped, but enterprise risk is action-scoped. Granting an agent access to a Salesforce MCP server does not mean it should be able to bulk-delete records, mass-email contacts, or modify billing data. The tool has one permission. The actions within it have wildly different risk profiles. Most MCP clients do not have native mechanisms for action-level permission control. You have to build it yourself, or accept that the agent has broad access to everything the tool exposes.

The approval gate problem compounds this. The most important question in enterprise agent design is not whether an agent can do something - it is whether it should do it without asking first. Security researchers at the UK's NCSC and practitioners implementing agentic systems at scale consistently arrive at the same conclusion: write operations, destructive actions, bulk updates, and external communications must pause for explicit human sign-off before execution. This requires a client-side mechanism that can interrupt an agent workflow mid-execution, surface a recommendation to a human reviewer, capture their decision, and then resume or reject the action.

This is not technically exotic. It is standard workflow design. But most MCP client implementations in 2026 either do not support it natively, or implement it in ways that are too coarse (every action requires approval, which negates the efficiency gain) or too permissive (no actions require approval, which creates liability). Getting the calibration right - automatic for low-risk reads, human-in-the-loop for writes, mandatory review for irreversible actions - requires deliberate design that most proof-of-concept implementations skip entirely.

What this means in practice is that enterprise teams are frequently forced to build custom approval middleware between the MCP client and the agent orchestrator. This is engineering time that was not budgeted, requires deep understanding of both agent architecture and internal compliance requirements, and often has to be rebuilt for each client implementation because there is no shared standard yet.

The Governance Gap the UK AI Safety Institute Identified

The UK's AI Safety Institute paper - formally titled 'How are AI agents used? Evidence from 177,000 MCP tools' - is important reading for anyone building enterprise agent systems. It is one of the few large-scale empirical studies of what agents are actually doing at runtime, rather than what vendors claim they can do. The Bank of England was involved in the research collaboration, which tells you something about how seriously UK financial regulators are starting to take agentic AI risk.

The core finding is that tools are becoming overwhelmingly action-oriented rather than retrieval-oriented. Early MCP usage was dominated by read tools - retrieve this document, query this database, fetch this record. That pattern is changing rapidly. Write, update, execute, and communicate tools are growing as a share of the ecosystem. Agents are not just looking at systems; they are changing them.

For enterprise governance, this shift is critical. Read operations have limited blast radius. If an agent retrieves the wrong record, the cost is confusion. If an agent modifies the wrong record, the cost could be a corrupted database, a compliance breach, or a financial error that takes weeks to unwind. The NCSC's guidance on AI security, and the ICO's emerging framework for automated decision-making under UK GDPR Article 22, both point in the same direction: systems that take consequential automated actions need explicit accountability mechanisms.

The 2026 iteration of the MCP specification introduced enhanced consent workflows, including multi-factor authentication for high-risk operations and audit logs that track user approvals in real time. This is progress. But specification features and client implementations are not the same thing. The specification can define a consent mechanism; whether your chosen MCP client actually implements it, and whether your enterprise IT team can integrate it with existing identity and access management systems, is a separate question entirely.

Forbes TechCouncil's analysis from April 2026 put it clearly: effective governance now requires controls at the 'tool-call boundary.' Traditional data loss prevention and access control systems were built for human users interacting with interfaces. They were not built for API-level calls that agents make in milliseconds, often summarising or transforming data before it reaches any egress point that legacy systems would flag. The whole approval and audit model needs to be rethought at the execution layer, not bolted on afterwards.

For UK businesses operating under the FCA's Consumer Duty, the ICO's AI guidance, or sector-specific requirements in healthcare and financial services, this is not optional. Regulators are not waiting for the technology to mature before they start asking questions. If your agent took an action that harmed a customer, you will need to show what approved it, when, and why. If you cannot, the accountability falls on the human organisation - not the model.

How Organisations Are Actually Solving This Right Now

Given that native MCP client approval tooling is still maturing, how are enterprises that are actually shipping agentic systems handling the problem? Three patterns have emerged from organisations doing this in production.

The first pattern is the approval gate architecture, which the bonjoy.com analysis of enterprise HITL implementations documents well. The agent executes autonomously through low-risk, reversible steps - reading data, running calculations, generating drafts - and then pauses at defined checkpoints before taking consequential action. The agent surfaces its recommendation: here is what I intend to do, here is my reasoning, here is what happens if you approve. A human reviewer - not necessarily a technical expert - confirms or modifies the action. The agent proceeds with the approved version.

This pattern works because it preserves the efficiency gain (the agent did all the research and preparation) while keeping humans accountable for the consequential decisions. The friction is proportionate. Low-stakes reads are automatic. High-stakes writes require sign-off. Irreversible actions - deletions, bulk communications, financial transactions - require documented approval with a named approver on record.

Pinterest's production MCP ecosystem illustrates a second pattern: the registry-based governance model. Their central MCP registry acts as the source of truth for approved servers and their connectivity metadata. Clients consult the registry to validate permissions and server status before calling tools, enforcing governance consistently across the organisation. Both a human-friendly UI and an API allow discovery, validation, and integration. This is governance baked into infrastructure rather than applied as a control layer after the fact.

The third pattern is permission tiering at the tool definition level. ServiceNow's MCP implementation, for example, recommends starting read-only and adding write operations only with approval workflows in place. This means the initial MCP server deployment has a limited blast radius - agents can see everything they need, but cannot change anything without going through a defined process. Write capabilities are added incrementally as approval workflows are validated and trust is established. This is slower than shipping everything at once, but it dramatically reduces the risk surface during the critical early months when unexpected agent behaviour is most likely.

What this means in practice is that organisations should plan for three distinct phases: capability deployment (getting MCP servers running and connected), permission architecture (defining what actions require what level of approval), and governance integration (connecting approval workflows to existing identity, audit, and compliance systems). Most pilots only plan for the first phase. The organisations hitting production are the ones that planned for all three from the start.

The Counterargument: Are We Over-Engineering Safety at the Cost of Value?

The counterargument to everything above is worth taking seriously, because it comes from people building real systems rather than theorising about them. The argument goes like this: every approval gate you add is friction. Friction reduces the efficiency gain that justified the agent investment in the first place. If every write operation requires a human to approve it, you have not automated anything - you have added an expensive intermediary step to a process that used to be faster. At a certain point, the agent is doing work for a human who still has to make every decision that matters.

This is a legitimate tension, not a strawman. The organisations that have shipped the most capable enterprise agent systems are often the ones that made deliberate choices to trust the agent with more autonomy than security-first teams would be comfortable with. They moved fast, shipped to production, and learned from real mistakes rather than theorising about potential failures in review meetings.

The honest answer is that both positions are partly right, and the right balance depends on context. In a low-consequence domain - internal knowledge retrieval, draft generation, data summarisation - aggressive automation with minimal approval gates is probably the right call. The blast radius of a mistake is small and recoverable. The efficiency gain is real and immediate.

In high-consequence domains - financial transactions, customer communications, regulated data, compliance filings, medical records - the calculus is different. A single error can cost more than the agent's entire projected annual saving. Here, approval gates are not over-engineering. They are risk management with a clear return on investment.

The real failure mode is not choosing the wrong policy for a given domain. It is applying the same blanket policy to every domain because it is easier than making context-specific decisions. That is what produces the worst outcome: either agents that are so restricted they add no value, or agents that are so unrestricted they create liability faster than they create efficiency. The way out is a tiered permission model that matches the approval requirement to the actual risk of the action - not a universal setting applied across the board.

Organisations that have worked through this successfully consistently describe the same turning point: when they stopped treating permissions as a compliance checkbox and started treating them as product design. Who is the user of this approval workflow? What information do they need to make a good decision? How long can this realistically take before it negates the agent's value? Answering those questions properly is what separates a functional enterprise agent from a stalled pilot.

What to Build Now: A Practical Permission Architecture for Enterprise MCP

Given everything above, what should an enterprise team actually build? This section outlines the minimum viable permission architecture for a production MCP deployment in a regulated environment.

Start with action classification before you write any code. For every tool your MCP server exposes, categorise each action into one of three tiers. Tier one is read-only and reversible: fetch, list, search, retrieve. These can run autonomously with logging only. Tier two is write and recoverable: create, update, draft, schedule. These should run with a lightweight approval step - a notification to the relevant human that captures their explicit sign-off before execution, but does not require them to be present at invocation time. Tier three is irreversible or high-consequence: delete, bulk update, external send, financial transaction. These require synchronous human approval - the agent must pause and wait for a named approver to confirm before proceeding.

Build your audit trail from day one, not as an afterthought. Every tool call should log the agent identity, the action requested, the data accessed, the approval state (automatic, approved by human, rejected), the approver identity if applicable, and the timestamp. This is not just good practice - it is the evidence you will need if a regulator asks what your agent did and why. The MCP 2.4 specification introduced real-time approval audit logs as a core feature; use them.

Use OAuth 2.1 with short-lived tokens and integrate with your existing identity provider. Do not create a parallel identity system for agents. Agents should operate with scoped tokens that inherit from the user or service account they represent. Most multi-agent workflows currently pass the user's full-scope token downstream - every sub-agent gets the same broad permissions as the original user. Scope tokens properly so each agent only has access to what it needs for its specific task.

Test your approval workflows with real users before going to production. The approval gate pattern only works if the humans in the loop can actually evaluate the agent's recommendations in reasonable time. If your approval UI requires a technical reviewer to parse raw JSON to understand what the agent wants to do, the workflow will fail in practice even if it passes in theory. Invest in the approval interface as seriously as you invest in the agent capability itself.

Finally, plan for the registry model as you scale. Pinterest's approach - a central registry that validates server permissions before any tool call executes - is the right target architecture for any organisation running more than a handful of MCP servers. Ad hoc permission management does not scale. A registry gives you a single place to enforce governance, update permissions, and audit access across the entire agent ecosystem.

Frequently Asked Questions

What is the difference between MCP authentication and MCP authorisation?

Authentication confirms that the agent and MCP server are who they claim to be - this is handled by OAuth 2.1 and is largely a solved problem. Authorisation determines what actions an authenticated agent is permitted to take, and whether a human must approve before execution. Enterprise deployments are struggling with authorisation and approval, not authentication.

Does the MCP specification include built-in approval workflows?

The MCP 2.4 specification introduced enhanced consent workflows, including support for multi-factor authentication on high-risk operations and real-time audit logs for user approvals. However, specification support and client implementation are different things. Whether your specific MCP client implements these features - and whether they integrate with your enterprise identity and compliance systems - requires separate verification.

How do we handle approvals when agents need to act faster than a human can review?

The answer is accurate action classification, not universal speed. Read operations and low-consequence writes can run autonomously with no human delay. Only genuinely high-consequence, irreversible, or regulated actions should require synchronous human review. If your approval process is slowing down actions that did not need approval, you have a classification problem rather than a workflow problem.

What are the UK regulatory implications for enterprise AI agents taking automated actions?

Under UK GDPR Article 22, automated decisions with significant effects on individuals require human oversight mechanisms. The ICO has issued guidance on AI and automated decision-making that applies to agentic systems acting on behalf of organisations. The FCA's Consumer Duty framework applies where agents interact with or make decisions affecting customers. NCSC guidance on AI security recommends explicit audit trails for consequential automated actions. Failing to document who approved an agent action creates liability that sits with the organisation, not the model.

Should every agent action require human approval?

No. Universal approval requirements negate the efficiency gain that justifies agent investment. The correct approach is tiered permissions: automated for low-risk reads and reversible writes, lightweight asynchronous approval for moderate-consequence actions, and synchronous mandatory review for irreversible or high-consequence actions. The calibration of which actions fall in which tier is the critical design decision.

What is the tool-call boundary problem the Forbes TechCouncil analysis identified?

Traditional data governance and access control systems were designed for humans using interfaces - browsers, applications, dashboards. Agents operate at the API layer, making tool calls in milliseconds, often summarising or transforming data before it reaches any egress point that legacy DLP systems would detect. Effective governance needs to be enforced at the point of tool invocation, not downstream. This requires a fundamentally different control architecture to what most enterprise security teams have deployed.

How does Pinterest's registry model work and is it suitable for smaller organisations?

Pinterest built a central MCP registry that acts as the source of truth for approved servers and their permissions. Before any agent calls a tool, the client consults the registry to validate permissions and server status. This enforces governance consistently without relying on individual client configurations. For smaller organisations running fewer than five MCP servers, a simpler permission configuration stored in a shared policy file achieves a similar effect. The registry model becomes essential as the number of servers, agents, and users grows.

What should go in an MCP tool call audit log?

At minimum: agent identity, the specific tool and action called, the parameters passed, data accessed or modified, the approval state (automatic, approved, rejected), the approver identity and timestamp if human approval was involved, and the outcome. Logs should be immutable and stored separately from the systems the agents operate on. For regulated industries, retention periods and access controls on the audit log itself are also part of the compliance requirement.