Context Engineering Is Security Engineering. RSA 2026 Made the Case.

The Model Isn't the Problem Anymore

Cisco polled its major enterprise customers before RSA 2026 and found something astounding. 85% of large enterprises are experimenting with AI agents. Only 5% have moved them into production. That's not a technology gap. The models work. The tools exist. The 80-point spread between experimentation and production is a governance gap. It's also a context gap.

In controlled experiments across frontier AI models, researchers found that over half the time, adding more retrieved context made a previously correct answer to become incorrect. Not a more nuanced answer. A wrong one.

The noise from extra tokens overwhelmed the signal. The information-theoretic optimum for both quality and security sits far below maximum context capacity. Every enterprise stuffing more data into bigger context windows is making their agents less accurate and less secure at the same time.

I spent the week of RSAC watching vendor after vendor arrive at this same conclusion from different directions. Cisco shipped an MCP gateway that routes all agent tool traffic through policy enforcement and assigns fine-grained, time-bound permissions. Google expanded Model Armor to sanitize MCP tool calls and responses with floor settings that define minimum security filters across an entire project. Geordie AI, the Innovation Sandbox winner, built a remediation engine that feeds risk-aware context back to agents in real time. Microsoft launched Agent 365 as a control plane for observing and governing agents at scale.

None of these companies coordinated their announcements. They each solved for the same underlying problem: the context window is the actual security perimeter for AI agents. Not the model. Not the network boundary. The context.

That realization changes where security teams need to focus. It changes how we think about authorization. It exposes a gap that most enterprises haven't even named yet.

Why Context is the Attack Surface, Not the Model

Here's the argument I want security leaders and architects to pressure-test.

There's a property of how modern AI models work that most security teams don't know about. Researchers call it token democracy. It means the model has no built-in way to distinguish between a system instruction from a user message from a retrieved document. All of those enter the context window as tokens, and the model processes them all through the same machinery with equal weight. There's no architectural privilege that says, "This token is a safety rule; treat it differently." A poisoned document retrieved through RAG competes for the model's attention on equal footing with the system prompt that told the agent not to follow external instructions.

This matters enormously for security. It means every token in the context window is a potential instruction, and every source that feeds tokens into the window is a potential attack vector. The model can't tell the difference between the data it's supposed to read and the instructions it's supposed to follow. Once content enters the context window, it all looks the same.

It gets worse as context grows. Research across 18 different frontier models shows universal performance degradation as input length increases, even on simple tasks. The attention mechanism that makes these models work forces all tokens to compete for a fixed budget. The more tokens in the window, the less attention any single token receives.

Longer context doesn't mean the model has more to work with. It means safety instructions get diluted. Anthropic's own research showed that attack effectiveness follows a power law with context length: the more tokens you add, the easier it becomes to override safety training. No model tested showed a plateau. More capable models were more exposed because they follow instructions more faithfully, including malicious instructions.

This maps directly to something every security practitioner is already familiar with. The Principle of Least Privilege dictates giving a user the minimum access needed for the task, and nothing more. The same logic applies to context. Give the model the minimum set of tokens needed for the task, and nothing more. Fewer tokens means fewer injection vectors, higher attention on safety instructions, and less room for adversarial payloads to hide.

Context engineering optimizes for richness: more relevant context leads to better agent performance.

Security engineering optimizes for constraints: minimum necessary access and least privilege.

Every context engineering decision sits at the intersection of those competing objectives. The organizations that govern this tension will ship agents to production. Those who ignore it will stay stuck in the 85/5 gap.

The most overlooked issue? The same channels that make context engineering effective carry malicious payloads with identical ease.

• RAG retrieval pipelines that inject relevant knowledge also inject poisoned documents.
• Tool interfaces that provide rich functionality also provide an attack surface.
• Memory systems that maintain a useful state also maintain a poisoned state.
• Compaction algorithms that preserve important context also drop security constraints.

There is no way to build a rich context engineering pipeline that's immune to context poisoning. Explicit, continuous security controls are needed at every ingestion point.

OWASP recognized this when they added LLM08:2025 specifically for vector and embedding weaknesses. Research shows that five poisoned documents in a database of millions can manipulate AI responses 90% of the time.

IBM's 2025 Cost of Data Breach Report found that 97% of organizations with AI-related security incidents lacked proper AI access controls. The SecuritySandman research from June 2025 discovered more than 3,000 vector database instances exposed on the public internet with no authentication at all.

The context layer is where the risk lives. The context layer is where the risk lives. The industry is building needed controls there. It’s time for enterprises to take action: begin your context-layer security audit now and address this emerging risk head-on.

From Detection to Continuous, Contextual Security

Gartner introduced the Guardian Agent concept to describe AI agents whose job is to monitor and govern other AI agents. It's the right direction. The RSA convergence described above proves the industry recognizes that context is the control point.

Recognition is one thing. Operationalizing it is another. Detection alone watches agents whose context was never threat-modeled in the first place.

Snapshot posture scans capture a moment that's outdated by the time the report lands.

Stateless prompt analysis catches single-turn attacks and misses everything else.

These approaches treat agent risk as a series of isolated events. Agent risk doesn't work that way. It develops across configuration changes, runtime behavior, long-horizon tasks, and interactions between agents, users, and enterprise systems.

What Zenity calls continuous, contextual security is the operational answer to the context engineering gap the rest of the industry identified at RSA. The company launched this approach at the conference on March 23, and it's built on three capabilities that work together.

The stateful threat engine analyzes full interaction chains across users, agents, and sessions. Real attacks don't arrive in a single prompt.

They unfold through sequences of normal-looking interactions via multi-step prompt injection, gradual data exfiltration, and tool misuse across chained requests. Each step looks legitimate on its own. The intent only becomes visible when you hold the full sequence in view. The stateful engine maintains contextual history and evaluates how requests evolve over time, rather than treating each prompt in isolation. This means security teams can stop a harmful action before it executes, not discover it after the data is gone.

Real-time exposure visibility replaces periodic posture scans with event-driven ingestion.

When an agent configuration changes, a new connector appears, permissions shift, or an MCP server is added, the platform reflects the new exposure state within minutes. Security teams investigate using data that represents the current environment, not what existed at the time of the last scan. In large environments where agents are deployed and modified daily, this is the difference between investigating real risk and chasing ghosts.

The Issues Correlation Agent ties those layers together.

Zenity connects posture weaknesses, permission drift, runtime detections, and policy violations into unified risk objects that show where configuration exposure and live behavior intersect. A misconfigured agent with excessive tool access is one signal. That same agent executing suspicious multi-step interactions is another. The Issues capability surfaces the connection and tells security teams whether the misconfiguration is under active exploitation or represents theoretical risk. Instead of chasing 50 disconnected alerts, teams open one investigation with the full story already assembled.

Zenity also announced a partnership with ServiceNow at RSA, routing security signals natively into ServiceNow SecOps. For organizations already running their security operations through ServiceNow, this means agent security findings land in the same workflow as every other security event. No separate console. No context switching.

As Zenity CEO Ben Kliger put it: Agents don't execute in isolation. They reason, take action, and evolve. As they do, risk evolves with them across every interaction and trigger. The security model has to keep pace.

There's an architectural reason this works. The most common pattern for securing homegrown agents today is embedding security logic inside the agent runtime. Middleware guards, prompt shields, output filters.

The advantage is proximity.

The disadvantage is that you're asking the agent to honestly report on its own behavior, including behavior that might result from compromised context.

When a poisoned RAG pipeline feeds bad data to an agent, the agent doesn't know it's compromised. An observer inside that runtime doesn't know either.

Zenity made a deliberate choice to observe from the platform side, monitoring APIs, tool calls, and context pipelines from outside the agent runtime. The telemetry isn't filtered through the agent's own reasoning. The stateful threat engine, the real-time exposure visibility, and the Issues correlation all depend on that independence. It's what makes the detections trustworthy and the correlation meaningful.

The coverage spans Microsoft 365 Copilot, Copilot Studio, ChatGPT Enterprise, Salesforce Agentforce, Azure AI Foundry, Google Vertex AI, and ServiceNow. For homegrown agents built on custom infrastructure, Zenity's Evaluation Engine extends the same detection logic through a cloud-agnostic API, returning Allow or Deny decisions with full explainability for each micro-interaction.

This is what Guardian Agents require as a foundation: continuous visibility into context decisions, across what an agent can access, what data it retrieves, how its behavior changes over time, and where posture and runtime signals converge into actual risk.

Without that contextual continuity, a Guardian Agent is monitoring agents it doesn't understand.

What to Audit Immediately

Bessemer Venture Partners published their agent security thesis during RSA week and named three capabilities traditional security tools lack: agentic investigation, real-time nondeterministic detection, and context-aware enforcement. That framing is right.

The adoption gap between experimentation and production won't close by buying more tools. It closes when organizations start treating context engineering as a security discipline. That means someone has to own it. In most organizations today, nobody does. The AI team owns agent performance. The platform team owns infrastructure. The security team owns threat response. Context engineering sits in the seam between all three, and seams are where things break.

Gartner projects that 40% of enterprise applications will embed task-specific agents by the end of 2026, up from less than 5% in 2025. McKinsey's internal AI platform was compromised in a red team exercise when an autonomous agent gained broad system access in under two hours. The scale is coming. The governance isn't ready.

That tension plays out in every design decision your teams are making right now. When a developer writes a system prompt, they're defining what the agent can become. When they configure tool schemas and MCP access, they're defining what the agent can do. When they select RAG retrieval sources, they're defining what the agent treats as authoritative. When they set up persistent memory, they're defining what carries forward across sessions. When they configure context compaction rules, they're deciding what gets dropped when the window fills up. Every one of those is an authorization decision. In most organizations, none of them go through a security review.

Key AI Agent Audit Questions

For every AI agent in your environment, here are the key questions you should be asking yourself:

System prompt and behavioral constraints.

• Has security reviewed the agent's system prompt?
• Do you know what identity, constraints, and behavioral boundaries are defined there?
• Prompt leakage reveals the entire context engineering architecture to attackers (OWASP LLM07).
• If your system prompt were exposed tomorrow, what would an attacker learn?

Tool schemas and permission boundaries.

• What tools can the agent access? Through what protocols? With what permissions?
• Are those permissions time-bound and task-specific, or persistent and broad?

Excessive agency through tool access is one of the most common and least-governed attack surfaces for AI agents (OWASP LLM06).

RAG retrieval sources and trust levels.

• Where does the agent get its authoritative information?
• Who controls those sources?
• What's the chain of custody from data source to embedding to retrieval?

Vector poisoning is now a well-documented attack category (OWASP LLM08), and most organizations don't audit their RAG pipelines.

Memory persistence and poisoning exposure.

• Does the agent maintain memory across sessions?
• Who can influence what persists?

Memory poisoning can happen through normal interactions at runtime (OWASP LLM04). A user who discovers the persistence mechanism can plant instructions that activate in future sessions.

Context compaction rules and what gets dropped.

• When the context window fills up, what gets compressed or removed?

If security constraints live in the system prompt, and compaction drops them, then the agent's behavioral boundaries change mid-session. This is a real attack surface (OWASP LLM09) that almost nobody governs.

If the answer to any of these is "no" or "I don't know who would review that," you found the gap the 85/5 split is made of.

The convergence at RSA 2026 wasn't coordinated. That's what makes it credible. Cisco, Google, Geordie, Microsoft, and Zenity arrived at the same conclusion independently: the context layer is the security perimeter for AI agents. The organizations that govern it will move from the 85% experimenting to the 5% in production. The ones that don't will keep wondering why their agents never ship.

Context engineering is security engineering. The question for your organization is who owns it.