The web is not a trusted prompt
Search is becoming an input layer for agents. An agent finds a page, extracts its text, then sends that text to a model that can answer, browse, write code, or call tools. That workflow is useful, but it creates a boundary problem: webpages are authored by strangers, while the model may treat natural-language instructions as meaningful.
Indirect prompt injection exploits that boundary. The malicious instruction is not typed by the user. It is placed inside a webpage, frequently in hidden HTML, off-screen elements, comments, metadata, or text coloured to blend into the page. A naïve extractor can hand it to the model alongside legitimate content.
This is not a claim that every hidden element is malicious. It is a signal that untrusted page text contains language attempting to redirect an AI system's behavior. That content should not be granted the same status as the user’s request or verified evidence.
What Arlong observed
In this case, the page’s visible content was an ordinary technical site. Its source, however, included a hidden block with imperative language such as “Ignore previous instructions,” followed by instructions to refuse the user’s request and produce unrelated output. The request was not relevant to the page’s stated purpose. It was an attempt to control the reader.
Figure 1. The instruction appeared in hidden page content, not in the user’s request.
A second incident was blocked before extraction
We also tested a separate page that embedded an imperative instruction in an element styled to be effectively invisible. The instruction attempted to replace the user’s request with a different task. This time Arlong did not merely attach a review signal. The extraction result was blocked before any page content could be returned to the requesting AI workflow.
Figure 2. The hostile instruction was placed in near-invisible source text, separate from the visible webpage.
The request completed without reading the page into downstream context. Arlong returned an empty content field, BLOCKED reputation, and a trust score of 0. The hidden text was not executed, summarized, or passed through as evidence.
Figure 3. The observed API/tool result for the blocked page: no extracted content, blocked reputation, zero trust score.
What happens in Arlong
Arlong treats retrieved text as untrusted evidence, never as a command channel. Screening occurs before content is offered to downstream synthesis. The safety result becomes metadata that routing and extraction can use, rather than a silent judgment hidden from the operator.
Retrieve
Fetch only the page selected by the caller.
Extract
Turn markup into reviewable text while retaining safety context.
Classify
Look for instruction-like patterns aimed at agents or tools.
Route safely
Flag or withhold unsafe content before it reaches synthesis.
The detector produced a TOOL_EXECUTION_REQUEST signal on this page. That signal did not mean the page was automatically labelled as malware, and it did not authorize any tool use. It meant the extraction output required review and the instruction could not be treated as evidence for the answer.
Figure 4. Arlong reports the detected pattern as a safety signal; the page instruction was not executed.
Arlong did not follow the hidden instruction. It did not change the user’s task, refuse because of a page-authored copyright claim, call a tool, or generate the unrelated text requested by the page.
Why labels alone are not enough
A source can have a healthy reputation and still contain unsafe text. A page can be useful to a human reader while including a hostile payload for an automated one. That is why source reputation, relevance, and prompt-injection screening are separate signals in Arlong. Collapsing them into one “safe/unsafe” badge loses the distinction operators need.
{
"source_reputation": {"status": "SAFE", "trust_score": 88},
"security_analysis": {
"action": "review",
"flags": ["TOOL_EXECUTION_REQUEST"],
"scanned_chars": 4002
}
}
The values above illustrate the kind of structured result available to an agent. Scores and flags vary by source and are not a guarantee that a page is harmless. They are a way to make the system’s safety decision inspectable and to ensure risky content is not casually promoted into model context.
What this does and does not solve
No detector can prove that a webpage is safe. Attackers can use new wording, images, documents, encoded strings, or legitimate-looking instructions. Defense therefore cannot be one regex or one model pass. It needs layered controls: explicit trust boundaries, constrained tool permissions, source-level screening, grounded synthesis, and audit-friendly metadata.
Arlong’s role is the web boundary. It reduces the chance that hostile web text becomes trusted model context, and it gives people and agent builders a visible signal when a source needs closer inspection. Applications should still apply their own authorization rules before executing actions.