MCP server security is now an identity governance problem

At a glance

What this is: This is an independent analysis of MCP server security and the key finding is that securing the channel requires more than TLS because context, identity, authorization, and monitoring all have to be enforced together.

Why it matters: It matters because IAM, NHI, and emerging agent governance programmes now have to treat MCP as an identity control plane, not just another API transport layer.

👉 Read Aembit's analysis of MCP server security for AI agents and identity controls

Context

Model Context Protocol, or MCP, turns the server that brokers agent tool calls into a security boundary, not just a transport. Once the server mediates context, tool selection, and payload delivery, any weakness in identity verification or authorization can become a data exposure path for non-human identities and agentic workflows.

The governance gap is that conventional API controls assume stable request patterns and clear caller intent. MCP traffic is more dynamic, more contextual, and easier to manipulate mid-session, which means identity teams need to think about context integrity, tool scoping, and behavioral monitoring as part of the same control plane.

Key questions

Q: How should security teams govern MCP servers in agentic workflows?

A: Security teams should govern MCP servers as identity enforcement points, not simple integration middleware. That means restricting tool access by workload identity, validating parameters at the server boundary, isolating session context, and monitoring behaviour for abnormal tool sequences. The goal is to make every agent action attributable, scoped, and reviewable before data moves.

Q: Why do encrypted MCP channels still leave AI agents exposed?

A: Encrypted channels stop eavesdropping, but they do not stop context manipulation, spoofed endpoints, or unsafe tool invocation. If the agent trusts malformed content or overbroad permissions, an attacker can still drive exfiltration or unauthorized actions through a valid-looking session. Encryption is one control layer, not a complete trust model.

Q: What do teams get wrong about least privilege for AI agents?

A: They often apply least privilege at the account level and stop there. In MCP environments, the real risk sits at the tool and parameter level because an authenticated agent can still overreach through permissive workflows. Effective least privilege must constrain what the agent can call, how often it can call it, and which data sources it can reach.

Q: Who is accountable when an agent leaks data through an MCP server?

A: Accountability sits with the teams that defined the trust boundary and the controls that failed to enforce it, usually identity, platform, and security owners together. If tool authorization, context validation, or monitoring was missing, the breach is a governance failure, not just a runtime incident. Shared ownership must be explicit before deployment.

Technical breakdown

MCP context manipulation and prompt injection

MCP servers pass structured context to agents, and that context can carry hidden instructions as easily as legitimate data. Prompt injection works when malicious text, embedded commands, or malformed payloads are delivered as trusted context and the agent executes them as part of normal workflow. The server may see only a valid message exchange while the agent behaves in an unsafe way. This is why content validation at the boundary matters, not just transport encryption. Practical implication: validate and sanitize context before it reaches the agent, then isolate each session so injected state cannot persist.

Practical implication: validate and sanitize context before it reaches the agent, then isolate each session so injected state cannot persist.

Tool invocation abuse and authorization scope

In MCP, authentication proves identity, but authorization decides which tools, parameters, and usage patterns are acceptable. That distinction matters because an authenticated agent can still overreach if the server does not enforce fine-grained policy at the point of tool invocation. Parameter validation, rate limits, and audience-scoped credentials reduce the chance that a permitted call becomes a scanning or exfiltration path. The core architecture issue is that agent workflows are permissive by design, so tool access must be constrained independently of session success. Practical implication: enforce tool-level policies on the server, not in the agent, and log every invocation with context.

Practical implication: enforce tool-level policies on the server, not in the agent, and log every invocation with context.

Why transport security alone does not secure MCP

TLS protects the channel from passive interception, but it does not guarantee that both endpoints are real, that the payload is honest, or that a request is safe to execute. In MCP deployments, attackers can still exploit spoofed servers, manipulated parameters, and malicious context even when the connection is encrypted. Mutual TLS, certificate validation, sender-constrained tokens, and selective pinning strengthen endpoint assurance, but they only work when combined with behavioral monitoring. The lesson is that MCP security is a layered control problem, not a single protocol setting. Practical implication: build defense in depth across identity, transport, context, and monitoring instead of assuming encryption closes the risk.

Practical implication: build defense in depth across identity, transport, context, and monitoring instead of assuming encryption closes the risk.

Threat narrative

Attacker objective: The attacker wants to manipulate an agent into disclosing sensitive information or executing privileged actions through trusted MCP interactions.

1. Entry occurs when an attacker places malicious instructions into context or intercepts an MCP session that an agent trusts as legitimate.
2. Escalation follows when the agent accepts manipulated tool parameters, reveals internal state, or invokes privileged tools on the attacker’s behalf.
3. Impact occurs when the attacker uses those tool calls to exfiltrate sensitive data or alter operational decisions without ever stealing a password.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

MCP security is now an identity governance problem, not a transport problem. The moment a server brokers tool calls, the security boundary shifts from packet inspection to control of who may act, what they may access, and which context they are allowed to trust. Encryption is necessary, but it does not govern intent, tool scope, or session-level abuse. Practitioners should treat MCP as part of the identity plane, not a separate integration layer.

Context integrity is the missing control in most AI workflow designs. Traditional IAM assumes the request is the request. MCP breaks that assumption because the context itself can be weaponized, and the attacker’s leverage comes from reshaping what the agent believes is true mid-stream. That creates a new governance concept: contextual integrity debt, where the enterprise has authentication and logging but no reliable assurance that the content being acted on is legitimate. Practitioners must recognize that logged access is not the same as trustworthy context.

Granular tool authorization has become the practical limit of least privilege for AI systems. A general allow-or-deny model is too coarse when agents can chain tool calls, change objectives within a session, and move from one data source to another without a human in the loop. The control gap is not the absence of IAM, but the absence of policy at the tool and parameter layer. Security teams should expect their existing privilege models to fail if they cannot express tool-specific boundaries.

Machine identity controls must extend into behavioral verification. Workload identity, mTLS, and short-lived credentials reduce the chance of impersonation, but they do not answer whether the authenticated workload is behaving as expected. MCP deployments need observability for unusual context size, frequency, tool sequences, and cross-session anomalies because a valid identity can still be used maliciously. Practitioners should align NHI governance with runtime monitoring, not treat them as separate programmes.

AI governance will increasingly be judged by how it constrains agent-mediated data movement. The enterprises that get ahead here will be the ones that define policy at the communication boundary, not only at the account boundary. That means identity teams, platform teams, and security operations must share ownership of MCP controls. Practitioners should prepare for MCP to become a reference architecture question in both NHI and agentic AI governance.

From our research:

• 53% of MCP servers expose credentials through hard-coded values in configuration files, according to The State of MCP Server Security 2025.
• Another finding from the same research shows that only 18% of MCP server deployments implement any form of access scoping for tool permissions.
• For a broader view of the surrounding risk pattern, see Top 10 NHI Issues for how secret exposure and overbroad access combine in machine identity programmes.

What this signals

Context-aware controls will become the differentiator for AI infrastructure security. A platform can authenticate an agent and still fail if it cannot verify what the agent is being asked to do at runtime. That is why MCP hardening needs to converge with workload identity, policy enforcement, and session monitoring instead of living as a separate integration checklist.

The practical signal for IAM and NHI teams is that secret reduction alone is not enough. If a service can still receive broad tool access or accept poisoned context, the organisation has reduced credential risk but not decision risk. The control agenda now shifts toward observable, scoped, and attributable agent interactions.

Contextual integrity debt: this is the gap that appears when the organisation has authentication and logging but no assurance that the data being acted on is trustworthy. Teams should expect this concept to show up in architecture reviews because it captures the failure mode more precisely than generic access risk does.

For practitioners

• Enforce tool-level policy at the MCP server boundary Define which agents can invoke which tools, under what attributes, and with which parameter limits. Put the policy where the request is mediated, not inside agent logic, so a compromised or misled agent cannot bypass it.
• Validate and isolate all context before agent consumption Sanitize structured fields, reject malformed payloads, and clear session memory at the end of each interaction. Use fresh context scopes so one session cannot contaminate another under concurrent load.
• Bind workload identity to short-lived credentials Use verified workload attributes, short validity periods, and audience-scoped tokens so one credential cannot be replayed across servers. Pair that with certificate validation and selective pinning for exposed endpoints.
• Monitor behavioural drift across agent-server sessions Track request frequency, tool sequence patterns, context size, and abnormal retries so you can spot prompt injection, scanning, or misuse that passes authentication checks. Send anomalies into existing SOC workflows.

Key takeaways

• MCP servers create an identity boundary where context, tool use, and authorization must be governed together.
• Hard-coded credentials and missing tool scoping show that many deployments still rely on trust assumptions rather than enforceable policy.
• Practitioners should move MCP into the same control discussion as workload identity, least privilege, and runtime monitoring.

Key terms

• Model Context Protocol: A protocol that lets AI agents exchange context and call tools through a structured server interface. In security terms, it becomes part of the trust boundary because it can carry both legitimate instructions and malicious manipulation if identity and context controls are weak.
• Context integrity: The assurance that data passed into an agent has not been altered, poisoned, or framed in a way that changes unsafe behaviour. For MCP and agent workflows, context integrity is a control objective, not just a data quality issue, because the agent may act on the content directly.
• Tool authorization: The policy decision that determines which tools an authenticated agent may invoke, with what parameters, and under what conditions. It is more specific than login success and more important than raw connectivity because it limits what an agent can actually do once inside the trust boundary.
• Workload identity: A machine identity used by services, containers, and agents to authenticate without relying on persistent shared secrets. In agentic environments, workload identity should be paired with short-lived credentials and runtime policy so the identity proves who the actor is without granting broad standing access.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Aembit: MCP server security for AI agents and identity controls. Read the original.