Context engineering is the security perimeter for AI agents

At a glance

What this is: This analysis argues that AI agent context, not the model itself, is the primary security boundary, and that overloaded context windows weaken both accuracy and control.

Why it matters: IAM, NHI, and security teams need to treat prompts, tools, memory, and retrieval as authorization surfaces because agent behaviour changes with context, not just identity.

By the numbers:

• 85% of large enterprises are experimenting with AI agents, but only 5% have moved them into production.
• 97% of organizations with AI-related security incidents lacked proper AI access controls.

👉 Read Zenity's analysis of why context engineering is the security perimeter for AI agents

Context

AI agent context is the live instruction set the model uses to decide what to do next. The problem is that modern systems treat system prompts, retrieved documents, tool outputs, and memory as one shared decision space, which means security boundaries blur as context grows. For IAM teams, that turns context design into an access-control problem, not just a model-tuning exercise.

RSA 2026 made that gap visible across the market. Multiple vendors converged on the same conclusion: the context window is the control point for AI agent security, and that means governance has to cover what enters the window, what stays in it, and what the agent is allowed to do with it. For teams already managing NHI and autonomous workflows, this is the same lifecycle problem in a new runtime form.

Key questions

Q: How should security teams govern AI agent context windows?

A: Security teams should treat context windows as governed trust boundaries, not as passive text buffers. That means classifying every source that can enter context, limiting it to task-essential material, and monitoring how the agent behaves when those inputs change. Governance has to cover prompts, retrieval, memory, and tool calls together because each can alter the agent’s decisions.

Q: Why do AI agents make least privilege harder to enforce?

A: AI agents make least privilege harder because their effective authority depends on what context they can see and act on at runtime, not just on the permissions assigned to the underlying identity. If retrieval, memory, or tool access expands, the agent’s decision surface expands with it. That makes scope control a live runtime problem, not a one-time provisioning task.

Q: What breaks when prompt, retrieval, and memory are governed separately?

A: When prompt, retrieval, and memory are governed separately, no one owns the full decision chain. A secure prompt cannot compensate for a poisoned document source, and a clean retrieval pipeline cannot prevent unsafe tool use if memory carries bad instructions forward. The result is fragmented control that looks compliant in parts but fails at runtime.

Q: How can organisations tell whether AI agent controls are actually working?

A: The best signal is whether the agent’s behaviour stays stable when context changes. If the same agent becomes less accurate, more permissive, or more erratic as retrieved data grows or permissions drift, the controls are not working well enough. Good governance produces predictable behaviour under constrained context, not just clean scan results.

Technical breakdown

Token democracy and context window risk

Token democracy means the model does not inherently privilege a system instruction over retrieved text or user input. Every token enters the same attention mechanism, so a poisoned document or noisy prompt can compete directly with safety instructions. As the context window grows, the model has more material to process but less focused attention on any one instruction. That is why longer context can reduce both answer quality and policy adherence. Security teams should think of context as a mixed-trust execution surface, not a passive input buffer.

Practical implication: Treat every retrieval and prompt source as an access-controlled trust boundary, not as harmless text ingestion.

Why context engineering creates an authorization problem

Context engineering improves agent usefulness by adding relevant information, but each additional source expands the decision surface. Tool schemas, RAG sources, memory, and compaction rules all influence what the agent regards as authoritative. If security constraints sit in a prompt fragment that later gets compressed or diluted, the agent’s operating boundary changes mid-session. That is why context design behaves like authorization design: it determines what the agent can infer, reference, and act on. The architecture is not neutral.

Practical implication: Review context sources with the same discipline used for permissions, scope, and policy inheritance.

Continuous contextual security versus snapshot detection

Snapshot scans and single-turn prompt filters miss how AI agents behave over time. Real risk emerges across chains of prompts, tool calls, and changing exposure states, which means one clean scan says little about the next interaction. Continuous contextual security keeps state across sessions and correlates posture drift with runtime behaviour, so defenders can see whether a misconfiguration is merely present or actively exploitable. That shift matters because agent incidents are usually sequence problems, not isolated events.

Practical implication: Move from point-in-time checks to stateful monitoring across prompts, tools, memory, and retrieval pipelines.

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

Context engineering has become the new identity boundary for AI agents. The vendor convergence at RSA 2026 shows that the market is independently identifying context as the primary control point, not the model. That is a material shift for identity governance because the relevant question is no longer only who the agent is, but what instruction environment it is operating inside. Practitioners should treat context as a governed authorization surface, not as an implementation detail.

Token democracy is the named failure mode that makes AI agent context insecure by design. The model has no built-in privilege separation between system prompts, retrieved content, and user instructions, so trust is flattened at the token layer. That means malicious or simply noisy inputs can compete directly with policy. The implication is that security assumptions built on trusted instruction channels do not survive once all content enters the same attention pool.

Least privilege for context is the right framing, but it is not just a control addition. The broken premise is that richer context is always safer or more accurate. RSA 2026 evidence points the other way: more context can degrade both performance and safety. That means governance teams must stop equating completeness with control and instead ask which sources are actually needed for the task.

Continuous monitoring is now a prerequisite for AI agent governance. Static detection assumes the risk state is stable long enough to observe it, but agent behaviour changes across tool calls, retrieval updates, and memory persistence. The field should interpret this as a lifecycle problem for runtime context, not a one-time security event. Practitioners should align monitoring, review, and escalation around the agent session, not the scan window.

From our research:

• 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete compliance and investigation blind spot.
• For a broader control lens, OWASP NHI Top 10 helps teams map context, tool, and memory risk into a structured agentic-AI control model.

What this signals

Context sprawl will become a governance metric, not just a model-design concern. As enterprises add more retrieval, memory, and tool integrations, the real question is whether they can prove which inputs shaped a given agent decision. That is a programme-level requirement for NHI and agentic AI governance, and it aligns closely with the control logic in OWASP NHI Top 10.

With 24,008 unique secrets exposed in MCP configuration files in 2025 alone, per The State of Secrets Sprawl 2026, the context layer is already leaking into the identity layer. Security leaders should expect tool configuration, credential handling, and prompt design to be reviewed together, because they now form one operational risk surface.

Identity blast radius: when agent context determines what the system can see and do, the blast radius is no longer bounded by identity alone. Teams should prepare for policy enforcement that follows the session, the retrieval source, and the tool invocation chain, not just the principal.

For practitioners

• Map every context source as a governed access path Inventory system prompts, retrieval feeds, memory stores, tool outputs, and compaction rules as separate trust inputs. Assign ownership for each source and require review before any source can influence production agent behaviour.
• Constrain context to the minimum necessary tokens Remove unused retrieval sources, trim prompt scaffolding, and reduce memory persistence to the smallest set that still supports the task. Fewer tokens reduce both injection opportunities and instruction dilution.
• Correlate posture drift with runtime behaviour Track when agent permissions, connectors, or retrieval sources change and compare those changes with tool calls and output patterns. Use the correlation to decide whether the agent is simply misconfigured or under active exploitation.
• Separate control logic from agent reasoning paths Prefer platform-side observation and enforcement over in-runtime self-reporting. If the agent is responsible for judging its own context, a poisoned context can also shape the verdict.

Key takeaways

• AI agent risk is now about the context layer, because the model cannot reliably separate trusted instruction from untrusted input.
• The scale issue is already visible in enterprise adoption, where experimentation far outpaces production governance and control maturity.
• Security teams need runtime, stateful controls that govern prompts, retrieval, memory, and tools as one access path.

Key terms

• Context window: The context window is the live set of instructions, retrieved data, tool outputs, and memory that an AI model uses to decide what happens next. In security terms, it is a shared decision surface, so every added token can change behaviour, trust, and attack exposure.
• Token democracy: Token democracy is the property that a model does not inherently privilege system instructions over user content or retrieved documents. All tokens are processed through the same attention mechanism, which means a malicious or noisy input can compete with a safety rule on equal footing.
• Context poisoning: Context poisoning is the injection of misleading or malicious content into the material an AI agent relies on for decisions. It can arrive through retrieval, memory, tools, or documents, and it matters because the agent may treat the poisoned input as authoritative.
• Stateful security monitoring: Stateful security monitoring tracks how an AI agent’s risk changes across a session instead of judging each prompt in isolation. It preserves interaction history, compares posture drift with runtime behaviour, and helps defenders see whether the agent is merely misconfigured or actively being manipulated.

Deepen your knowledge

Context-layer security and AI agent governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is trying to secure agent behaviour without overextending the model boundary, this is the right starting point.

This post draws on content published by Zenity: Context Engineering Is Security Engineering. RSA 2026 Made the Case. Read the original.