The way most agents are attacked is not what their input filters were trained to see. In ARGUS, the authors show that a prompt-injection payload can sit harmlessly in a tool output, a retrieved document, or a conversation turn until it meets the agent’s current state. Only then does it become an actionable instruction. Static filters, which inspect messages in isolation, miss this because the malicious signal lives in the combination, not the text.
Why do static filters miss prompt injection in agents?
Static filters look for suspicious strings, patterns, or embeddings in user input. That works when the attack is self-contained: a jailbreak pasted into a chat box carries its own context. In an agent, the same phrase can be benign in one runtime state and decisive in another. A retrieved chunk that says “ignore the previous instruction” is noise until the agent is about to call a tool it was told to avoid. A tool result containing a hidden directive only matters when the agent is choosing between actions.
ARGUS calls this context-aware prompt injection and frames it as a causal-support problem. The attacker crafts evidence that influences a specific action, and the action only succeeds because the evidence is present at decision time. Existing benchmarks largely miss this because they test context-insensitive tasks with generic payloads. The ARGUS team responds with AgentLure, a benchmark spanning four agentic domains, eight attack vectors, and six attack surfaces, built for context-dependent tasks.
The takeaway is architectural. If your defense only sees the assembled prompt, it sees what the model sees. The model cannot tell which token came from a trusted system instruction, an untrusted web fetch, or a user message rewritten by a malicious extension. Something else has to track that.
How does ARGUS defend against context-aware injection?
ARGUS is a causal-provenance auditor. Instead of asking “does this input look malicious?” it asks “what evidence supports this action, and is that evidence trustworthy?” It builds an influence-provenance graph over the agent’s runtime spans: user messages, retrieval results, tool outputs, and intermediate reasoning. Each candidate action is grounded in the spans that entail it, and the action is released only when benign evidence entails it and task invariants still hold.
This shifts the control point. Input filters try to stop bad data from entering the context window. Provenance auditing stops bad actions from leaving the planner. The model can still read the injected text; the auditor prevents the injection from becoming a decision. On AgentLure, ARGUS reduced attack success rate from 28.8% to 3.8% while preserving 87.5% clean utility.
The mechanism is not free. Labeling spans, building the graph, and checking entailment all add latency and engineering work. The value proposition is not “drop this in front of your LLM call.” It is “restructure your agent so every action is accountable to its sources.”
What is the real cost: detection accuracy or integration work?
The brief and the paper frame the tradeoff as integration cost, not detection accuracy. ARGUS improves the security-utility tradeoff on its own benchmark, but the harder problem is applying the same idea across every tool surface an agent touches.
Consider what counts as context in VS Code agents: tool outputs, file contents, explicit references, conversation history, custom instructions, and implicit editor state. The assembled prompt is all the model can see. That means the provenance boundary has to be drawn around each of those surfaces separately.
VS Code’s MCP server integration makes this concrete. Tools, resources, prompts, and apps are distinct context surfaces, each capable of running arbitrary code and each requiring its own trust decision. A single filter at the top of the prompt cannot know that a resource from one MCP server is high-trust while a prompt template from another is not. You need a policy per surface.
That is the integration cost the angle emphasizes. Every new tool, retriever, or instruction channel needs its own context policy, its own provenance labels, and its own entailment rules. This is runtime architecture, not prompt engineering.
How do jailbreak defenses like Context Filtering compare?
Context Filtering is a different kind of defense. It is an input-preprocessing method that claims to reduce jailbreak attack success rates by up to 92% while maintaining model performance. The distinction matters: jailbreak attacks try to elicit disallowed content from the model itself, usually through a single adversarial prompt. Context-aware prompt injection in an agent tries to make the agent take a disallowed action using evidence assembled at runtime.
Context Filtering is plug-and-play. ARGUS is a runtime auditor. You could imagine using both: Context Filtering to strip obvious jailbreak patterns from raw input, and ARGUS-style provenance to protect action selection from context-assembled attacks. But they are not substitutes, and the 92% figure should not be cited as evidence that ARGUS’s problem is solved.
What do the AgentLure numbers actually mean?
On AgentLure, ARGUS cut attack success from 28.8% to 3.8% and kept 87.5% of clean utility. The baseline is high because the benchmark is built for context-dependent attacks: without provenance, the agent is genuinely confused by evidence that supports the wrong action. The 3.8% residual suggests the defense is not perfect, which is consistent with the claim that this is a hard problem rather than a solved one.
The clean-utility number is the one to watch. A defense that blocks 96% of attacks but breaks half of legitimate tasks is unusable in production. The 87.5% figure is a decent starting point, though real-world utility depends on how tightly task invariants are defined and how much the agent’s job resembles the benchmark tasks.
Again, these are research-benchmark numbers from a paper that was updated to v2 on arXiv on 8 July 2026 [unverified]. They are not field data from deployed agents. Treat them as evidence that the approach is promising, not as a guarantee of real-world performance.
What should teams building agents do now?
First, stop assuming prompt injection can be sanitized away at the input boundary. If your agent uses tools, retrieval, or persistent instructions, the attack surface is the assembled context, not the latest user message. Input filtering is still useful for obvious cases, but it is insufficient.
Second, map your context surfaces and assign trust levels. For each source, ask what it would take for an attacker to control it and what actions it can influence. A web search result should not have the same provenance weight as a system prompt or a signed tool result.
Third, instrument action selection so you can trace which spans supported which action. You do not need a full ARGUS implementation to start. Logging the provenance of tool arguments, retrieval chunks, and reasoning traces is a prerequisite for any later enforcement.
Fourth, enforce per-tool policies. Some tools are read-only and low-risk; others execute code, send email, or mutate state. Each should have its own guardrails and its own rules about what evidence is sufficient to invoke it.
Finally, treat benchmarks as directional. ARGUS on AgentLure shows the security-utility tradeoff can move. Your agent’s tradeoff will depend on your tools, your invariants, and how well you can label your runtime spans. The work is not finding a better filter. It is building an architecture where every action knows where it came from.
Frequently Asked Questions
When is ARGUS overkill for a small agent?
If your agent has a single read-only tool and no retrieval, there are few context surfaces to disentangle, so a full provenance graph may cost more in latency and engineering than it saves. The defense becomes essential once tool outputs, retrieval chunks, custom instructions, or implicit editor state can jointly determine an action, as in VS Code agents.
What makes AgentLure harder than standard prompt-injection benchmarks?
AgentLure tasks are context-dependent: the correct action is only justified by specific runtime evidence, and attacks are crafted so the malicious instruction is causally supported by that evidence. Standard benchmarks often test isolated jailbreak strings on context-insensitive tasks, which misses the agentic combination problem.
What is the minimum viable first step toward ARGUS-style auditing?
Start by logging which context span, user message, tool output, or retrieval chunk supports each tool argument and action, then assign a trust tier per surface. You can defer entailment checks until you have enough coverage to see which actions lack clean support.
Why does ARGUS still leave a 3.8% attack success rate?
Residual attacks can succeed when the injected payload piggybacks on evidence that is correctly labeled as benign but is incomplete, or when task invariants are too weak to rule out the malicious action. That gap is a reminder that provenance auditing is only as strong as the invariants and span labels you feed it.
Will provenance auditing slow down real-time agents?
Yes. Building an influence-provenance graph, labeling spans, and checking entailment add compute and latency to each action decision. Teams running low-latency assistants will likely need async auditing, high-stakes human checkpoints, or looser invariants, each of which changes the security-utility tradeoff.
