MCP, AI Agents, and the Governance and Security Blind Spot Nobody Is Talking About
Why identity and access is broken in an agentic world and MCP, and how enterprise middleware can fix it.
MCP, AI Agents, and the Governance and Security Blind Spot Nobody Is Talking About
Why identity and access is broken in an agentic world and MCP, and how enterprise middleware can fix it.
Everyone is talking about AI agents. Most of the conversation is about capability, what can the agent do, what data can it reach, how fast can it work.
Almost nobody is talking about what happens when it goes wrong.
After a deep dive into MCP architecture, identity and access controls, shared human and agent access, and the role enterprise middleware can play, here is what every enterprise deploying agents needs to understand before they go to production.
What MCP actually is, and what it is not
MCP stands for Model Context Protocol. Think of it as a universal connector standard that lets AI agents communicate with external tools, data sources, and services in a consistent, predictable way.
MCP has three core components:
The MCP Host: The application your agent lives inside (Claude, an IDE, a custom app). It contains an MCP Client that speaks the protocol.
MCP Servers: Lightweight programs that each wrap a specific capability: a CRM, a database, a web search tool, a file system. Each server exposes tools (actions the agent can call), resources (data the agent can read), and optionally prompts (pre-built templates).
The Protocol itself: a standardized JSON-RPC message format that any compliant host can use to talk to any compliant server.
The big idea: instead of every AI application building its own one-off integrations with every data source, MCP gives you a standard interface. Build one server for your database and any MCP-compatible agent can use it.
MCP is a protocol, not a directory. Your agent knows how to speak MCP, but it does not automatically know what servers exist. You wire those connections up explicitly in a configuration file.
How the agent discovers what it can do
This is one of the most misunderstood aspects of MCP. There are two distinct moments:
At agent startup: The agent reads a config file listing the MCP servers available to it. It then connects to each server and requests its capabilities, every tool, its name, and its parameters. Each server responds with its full menu, which the agent stores. This happens once, at initialization, before any user request is made.
At request time: When a user says something like ‘pull up the customer profile for Acme Corp,’ the agent, the LLM, reads the request, looks at the menu it already has, decides which tool to call and with what parameters, and fires it. The server’s job is to receive that specific call and execute it.
The intelligence, figuring out which tool to use, lives entirely in the agent. The server is a capable executor, not a decision maker. It does not interpret natural language. It does not choose what to do. It waits to be told.
This also means that exposing too many tools to an agent is actively harmful. Give an agent 500 available tools and it will get confused, slow down, and make more mistakes. Scope your agent’s toolbelt tightly to what it actually needs for its specific job.
The identity and access problem nobody is solving properly
Here is where most enterprise agent deployments are quietly sitting on a liability.
In a traditional REST API world, the trust chain is direct and clean:
User → Application → REST API → Salesforce
Salesforce sees the user’s token. Every call is traceable to a specific human. IAM works exactly as designed. Audit logs are clean. Licensing is respected.
In the MCP and agent world, that chain gets broken:
User → Agent → MCP Server → Salesforce
Now there is an autonomous decision maker in the middle, the LLM, that is not a human, not a traditional application, and was not anticipated by any IAM framework designed in the last twenty years.
This breaks traditional identity and access in several specific ways:
Identity is blurry. Is the caller the user, the agent, or the MCP server? Traditional IAM was designed for humans and service accounts. An agent is neither.
Consent is assumed. In REST, the user explicitly clicks a button. With an agent, the user makes one natural language request, and the agent may make multiple downstream API calls the user never individually authorized.
Least privilege becomes almost philosophical. Do you scope access to what the agent might ever need, or what it needs for this specific task? Too broad and you have blast radius risk. Too narrow and the agent fails mid-workflow.
Non-repudiation disappears. You need to prove a specific human took a specific action. When an agent acts on behalf of a user, who is legally responsible?
The shared access problem, 100 users, one agent
Consider a scenario: 100 support reps, all querying the same CRM agent. The agent potentially has access to all of their combined data. Without deliberate design, a rep asking ‘show me the biggest deals in the pipeline’ could get back deals from across the entire sales organization, data they were never supposed to see.
The industry has experimented with ‘agents inheriting user rights’ as a solution. It sounds clean.
But in complex or autonomous workflows it falls apart immediately.
In multi-agent workflows, which agent in the chain holds the user’s credentials?
Does each agent inherit the full rights?
What happens when the workflow runs overnight with no human present?
The right answer is straightforward in principle but hard to implement in practice: the user’s identity must flow through every hop in the chain.
User to agent to MCP server to Salesforce. If identity breaks at any point, every user’s view collapses into the agent’s view, and your 100 reps are all looking through the same eyes.
Access control belongs in the system that owns the data. Any architecture that intercepts the identity chain and tries to re-enforce permissions in a middleware layer takes on a burden it was not designed for, creates drift risk, and moves enforcement away from where it is most reliable.
For Salesforce specifically, this means per-user OAuth tokens passing all the way through so Salesforce’s own native permission model does the scoping. Salesforce already knows what each rep can see. Let it do its job.
Where middleware changes the entire story
Enterprise integration middleware, webMethods, MuleSoft, and others, has been solving cross-system connectivity and access governance for decades. It was not built for AI agents. But the problem agents need solved is almost exactly the problem middleware already solved for ETL pipelines, BI tools, and API integration.
Here is the architecture that mature enterprises will converge on:
The middleware becomes your MCP server. It already has IAM baked in, OAuth, SAML, role-based access, audit logging. Now you expose it as an MCP endpoint to your agent. You have not added a new vendor. You have added a new protocol to infrastructure you already trust and govern.
Identity flows through the middleware correctly. Per-user credentials travel with every call. You own that enforcement layer, not a third party.
Native MCP servers handle tier-one platforms. For Salesforce, use their own native MCP server where identity flows all the way through and Salesforce enforces its own rules natively.
Data Integration tools can handle the long tail. Legacy SAP instances, on-premise Oracle databases, niche industry SaaS that will never build their own MCP server. That is where connector library value is real and irreplaceable.
Taken further, the middleware can itself deploy and manage multiple MCP server instances in containers, one scoped to CRM, one to orders, one to knowledge, one to analytics, each independently scalable, each failing in isolation, and each presenting only the tools relevant to the agents that need them, creating a far more granular, resilient, and manageable architecture than any single monolithic MCP server could provide.
The result: you have separated three concerns that most people conflate. IAM and governance lives in your middleware, which you own. Connectivity to hard systems goes through specialist connectors used narrowly. Native platform capability stays with the platform owner. No single vendor becomes load-bearing across all three.
The governance layer, stopping rogue agents in their tracks
This is the piece that most deployment conversations are not having at all.
An LLM can be manipulated. Prompt injection, jailbreaking, a cleverly worded request that confuses the model, these are real attack vectors.
When middleware sits in or alongside your orchestration layer, it can enforce deterministic policy rules on every agent request before it reaches your data. Not AI rules, hard rules that execute the same way every time regardless of what the LLM was told or how it was manipulated.
Rate limiting. A legitimate support rep does not make 500 API calls in 60 seconds. A runaway autonomous agent or a compromised session might. Stop it.
Anomaly detection. The middleware knows what normal looks like. A rep who typically calls get customer 20 times a day suddenly calling list all customers at 2am is a pattern worth flagging before any data leaves.
Action allow-lists. A customer support agent has no business calling delete account or export all contacts. Those tools simply do not exist for it, not just unscoped, actively rejected at the middleware level even if the LLM tries.
Blast radius caps. Legitimate actions are almost always singular. An agent requesting a bulk update of 10,000 records is almost certainly wrong. Hard stop.
Human confirmation gates. Certain classes of actions, write operations, deletions, anything touching financial data, always require explicit human confirmation before the middleware lets them through. The agent proposes. The human disposes.
Context awareness. If this agent was invoked for a single support ticket, a request to pull data completely unrelated to that customer is out of scope. Flagged and halted.
This is the reason middleware is the right place for this, not the agent itself, security should never live in the LLM layer
Middleware is deterministic. It does not reason. It does not get confused by a clever prompt. A rule that says ‘never allow bulk deletes’ executes the same way every single time.
Where the industry actually is
Most organizations deploying agents right now are cutting corners on auth because the tooling is new and the pressure is to ship fast. They are using shared service accounts, ignoring audit trails, and trusting the LLM to make correct security decisions. That assumption will break. It is a matter of when and how visibly.
The organizations that will have the smoothest agentic adoption over the next three years are the ones making deliberate architectural decisions now, about identity propagation, about middleware governance, about where enforcement lives and who owns it.
MCP is a powerful and genuinely important standard. But it is a protocol, not a security framework. The security architecture around it is entirely up to you.
The agent should have the freedom to be intelligent and flexible, inside a hard box defined by your middleware, with identity flowing correctly, access scoped precisely, actions governed by deterministic policy, and every request logged with full context.
That is where enterprise AI architecture needs to land. Most organizations are years away from thinking this clearly about it. The ones who start now will be glad they did.
What are you seeing in your own agent deployments? Are the identity and governance questions getting the attention they deserve?