MCPs increase risk because they pass structured context across system boundaries, and agentic systems may obey that context without enough human review. If attacker-controlled content can influence rules, prompts, or downstream actions, the model may execute harmful instructions as if they were legitimate. The danger is not only malicious code, but trusted context being misused.
Why MCP Context Becomes a Security Boundary
MCP increases risk because it turns context into an active input to automation rather than a passive reference for a human reviewer. When an agent can read instructions, tools, data, and policy hints from a shared context channel, the security question shifts from “is the data correct?” to “can this data safely drive action?” That matters because context often crosses trust boundaries that were never designed for executable influence.
In practical terms, the problem is not only prompt injection or malicious code. It is also over-trust in upstream context, where a seemingly ordinary document, ticket, or message can shape what the agent retrieves, approves, or sends onward. For agentic systems, that makes context handling a control point as important as authentication or authorization. Current guidance suggests treating any context source that can alter tool use, permissions, or workflow state as security-relevant input.
In practice, many security teams discover the boundary problem only after an agent has already acted on contaminated context rather than through deliberate testing of the context path.
How It Works in Practice
An MCP-connected agent usually follows a chain: it receives context, interprets it, chooses tools, and then executes actions with some level of delegated authority. The risk grows when that chain has no strong separation between informational context and actionable control data. If the same context bundle contains instructions, retrieval results, user content, and policy metadata, the agent may treat them as equally trustworthy unless explicit guardrails are enforced.
This is why static, role-only access control often breaks down for autonomous systems. Roles can say what a human account may do, but they do not reliably answer whether a particular action is safe in the current situation. Agentic workflows need context-aware decisions such as whether the request came from a trusted channel, whether the retrieved content was tampered with, and whether the intended action matches the current task scope. A strong pattern is to pair short-lived credentials with narrowly scoped tool permissions so the agent can complete one bounded task without carrying broad standing access.
One relevant signal is that only 52% of companies can track and audit the data their AI agents access, leaving 48% with a blind spot for compliance and breach investigation, according to SailPoint’s AI Agents: The New Attack Surface report. That gap matters because if the organisation cannot reconstruct what context the agent used, it also cannot explain why the agent took a particular action.
Best practice is evolving toward real-time policy evaluation, ephemeral secrets, tool-level allowlisting, and separate handling for untrusted context versus trusted control signals. For deeper background on agent-specific risk patterns, see the OWASP Agentic AI Top 10 and NHIMG’s OWASP Agentic Applications Top 10.
These controls tend to break down when agents can chain several tools together across loosely governed systems, because a single contaminated context item can be amplified into multiple downstream actions.
Where the Real Exposure Comes From
Tighter context controls often increase workflow friction, requiring organisations to balance automation speed against stronger verification and smaller trust zones.
The first exposure is context injection: hostile or malformed content becomes operational input and changes the agent’s behaviour. The second is privilege amplification: an agent with broad credentials can turn a small context mistake into a large action, such as exfiltration, deletion, or unauthorized disclosure. The third is audit failure: without clear provenance for each context item and each tool call, teams lose the ability to distinguish normal automation from abuse.
There is no universal standard for this yet, so the practical rule is to distinguish between context that informs a decision and context that authorizes one. If the same channel does both, the trust boundary is too weak. Organisations also need to be cautious about assuming that a model’s reasoning layer will filter malicious content on its own. Autonomous systems are especially vulnerable when they are asked to be helpful first and cautious second.
When the question is about agentic risk rather than generic identity governance, stronger specialist references are more useful than broad security summaries. The CSA MAESTRO agentic AI threat modeling framework is a useful external reference for mapping these control failures, and NHIMG’s Moltbook AI agent keys breach illustrates how agent access materialises into a broader exposure problem.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, CSA MAESTRO and MITRE ATT&CK address the attack and risk surface, while NIST AI RMF, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A2 — Prompt Injection | MCP context can be poisoned to steer agent actions. |
| A3 — Excessive Agency | Agents may act beyond intended scope when context drives execution. | |
| A6 — Sensitive Information Disclosure | Context channels can expose secrets or sensitive data to tools and outputs. | |
| Recommendation — Treat untrusted context as hostile input and block it from steering tool use. Constrain autonomous actions to the minimum task scope and approval path. Restrict sensitive context and prevent it from flowing into uncontrolled outputs. | ||
| CSA MAESTRO | GOV-01 — Agent Governance | MCP requires governance over agent context, authority, and accountability. |
| DEF-02 — Tool and Action Controls | The risk is unsafe tool invocation from trusted context. | |
| Recommendation — Define governance rules for what context may influence agent decisions. Gate tool execution with policy checks and scoped action approval. | ||
| NIST AI RMF | GOVERN — Govern, Map, Measure, and Manage | Agentic context risk needs mapped oversight and measurable controls. |
| Recommendation — Map context sources, measure misuse paths, and manage residual agent risk. | ||
| CIS Controls v8 | 6.3 — Access Control Management | Agents need narrowly scoped and reviewable access to limit context-driven abuse. |
| Recommendation — Limit agent permissions to the smallest access needed for each task. | ||
| NIST CSF 2.0 | PR.AC-1 — Identity and Access Management | Context-driven actions become risky when access is broader than the task. |
| Recommendation — Enforce least privilege so context cannot expand authorization on its own. | ||
Practitioner Guidance
What to prioritise: Separate untrusted context from privileged action paths first. If a context source can change tool selection, output destination, or access scope, treat that path as a security boundary rather than a convenience layer.
What to verify: Confirm that the agent cannot turn retrieved content into authority without an explicit policy check. Verify provenance, freshness, and task relevance for any input that can influence execution, and require short-lived credentials for high-impact actions.
Decision rule: If the agent can perform a harmful action before a human would reasonably review it, the control design is too permissive. Reduce standing access, narrow tool permissions, and add human approval for irreversible operations.
What practitioners underestimate: The failure is often cumulative. One mildly trusted context source may be safe alone, but several loosely trusted sources combined can produce a decisive and unintended action chain.
Practitioner takeaway: The goal is not to stop agents from using context, but to make sure no single context path can silently become both evidence and authority.
