Context engineering exposes the real attack surface in agentic AI

At a glance

What this is: This is an analysis of how context engineering creates a broader attack surface for agentic AI, with the key finding that attackers can manipulate context to cause unsafe actions without breaching the underlying model.

Why it matters: It matters because IAM, AI governance, and security teams must treat retrieval, orchestration, and runtime policy as identity-adjacent control points, not just model-adjacent engineering details.

By the numbers:

• 67% of organisations still rely heavily on static credentials despite the risks they pose to agentic AI deployments, according to the 2026 Infrastructure Identity Survey.
• Only 13% of organisations feel extremely prepared for the reality of agentic AI despite the majority racing toward autonomous adoption, according to the 2026 Infrastructure Identity Survey.

Context

Context engineering is the discipline of curating the data and instructions an LLM or AI agent uses at runtime. In agentic AI systems, that context is often the real trust boundary because it shapes decisions, tool use, and output quality before the model ever reasons over a request.

Traditional application security assumes the most important boundary sits in code, infrastructure, or the model weights. This article argues that the higher-risk layer is the AI abstraction layer: prompts, retrieval pipelines, orchestration tools, and business logic. For IAM and governance teams, that shifts control thinking from static permissions to runtime context governance.

The article’s core warning is that malicious context can cause harmful behaviour even when the model is not exploited directly. That is especially relevant for systems that coordinate multiple agents or consume external content, where the attack surface expands with every trust relationship in the context pipeline.

Key questions

Q: How should security teams control context in agentic AI systems?

A: Security teams should treat context as a governed input, not an implementation detail. That means classifying sources, restricting who can write or retrieve from them, filtering sensitive content, and logging every context change that affects agent behavior. If an agent can only act safely when its inputs are trusted, context provenance becomes a core control.

Q: Why do poisoned prompts and retrieved documents create more risk than a bad model output?

A: Because the AI can still act on malicious context even when the model itself is functioning as designed. The risk is not only incorrect text, but unsafe decisions, data leakage, or destructive tool use driven by manipulated instructions that appear legitimate to the system.

Q: What are the signs that context governance is missing from an enterprise AI program?

A: Common signs include agents using inconsistent definitions, acting on outdated policy, bypassing semantic standards, or producing different answers from the same data. Another warning is when teams can explain meaning in the data layer but cannot tell which agents are actually using it. That gap usually means context was governed once, but not maintained in production.

Q: How should security teams prevent AI agents from acting on malicious input?

A: Security teams should treat every external prompt, email, ticket, or chat message as untrusted input until it is validated against policy. The strongest control is runtime enforcement at the point of tool invocation, where the system can block risky actions before they reach CRM, email, or other sensitive tools.

Technical breakdown

How context poisoning alters agentic AI behaviour

Context poisoning is the insertion of malicious or misleading information into the data an AI system retrieves and trusts. The model does not need to be compromised for this to work. If the system treats retrieved content, user-supplied input, or operational context as authoritative, the attacker can influence outputs, tool selection, and downstream actions. In agentic systems, that matters more because context is not just explanatory text. It becomes control material that can steer multi-step execution. The article’s examples show that even tiny amounts of poisoned content can reshape behaviour when the system lacks trust boundaries around retrieval.

Practical implication: treat retrieved context as a governed input surface and not as passive content.

Why business logic manipulation is the higher-order risk

Business logic manipulation is a form of context attack where the malicious input looks legitimate but is designed to exploit how the AI interprets goals, policies, or workflow state. This is different from a simple prompt injection because the attacker is targeting the operating logic of the application, not merely the wording of a prompt. In practice, this can drive data leakage, unsafe approvals, or destructive actions by aligning malicious instructions with the system’s own expected behaviour. The article’s point is that AI systems fail when they trust context too broadly, especially when business rules are embedded in retrieval and orchestration layers rather than enforced externally.

Practical implication: separate business rules from untrusted context and verify that policy enforcement happens outside the model.

How runtime guardrails change the trust model

Runtime guardrails are controls that evaluate context dynamically before the AI acts. They sit between raw input, retrieved material, and execution so that risk classification, access scope, and policy checks can change based on the task or source. This is the article’s practical answer to the shift-up problem: security has to follow the AI decision path, not just the code path. For agentic AI, that also means visibility into prompt histories, retrieval traces, and changes to context sources. Without those records, you cannot prove which context shaped a decision or whether the decision was based on trusted material.

Practical implication: log, version, and filter context at runtime so you can detect and constrain manipulation.

Threat narrative

Attacker objective: The attacker wants to bend the AI system’s own decision process so it takes unsafe actions or exposes data without needing a model exploit.

1. Entry occurs when the attacker injects malicious instructions into prompts, retrieved documents, or repository-linked context that the AI system trusts.
2. Escalation happens when the agent treats that poisoned context as valid operational guidance and uses it to shape tool use or workflow decisions.
3. Impact follows when the system leaks sensitive data, deletes resources, or produces unauthorized output based on manipulated business logic.

Breaches seen in the wild

• reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.
• DeepSeek database exposure 2025: An unauthenticated DeepSeek ClickHouse database exposed over a million log lines with plaintext chat history and API keys in 2025.

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 is now an identity boundary, not just an application input. Once an AI system uses external material to decide what to do, the trust problem moves from model quality to context governance. That makes retrieval pipelines, prompt histories, and orchestration layers part of the control plane for agentic behaviour. The practitioner implication is straightforward: if the context path is ungoverned, the identity path is incomplete.

Shift left is no longer enough when the AI abstraction layer can be attacked at runtime. The article is right to frame the real attack surface above the code. Static reviews of prompts or retrieval logic cannot fully address a system that can ingest new context continuously and act immediately on it. Practitioners need runtime controls that evaluate trust at the moment of execution, not only at build time.

Context poisoning creates an identity blast radius problem. The more agents, tools, and retrieval sources an application uses, the farther one poisoned input can travel through the decision chain. That is a governance issue, not just a technical bug. Teams should assume that any untrusted source linked to an agent can expand blast radius unless it is explicitly constrained.

Trusted context is the new least-privilege surface for agentic AI. The article shows that broad retrieval rights are functionally similar to broad permissions in IAM: they create unnecessary exposure even when the model itself is behaving as designed. The important design question is no longer whether the agent can access data, but whether it should be allowed to ingest that context for this task.

Runtime policy is what separates helpful automation from unsafe autonomy. Agentic systems that coordinate multiple steps need policy-aware orchestration to prevent manipulated context from becoming delegated action. That is where AI governance converges with NHI and IAM practice: access, trust, and execution must be evaluated together. The practitioner implication is to govern context as an active control surface, not a passive data feed.

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.
• Read next: Agentic AI Identity Maturity Model

What this signals

Context governance is becoming the practical control plane for agentic AI. Teams that already manage identities, permissions, and secrets should now map those disciplines onto prompts, retrieval sources, and orchestration paths. A system can be technically secure at the model layer and still be operationally exposed if context is not governed end to end.

Runtime filtering matters more as agentic adoption rises. 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. That expectation makes context trust, source classification, and task-scoped policy enforcement immediate governance requirements, not future architecture work.

For practitioners

• Map all context ingestion points Inventory every place the agent can pull instructions, documents, tickets, logs, or repository data into the decision path. Classify each source by trust level and business sensitivity before granting it to production workflows.
• Sanitize and classify retrieved context Strip unnecessary sensitive data, label trusted sources, and block low-confidence material from reaching high-impact tasks. Apply different handling rules for customer data, internal documentation, and externally contributed content.
• Control access to retrieval pipelines Restrict who and what can load context into the model, using role-based access controls and task-scoped permissions for tools, connectors, and knowledge stores.
• Log prompt and retrieval history Version context sources and retain retrieval traces so security teams can reconstruct what the agent saw before it acted. Use those records to detect anomalous context changes and injection attempts.
• Apply policy-aware orchestration Enforce runtime checks that filter context based on risk, task type, and source trust before the agent executes a tool call or returns an external-facing answer.

Key takeaways

• Context engineering expands the AI attack surface because attackers can manipulate what the system trusts without exploiting the model itself.
• The article shows that prompt injection, poisoned retrieval, and business logic abuse can lead to data leakage, destructive actions, or unsafe outputs.
• Practitioners need runtime context governance, source classification, and traceable retrieval histories to limit the blast radius of manipulated inputs.

Key terms

• Context Engineering: The practice of selecting, curating, and delivering the information an AI system uses at runtime. In agentic environments, context engineering is a security function because the quality, provenance, and trust level of the inputs directly shape the system’s actions and outputs.
• 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.
• Runtime Guardrail: A control applied while an AI agent is operating, not just during configuration or review. Guardrails can block dangerous tool calls, require approval for sensitive actions, or stop data leakage before it reaches systems or users.
• Business Logic Manipulation: A technique that uses plausible-looking instructions or data to push an AI system into unsafe or unauthorized behavior. The attack targets how the system interprets context and applies rules, rather than exploiting a traditional software vulnerability.

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.