MCP context poisoning is the new attack surface for AI agents

At a glance

What this is: This is Salt’s analysis of MCP context poisoning, where an AI agent’s operating context can be altered to redirect legitimate-looking actions into malicious behaviour.

Why it matters: It matters because IAM and security teams must govern the agent’s intent, role, and tool access before execution, not just inspect API calls after the fact.

Context

MCP context poisoning is a governance problem before it is a tooling problem. The article describes a situation where an autonomous AI agent keeps acting through valid APIs, but its internal mission briefing has been altered so the outputs no longer match the approved purpose.

For identity teams, the key issue is that agent behaviour now depends on persistent context, not just a static credential or one-off request. That makes authorisation, role assignment, and tool scope part of the runtime trust boundary.

The article’s scenario is atypical in one sense and increasingly typical in another: the exact attack path is novel, but the underlying failure mode is familiar because security controls still assume the intent behind each call is stable and observable.

Key questions

Q: What breaks when an agent relies on poisoned context or memory?

A: Future decisions break because the attacker has altered the agent's working state, not just one prompt. Poisoned context can survive across sessions, bias tool selection, and create repeated unsafe behaviour. That turns a single successful injection into a persistent governance problem rather than a one-off incident.

Q: Why do valid API calls still create risk in autonomous AI systems?

A: Because the risky part is often upstream of the call. If the agent’s goal, role, or constraints have been altered, each API request may be technically allowed while still serving a malicious objective. Security teams need to evaluate behaviour against intended purpose, not only against authentication status.

Q: How can security teams detect context poisoning in AI agents?

A: Look for behavioural drift, especially unexpected tools, new databases, altered output destinations, and role changes that do not match the agent’s approved mission. Detection works best when teams baseline normal task patterns and compare runtime activity to that baseline continuously.

Q: What should organisations do first when they start governing AI agent behaviour?

A: Start with the highest-impact workflows that touch customers, spend or sensitive data, then define purpose, allowed data, escalation rules and expiry for each one. That approach gives you the fastest risk reduction because it focuses on where intent drift causes the most damage.

Technical breakdown

How MCP context becomes the control plane for an AI agent

The article treats MCP as a mission briefing that carries the agent’s goal, tools, role, memory, and constraints. That is important because it turns the context bundle into the effective control plane for the agent’s behaviour. If an attacker can alter that bundle, the agent continues to act through legitimate interfaces while pursuing a different objective. Traditional security monitoring sees authorised API traffic, not the decision logic that produced it. In identity terms, the trust boundary moves upstream from request validation to context integrity.

Practical implication: protect the context store and the path that writes agent instructions, not only the downstream APIs.

Why valid API calls can still hide malicious intent

The core failure described is not authentication failure, but semantic abuse of authorised access. Each call can be syntactically valid, correctly authenticated, and still part of a malicious sequence if the agent’s internal instructions have been poisoned. That is why API gateways and firewalls may stay quiet. They are checking whether the call is allowed, while the real attack is changing what the agent thinks it is supposed to do. This is the same kind of mismatch that appears when authorisation is treated as static while runtime intent is mutable.

Practical implication: correlate API activity with agent purpose, not just with source identity and request shape.

How role drift turns agent identity into an escalation path

The article’s example shows a sales analyst role being rewritten into a database administrator role. That is role drift, but for autonomous systems it is more than a policy violation. It is a runtime identity rewrite that changes what tools are acceptable, what data can be touched, and what constraints apply. Once the role changes, the agent can inherit broader permission assumptions without ever presenting a new login event. For governance teams, the important point is that the role attached to an agent is now part of the attack surface, not just a label in a catalogue.

Practical implication: detect role drift as an identity event, not as a downstream application anomaly.

Threat narrative

Attacker objective: The attacker wants the AI agent to carry out unauthorised data access and exfiltration while appearing legitimate to normal monitoring.

1. Entry occurs when an attacker intercepts or modifies the agent’s mission briefing before execution, giving them control over the context the agent will follow.
2. Escalation happens when the poisoned context rewrites the agent’s goal, tools, role, memory, and constraints into a malicious operating plan.
3. Impact follows when the agent uses valid APIs to export customer records or send data to an external server, while traditional controls see only authorised activity.

Breaches seen in the wild

• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Context integrity is now an identity control, not an application detail: Autonomous agents do not just consume permissions, they execute from a mutable mission briefing that defines what they believe they are allowed to do. Once that briefing can be rewritten, authorisation no longer starts at the API gate. Practitioners should treat the instruction path as part of the identity boundary.

Valid API traffic no longer proves legitimate intent: The article shows why request-level monitoring misses the attack when every individual call is allowed. In an autonomous workflow, the control failure is not bad syntax or stolen login material, but malicious goal substitution before execution. That means behaviour baselining has to sit alongside authorisation, not behind it.

Role drift is the observable symptom of a broken trust model: A sales analyst agent that starts behaving like a database administrator is not simply anomalous. It is evidence that runtime identity assumptions have collapsed because the role attached to the agent can be changed midstream. Security teams need to recognise that the role catalogue is now an attack surface when an agent can be reprofiled on the fly.

Persistent mental state creates a new kind of blast radius: The article’s emphasis on memory and constraints shows that autonomous systems accumulate operational context over time, which can be poisoned incrementally or all at once. That makes the blast radius broader than a single request and narrower than a human account takeover. The governance challenge is to understand how far a corrupted context can steer the agent before anyone notices.

Named concept: context poisoning: This is the corruption of an AI agent’s operating context so the agent continues to behave through valid channels while pursuing attacker-chosen objectives. The phrase is useful because it distinguishes runtime intent compromise from credential theft or API abuse. Practitioners should use it to frame controls around instruction integrity, role drift, and behavioural verification.

From our research library:

• 53% of security leaders expect AI to run major portions of their infrastructure autonomously within the next three years, according to the 2026 Infrastructure Identity Survey.
• 19% of organisations give AI systems dramatically more access than human employees, nearly one in five granting unrestricted privilege, according to the 2026 Infrastructure Identity Survey.
• Read next: Agentic AI Identity Guide

What this signals

Context poisoning is the new runtime trust problem for autonomous agents: Security programmes that only supervise API traffic are missing the decision layer that now determines whether the call is benign or malicious. The operational boundary has moved to the agent’s context, which means identity governance has to include who may alter goals, roles, and constraints.

Access review logic does not fit within-session identity drift: Review cadences assume privileges persist long enough to be certified, but an agent can be redirected by changing its mission briefing without any new login event. That makes context integrity and behavioural verification more useful than retrospective attestation alone.

Role drift should be treated as a security signal, not a UX quirk: When an AI agent starts behaving outside its expected job function, the issue is not just anomalous output. It is evidence that the identity model attached to the agent no longer matches the runtime instructions controlling it, so governance needs to move upstream to instruction controls.

For practitioners

• Protect the mission briefing path Restrict who can write or modify agent goals, tools, roles, memory, and constraints, and treat that path as a privileged control surface.
• Baseline normal agent behaviour Define expected databases, tools, and action patterns for each agent so unexpected access to new systems becomes immediately visible.
• Detect runtime role drift Alert when an agent’s operating role changes from its approved function, especially when the new role expands data access or tool reach.
• Correlate API calls to intent Join API telemetry with the agent’s approved purpose so security teams can see whether valid calls are serving legitimate or poisoned objectives.
• Separate tool approval from tool use Keep a narrow approved tool set for each agent and block any context change that adds export, admin, or cross-domain actions without review.

Key takeaways

• MCP context poisoning shows that an autonomous AI agent can be redirected without breaking normal authentication or API validation.
• The attack changes the agent’s operating intent, so ordinary logs and gateways may record only valid-looking activity while the mission has been compromised.
• Practitioners need controls for instruction integrity, behavioural baselining, and role drift detection before agent actions reach production data or external destinations.

Key terms

• 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.
• Mission Briefing: The bundle of goals, tools, roles, memory, and constraints that directs an autonomous agent’s behaviour. For governance, it is the control surface that determines what the agent believes it may do at runtime, and therefore what must be protected from tampering.
• Role Drift: Role drift is the gradual mismatch between a defined role and the access it actually carries. It appears when exceptions, temporary grants, or outdated job mappings accumulate, causing automated provisioning to assign permissions that no longer reflect current business need.
• Runtime Intent Analysis: Runtime intent analysis is the practice of evaluating whether an API session’s sequence, timing, and identity context match expected behaviour. It goes beyond request inspection by correlating flow, session history, and entitlement scope to detect abuse that looks legitimate at the packet level.

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.