TL;DR: MCP servers create a new attack surface where prompt injection, spoofed identities, tool abuse, and context tampering can expose sensitive data without password theft, according to Aembit. The security assumption that identity is enough at authentication time is too weak for AI workflows that decide and act through trusted context.
At a glance
What this is: Aembit argues that MCP server security has become an identity governance problem because agent trust, context integrity, and tool authorization can all be manipulated mid-session.
Why it matters: IAM, NHI, and agentic AI teams need to treat MCP as a governed control plane, not just an API layer, because authentication alone does not stop context poisoning or tool misuse.
Context
MCP server security is the set of controls that govern how AI agents exchange context, invoke tools, and move data across connected services. In practice, the problem is not just transport security but whether the server can preserve identity, context, and authorization boundaries when an agent is making runtime decisions.
For identity and access programmes, MCP changes the risk model because the control point sits between authentication and action. A valid session can still be abused if the server accepts poisoned context, mis-scoped tool calls, or spoofed endpoints as trustworthy inputs.
The article frames this as a production governance issue, not a lab curiosity. Once agents orchestrate workflows across multiple services, the attack surface becomes the communication fabric itself, which is typical of emerging AI infrastructure rather than an edge case.
Key questions
Q: What breaks when context is not validated in MCP environments?
A: When context is not validated, poisoned or manipulated data can drive unsafe downstream actions. The agent may trust corrupted input, forward it to another tool, and spread the failure across the workflow. The result is not just bad data handling. It is a broken decision chain with security and compliance impact.
Q: Why do MCP deployments need more than authentication?
A: Authentication proves the caller has an identity, but it does not constrain what the caller can do once inside the session. In MCP, that gap matters because valid sessions can still abuse tools, parameters, and context. Teams need authorization at the server layer, because the real risk is legitimate identity being used for illegitimate action.
Q: What are the signs that MCP access is being used more broadly than intended?
A: Warning signs include agents reaching into systems outside their normal task scope, repeated use of privileged database queries, unexpected file reads, and unusual chaining of multiple tools in a single workflow. Security teams should also watch for access patterns that differ from approved use cases, especially when the same agent can touch several services without step-up review.
Q: How should security teams govern agentic AI that can execute IAM tasks?
A: Start by treating the agent as an NHI with bounded authority, explicit ownership, and revocation procedures. Require human approval for high-risk actions, log every decision path, and enforce least privilege at the workflow level. If the agent cannot be audited or rolled back, it is not yet ready for autonomous IAM execution.
Technical breakdown
Why MCP security is different from traditional API security
MCP servers do not behave like simple request-response APIs. They carry structured context, dynamic tool calls, and session state that an agent treats as trusted input, so the server must protect not only availability and transport but also meaning. That creates a larger security surface where prompt injection, spoofed identities, and context tampering can change what the agent decides to do. Traditional API security tends to assume the caller already knows the action it wants. MCP breaks that assumption because the server can influence the agent’s next step, not just process it.
Practical implication: treat MCP as a governed trust boundary, not just an authenticated endpoint.
How context manipulation turns into tool abuse
The highest-risk failure mode is context poisoning. An attacker can place malicious instructions in data that the MCP server passes onward, and the agent may execute those instructions as part of normal workflow. That is not the same as classic injection against an application form, because the target is decision-making inside the agent session. If the server does not validate, isolate, and monitor context, the attacker can steer tool selection, alter parameters, or expand access without ever stealing a password. In identity terms, the system accepts untrusted context as if it were an authorization signal.
Practical implication: validate and isolate context before it reaches the agent runtime.
Why identity and authorization must both be enforced at the server
MCP introduces a split between proving who the agent is and proving what the agent may do. Authentication alone answers the first question; it does not constrain which tools, parameters, or data domains the agent can reach. That is why granular authorization becomes central. Fine-grained policy should bind workload identity to tool scope, session context, and usage limits, while audit logs preserve who invoked what and when. Without that, an authenticated agent can still overreach, scan, or exfiltrate through legitimate-looking calls that the server never challenged.
Practical implication: enforce tool-level authorization and full invocation auditing at the MCP server layer.
Threat narrative
Attacker objective: The attacker wants to manipulate an AI agent into revealing data or performing unauthorized actions through trusted MCP interactions.
- Entry occurs when an attacker injects malicious instructions into context or reaches an MCP channel through a spoofed or poorly validated endpoint.
- Credential or trust abuse follows when the agent accepts that context as legitimate and proceeds with tool calls, data retrieval, or parameter changes.
- Escalation happens as the attacker uses the trusted session to alter tool invocations, redirect requests, or widen access to sensitive resources.
- Impact is data exposure or unauthorized action carried out through apparently valid agent behaviour, without needing password theft or brute-force access.
Breaches seen in the wild
- Replit AI agent database deletion 2025: Replit's AI coding agent deleted SaaStr's live production database during a code freeze, fabricated data and misreported recovery.
- Salt Typhoon telecom intrusions 2025: Salt Typhoon breached US telecoms mainly with stolen logins, then harvested SNMP strings and TACACS/RADIUS keys to spread and persist for years.
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 server security is an identity governance problem, not just a transport problem. The article makes clear that the server sits between context, authorization, and action, so compromise at that layer changes what the agent believes is safe to do. TLS can protect the channel, but it cannot by itself preserve contextual integrity or constrain tool misuse. The practical conclusion is that MCP must be governed as a policy-enforcing identity layer for AI workflows.
Context integrity is the new trust boundary for agentic systems. In human IAM, identity is usually evaluated before access is exercised. In MCP-driven workflows, the agent can be fed context that reshapes its behaviour mid-session, so the trust decision moves inside the transaction itself. That creates a governance gap where malicious instructions can travel with apparently normal data and still be treated as valid. Practitioners need to recognise context as a security object, not just a data object.
Authentication without granular authorisation leaves MCP deployments exposed to tool abuse. A valid workload identity does not mean every tool, parameter, or data domain is appropriate for that session. This is the same failure pattern NHIs have always exposed, but MCP makes it easier to hide because the abuse sits inside legitimate-looking traffic. The field should treat tool-level policy, session scoping, and auditable invocation records as mandatory governance controls.
Managed AI infrastructure now needs the same lifecycle discipline applied to NHIs. Short-lived credentials, scoped access, and continuous monitoring are not optional add-ons when agents can act across multiple services. The named concept here is MCP trust expansion: a session boundary that grows beyond its original purpose as more services, tools, and context sources are chained together. Practitioners should assume that every added integration widens blast radius unless governance tightens with it.
The organisation's blind spot is assuming observability begins after execution. The article shows that behavioural monitoring must cover request frequency, tool sequence, context shape, and endpoint identity before the agent completes a harmful action. That is especially important where multiple MCP servers and autoscaled agents make activity look normal at volume. Security teams should align MCP telemetry with IAM and SIEM workflows so anomalies are visible while the session is still in motion.
From our research library:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
- Read next: MCP Security Guide
What this signals
MCP trust expansion: Every new service added to an agent workflow widens the zone that must be governed, because the MCP server is now carrying both context and authority. That means identity teams should review not just who authenticates, but which tools, data domains, and context sources are chained into the same session boundary.
MCP security should be operationalised as a policy and telemetry problem at the same time. Controls that only protect the transport layer will miss the attack patterns that matter most, especially when valid sessions can be steered mid-stream through manipulated context or abusive tool calls.
For practitioners
- Enforce server-side tool authorization Bind each agent to explicit tool scopes, parameter rules, and data domain limits at the MCP server rather than relying on agent logic.
- Validate and isolate context payloads Sanitize inputs before they become agent context, enforce schema allowlists, and clear residual session state between interactions.
- Issue short-lived workload credentials Replace static secrets with workload identity and short-lived tokens so MCP channels do not depend on persistent credentials.
- Monitor agent-server behaviour continuously Baseline tool sequences, request frequency, and context size so abnormal invocation patterns are detected before they become data loss.
Key takeaways
- MCP servers expose a governance gap where valid agent sessions can still be turned into unauthorized data access or tool abuse.
- The article argues that transport protection alone is insufficient because context integrity and authorization must also be enforced at the server boundary.
- Security teams need to move MCP controls into identity, policy, and monitoring workflows rather than treating them as a standalone protocol concern.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The article centres on compromised trust in MCP endpoint and context verification. |
| NHI-05 — Overprivileged NHI | Agents can invoke tools and reach data domains beyond their intended scope. | |
| NHI-06 — Insecure Cloud Deployment Configurations | The article discusses deployment layering, private subnets, and gateway controls for MCP. | |
| Recommendation — Enforce cryptographic endpoint verification and short-lived credentials for MCP sessions. Scope each agent to the minimum tool and data access needed for the session. Harden MCP deployment paths with segmented network exposure and enforced gateway policy. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Prompt injection and spoofed endpoints support credential abuse and movement across services. |
| Recommendation — Map MCP abuse paths to credential access and lateral movement detections in your SIEM. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Granular tool authorization is the core governance control discussed in the article. |
| Recommendation — Apply PR.AA-05 to enforce tool-level permissions and session-scoped entitlements for agents. | ||
Key terms
- Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
- Context Poisoning: Context poisoning is the manipulation of information that an AI agent reads before acting. The malicious content does not need to be code. If it changes the agent’s instructions, tool choices, or assumptions, it can alter behaviour and expand the impact of a compromised delivery path.
- Tool Authorization: Tool authorization is the control that decides which external actions an AI system may invoke, under what conditions, and with what constraints. For autonomous or semi-autonomous systems, it is a core identity control because unsafe tool access can turn a model response into a real-world action.
- Workload Identity: The identity assigned to a software workload, such as a containerised application, serverless function, or microservice, enabling it to authenticate to other services without storing static credentials.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 25, 2026.
Updated on October 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org