Skip to main content
Agent Context Poisoning Is Now a CVE CategoryGeneral
5 min readFor Security Engineers

Agent Context Poisoning Is Now a CVE Category

The OpenSSF Tech Talk on March 17, 2026, at 1:00 PM ET marks a significant shift in classifying AI security vulnerabilities. Angela McNeal will discuss agent autonomy and context integrity as new security frontiers, addressing attack vectors that don't fit into OWASP Top 10 categories or NIST 800-53 Rev 5 controls.

Your current security frameworks weren't built for systems that make autonomous decisions based on context windows you can't fully audit.

What Changed

Traditional application security assumes you control the execution path. You validate inputs, sanitize outputs, enforce least privilege, and monitor for anomalies. Agentic AI systems break this model in three ways:

Autonomous decision-making creates new attack surfaces. When an AI agent can choose which tools to invoke, which APIs to call, or which data sources to query, you're no longer securing a deterministic application flow. You're securing a system that generates its own execution paths based on context it assembles from multiple sources.

Context integrity has no equivalent in legacy frameworks. Your WAF can't detect when an attacker has poisoned the context window that guides an agent's decision-making. ISO 27001's access control requirements don't address scenarios where the agent itself has legitimate access but has been manipulated through crafted inputs that persist in its context.

The attack vector is the prompt history. Not the network layer, not the database query, not the API endpoint. The Secure AI Framework Ecosystem (SAFE) and Model Context Protocol (MCP) exist because we need new methods for validating context chains and detecting manipulation in conversational state.

Key Findings

1. Your existing threat models don't account for context persistence attacks

Traditional injection attacks target a single request-response cycle. Context poisoning works across multiple interactions. An attacker seeds malicious instructions early in a conversation, then waits for the agent to act on that poisoned context in later interactions when the original source is no longer visible in the immediate prompt.

Your code review checklist includes input validation. Does it include context chain validation? Does it verify that instructions in turn 47 of a conversation haven't been manipulated by untrusted input from turn 3?

2. Agent autonomy creates privilege escalation paths you can't model with RBAC

When you grant an agent access to tools and APIs, you're not just granting permissions to a user. You're granting permissions to a system that interprets instructions and makes decisions about when and how to use those permissions.

Consider a customer service agent with access to refund APIs, customer data lookups, and email systems. Traditional RBAC says "this agent can call these APIs." But can you define a policy for "this agent should never issue a refund based on instructions that appeared in a context window populated by user input, unless those instructions match specific templates and have been validated through a secondary channel"?

That's not a permissions problem. That's a decision integrity problem.

3. Infrastructure security for AI requires new monitoring methods

Your SIEM collects API calls, database queries, authentication events, and network flows. What does it collect about agent reasoning chains? Can you reconstruct why an agent made a specific decision? Can you detect when an agent's behavior diverges from expected patterns based on context manipulation rather than code changes?

The SAFE-MCP framework addresses this gap by defining standards for context provenance and decision auditability. But implementing these standards requires instrumentation that most security teams haven't built yet.

What This Means for Your Team

If you're running AI agents in production, your security posture has gaps that traditional controls don't fill. You need to answer three questions:

Can you trace agent decisions back to their context sources? Not just logging API calls, but recording the full context chain that led to each decision, with markers indicating which parts came from trusted sources versus user input.

Can you detect context manipulation in real-time? This requires baseline models of normal agent behavior and anomaly detection tuned to context-level attacks, not just network-level or application-level attacks.

Can you enforce boundaries on agent autonomy? You need policy frameworks that constrain what agents can do based on context provenance, not just user identity or role.

Action Items by Priority

Priority 1: Inventory your agentic systems and their tool access

List every AI agent running in your environment, the tools and APIs each agent can access, and the types of decisions each agent makes autonomously. This is your attack surface map. You can't secure what you haven't enumerated.

For each agent, document: What data sources populate its context? Which of those sources accept user input? What's the longest context chain that can influence a decision?

Priority 2: Implement context provenance tracking

Before you can detect context poisoning, you need to know where context comes from. Instrument your agents to tag every piece of context with its source and trust level. This doesn't require SAFE-MCP compliance yet, but it builds the foundation.

Start with a simple schema: trusted system-generated context, validated user input, unvalidated user input, external API responses. Tag everything.

Priority 3: Define decision boundaries based on context trust

Write policies that restrict agent actions based on context provenance. For example: "Agents cannot execute financial transactions if any part of the triggering context came from unvalidated user input in the last 10 turns."

This is policy-as-code for AI autonomy. You're not blocking the agent from accessing tools. You're constraining when it can use those tools based on context integrity.

Priority 4: Build monitoring for agent behavior anomalies

Your existing security monitoring won't catch context manipulation. You need baselines for normal agent decision patterns and alerts for deviations. This is behavioral analytics, but at the reasoning level instead of the network level.

Start simple: Track the distribution of tools each agent uses and the typical context patterns that precede each tool invocation. Alert on outliers.

Priority 5: Evaluate SAFE-MCP for your architecture

The Model Context Protocol provides standards for how agents exchange context securely. The Secure AI Framework Ecosystem builds on MCP with security-specific extensions. Evaluate whether these frameworks fit your agent architecture and what implementation effort they require.

Don't wait for perfect standards. The OpenSSF Tech Talk on March 17, 2026, will cover practical implementation approaches, but you can start mapping your architecture to these frameworks now.

Your current security stack wasn't designed for systems that build their own execution paths. Start treating context integrity as a first-class security requirement.

Topics:General

You Might Also Like