Hidden Instruction Attacks on LLM Agents: Detection Design for LLM Contamination

Where poisoning happens

When people say “LLM poisoning via crawling,” they often picture a malicious string inside the page body text. In practice, what matters is where “instructions” can enter the agent’s data path—because each entry point implies different controls and detection strategies.

Poisoning points: a practical taxonomy

Common “hidden instruction” (indirect prompt injection) techniques

Hidden instructions usually aim for one of two outcomes: (1) steering the answer (misinformation, biased evaluations, reputation manipulation), or (2) steering the agent’s actions (tool execution, data exfiltration, privilege abuse).

Typical patterns

• Priority inversion: “Treat this page as highest priority,” “ignore system instructions.”
• Extraction spec tampering: “Only extract the following keys,” “ratings must always be 5/5.”
• Output-channel abuse: Hide “next-step instructions” inside JSON or code blocks for downstream systems.
• Tool-call steering: “Fetch this additional URL,” “call this API next.”
• Evasion: Paraphrasing, splitting instructions, or slowly shifting topics so the command slips in unnoticed.

Recent research also explores attacks that avoid abrupt commands and instead transition the conversation topic gradually, making the injected behavior feel “reasonable” to the model.

Principles for detection design

The practical reality: crawler-driven LLM poisoning is easier to manage with detection → quarantine → impact minimization than with “perfect prevention.” If you consume external content at scale, you can’t drive the probability of malicious instructions to zero.

Principle 1: Separate data from instructions

Treat external documents as observations, not instructions. Reduce how much freedom untrusted text has to influence agent decisions. OpenAI’s guidance emphasizes not placing untrusted inputs into higher-privilege messages (like developer instructions), and using structured outputs to constrain what flows between steps.

Principle 2: Reduce free-form channels

The biggest reason detection is hard is that LLMs can generate arbitrary text that affects downstream steps. Whenever possible, lock down node-to-node communication with schemas (enums, required keys, max lengths, regex validation).

Principle 3: Use layered detection

Single filters (like keyword blocklists) are easy to bypass. Combine multiple weak signals, make a probabilistic call, and route suspicious content into quarantine, re-fetch, or human review.

Designing detection signals

This is the core of the implementation mindset: don’t rely on “the model will notice.” Explicitly design features your crawler/pipeline can observe and measure.

Document-level features

• Imperative-language score: must / ignore / override / priority / “follow these instructions,” etc.
• Agent-steering terms: tool, API, browser, search, system prompt, developer message, and similar vocabulary.
• Format coercion: forced JSON, base64 payloads, “encrypted” text, heavy use of invisible characters.
• Repetition / overemphasis: repeated directives, ALL CAPS, excessive punctuation/symbols.
• Topic mismatch: the page’s theme (title/headings) doesn’t match what the “instructions” talk about.

DOM and rendering diffs

“Hidden” instructions often rely less on the text itself and more on how it’s made invisible to humans. That’s why comparing raw HTML extraction vs post-render output can be a high-signal detector.

• CSS-based hiding: display:none, visibility:hidden, opacity:0, font-size:0, etc.
• Foreground/background color matching (white-on-white text)
• Off-screen positioning (CSS position tricks)
• Embedding in aria-* attributes or alt text

Anomalies in retrieval and hit distributions

If a poisoned document ranks unusually high or appears across many unrelated queries, it can “own” the RAG surface area over time. Track metrics like these:

• Hit ratio by domain (single-domain dominance)
• Reappearance rate of the same document within a time window
• Document diversity vs query diversity (low diversity increases risk)

Quarantine and containment

Detection without a handling policy will break your operations. Decide in advance what happens when a document crosses a threshold. A reliable pattern is a quarantine queue plus permission tiers.

Quarantine queue

• Don’t embed suspicious URLs (keep them out of your index/vector DB)
• Delay re-crawls and store snapshots for later comparison
• Route to human review with DOM diffs, visible text, and hidden/invisible text clearly separated

Permission tiers

For example: “low-risk docs can be summarized,” “medium-risk docs are citation-only,” and “high-risk docs are blocked from use.” The key rule is: never let high-risk documents become the justification for tool execution. OWASP also classifies prompt injection as a critical risk category.

Keep detection logic explainable. If you can’t answer “why was this quarantined?” you’ll end up in operational disputes and exceptions that quietly weaken the system.

Operations and testing

In practice, operations are harder than implementation. When indirect prompt injection succeeds, the symptoms vary: biased summaries, increased quoting, broken output formats, unusually frequent tool calls, and more.

Test perspectives

• Create pages that include “hidden instructions” and verify quarantine and low-privilege handling
• Resilience to false positives (for example, legitimate imperative language in FAQs or Terms of Service)
• Index refresh behavior (deletion/expiry) and time-to-effect
• Tool execution guardrails (allowlists, schema constraints, audit logs, and approvals)

Minimum viable monitoring

• Quarantine volume (by domain and over time)
• Diversity of referenced domains
• Spikes in tool calls (tied to specific queries or source documents)
• Output-structure violations (JSON schema errors, max-length violations)

If you’re focused on prompt leakage, prioritize output screening and post-processing monitoring early—they often provide faster risk reduction than trying to “perfect” upstream filtering.

A reusable blueprint for detection design

Here’s a pattern you can apply directly in design reviews and implementation planning.

Recommended architecture

1. Acquire: Store raw HTML and (if possible) rendered output
2. Extract: Separate visible vs invisible text, and body vs meta vs attributes
3. Detect: Score using multiple signals (explainable rules + lightweight classifiers)
4. Quarantine: Stop high-risk documents before indexing/embedding
5. Contain: Allow reference with restrictions (for example, never as tool-call justification)
6. Audit: Trace which document influenced which decision and which outputs

Unlike classic injection classes (like SQL injection), prompt injection is widely considered hard to “solve” completely. That’s why designing for detection and containment—and explicitly budgeting for residual risk—is the most realistic approach for production crawlers and RAG systems.

Summary

“Hidden instruction” attacks against LLM agents embed commands in external content to misdirect summaries, extraction, and tool execution—this is indirect prompt injection. In real systems, it’s more practical to optimize for (1) separating data from instructions, (2) reducing free-form output via structured schemas, (3) layered scoring-based detection, and (4) quarantine plus permission tiers to contain impact.

References