When agent connectivity becomes an identity problem

Every security architect has had this conversation.

“We’re just connecting the model to a few tools.”
“It’s all behind OAuth.”
“It’s read-only… mostly.”

And then, as if by sleight of hand, the model can now open tickets, rotate keys, query production data, approve workflows, and call cloud APIs at machine speed. This is the place where MCP security can no longer be theoretical, and has to be a consideration in any org that wants to embrace the future of business.

Model Context Protocol (MCP) is designed to let AI systems connect to our external tools and data sources in a structured way. It standardizes how models discover and call those tools. It’s often compared to OpenAPI, a specification designed to formally describe how APIs are structured and how they should be used. Google’s overview puts it in plain and simple terms: MCP enables LLMs to access real systems and potentially execute code or operations. Once that happens, our helpful AI assistant stops being a chatbot and becomes an actor in our environment.

The protocol is neutral. The risk is not.

The Governance Gap is Very Real

Before we even get into MCP security architecture, it’s important to consider the environment agents are landing in:

• 47% of organizations have implemented specific GenAI security controls. [Microsoft]
• 70% of organizations rank AI as a top data security risk. [Thales]
• From an analysis of hundreds of thousands of cloud identities, 99% had excessive permissions. [Unit 42]

Now add in MCP. If our human users are overprivileged, our agents will be too. And agents are on 24/7.

MCP Security Isn’t Just OAuth

The MCP specification mandates OAuth 2.1-based authorization patterns and secure consent flows. That’s good. But OAuth is plumbing, not policy. OAuth answers “Who is the caller?” and “What scope was granted?”

It doesn’t answer:

• Is that scope excessive?
• Is it time-bound?
• Is the effective permission larger than intended?
• Is the backend service account a silent super-admin?
• Has anyone reviewed this access in the last six months?

OAuth alone does not equal least privilege, and MCP security fails when architects assume it does.

The Real MCP Threat Model

Prompt Injection Meets Tool Execution

OWASP ranks prompt injection as the top risk in LLM systems, and the UK’s NCSC rightly states prompt injection is not like SQL injection; it’s harder to reliably mitigate because models cannot cleanly separate data from instructions.

In an MCP-enabled system, injection doesn’t just produce bad output. It can trigger tool calls.

A malicious string embedded in a Git repository, a support ticket, a wiki page, or even something as innocuous as a customer email, can instruct the model to use an MCP tool in ways we didn’t intend. If that tool can export data, modify IAM, generate credentials, or approve changes, our “chat assistant” just became an automation engine with lateral movement potential.

MCP security principle #1: the model must never be your enforcement layer. The tool boundary must be.

Excessive Permissions Amplified

If 99% of cloud identities have excessive permissions, now consider a typical MCP deployment pattern: One backend service account, broad API scopes, long-lived tokens, and multiple tools sharing the same credential. That’s not “agentic innovation.” That is identity debt with better branding. Agents accelerate whatever identity posture we already have. Good or bad.

Configuration And Supply Chain Exposure

MCP lowers the friction of adding tools. Which lowers the friction of adding the wrong tool.

Check Point Research disclosed vulnerabilities in Anthropic’s Claude Code that included exploitation paths involving MCP servers, leading to remote code execution and API token exfiltration through malicious project files. The takeaway for security architects isn’t vendor-specific. It is structural:

When configuration becomes executable context, our tool registry becomes part of our attack surface. MCP security must therefore treat tool definitions, MCP server manifests, extension repositories, and project configuration files as supply chain artifacts, not convenience files.

A Reference Architecture for Serious MCP Security

Security architects don’t need more warnings. They need patterns.

1. Workload Identity Per Agent and Per Tool Server

No shared tokens. No human API keys reused for automation. No “temporary” super-admin service accounts that become permanent. Each MCP server runs under a distinct workload identity, bound to environment, function, and owner. It’s not one feature. Success is a combination of Zero Standing Privilege + Just-In-Time Access + Entitlement Governance. That stack is what turns “distinct workload identity” from a slideware idea into something we can actually prove to an auditor, without digging through our tickets like some digital archaeologist.

2. Operation-Level Scoping, not Role-Level Guesswork

Scopes should map to discrete operations, not vague roles.

“ReadCustomerList” is defensible. “AdminAccess” is not.

Tokens must be short-lived and renewable through policy checks. Sensitive actions should require step-up controls or explicit approval workflows.

This is where modern cloud identity security platforms come into play:

• Discover effective entitlements across AWS, Azure, GCP, and SaaS.
• Identify toxic permission combinations.
• Eliminate standing privilege wherever possible.
• Replace persistent access with just-in-time elevation.
• Continuously review service principals and agent identities.

Without this, MCP security becomes theater.

3. Enforce Policy Outside the Model

The model suggests. The policy engine decides. Tool calls must be validated against strict schemas, parameter constraints, allowlisted operations, and contextual risk signals.

Every tool invocation should produce structured logs including caller identity, scope used, parameters, decision outcome, and downstream API action. Think distributed tracing for privilege.

4. Treat Agents as Digital Employees

Agents have roles. Agents have managers. Agents should undergo access reviews.

When we say “digital employees,” agents should have a unique identity, a defined role, bounded access, managerial ownership, temporary privilege elevation, ongoing reviews, and full auditability. That’s effective identity governance.

Microsoft’s AI security research repeatedly frames AI systems as new identity actors that require oversight and governance, not blind trust. That framing is exactly right. If our IAM governance excludes agents, our MCP security posture is incomplete.

Answering the Hard Questions

MCP is not inherently dangerous. It is an elegant integration pattern. But, MCP security is fundamentally an identity architecture problem:

• Who can act?
• With what effective permissions?
• For how long?
• Under whose approval?
• With what audit trail?

If we can’t answer those questions clearly for every MCP-connected agent in our estate, we don’t have agentic security. If we can’t prove least privilege to an assessor we have automation optimism. And optimism, as we all know, is not a control.

‍