Attackers use Prompt Infiltration via Public-Facing Application by placing malicious instructions in public content that an application later feeds into an LLM. Examples include web pages, reviews, tickets, or documents. Defenders should treat external text as untrusted, isolate it from system instructions, sanitise inputs, and test for indirect prompt injection in integrated workflows.
How prompt infiltration works when the app ingests public content
Prompt infiltration succeeds when an application treats outside text as if it were safe context for an LLM. The attacker does not need direct model access; they only need a public surface the app will later fetch, index, or summarise. That makes the primary failure boundary the application’s trust decision, not the model itself.
The most common pattern is indirect prompt injection. A malicious instruction is embedded in content the system expects to be harmless, such as a review, support ticket, knowledge base article, web page, or uploaded document. If the workflow passes that text into the model without strong separation, the model may follow the attacker’s instruction instead of the operator’s intent.
This is why public-facing inputs need to be treated as hostile by default. The dangerous part is not just the presence of words that look like prompts, it is the application design that lets external text compete with system instructions, developer instructions, or policy constraints. OWASP Agentic AI Top 10 and MITRE ATLAS adversarial AI threat matrix both capture this class of prompt injection and tool-abuse behavior.
Where attackers place the malicious instructions
Attackers put the payload where the application is likely to trust it later. That can be a public web page that a crawler summarises, a product review that a support agent reads, a ticket comment that gets folded into a case summary, or a document that becomes retrieval input for a RAG workflow. The content may look ordinary to humans, but it is engineered to change downstream model behavior.
The reason this works is that many integrations blur the line between data and instruction. Search, retrieval, parsing, summarisation, and workflow automation often concatenate external text into a single prompt bundle. Once that happens, the model may treat the attacker’s language as higher-priority context unless the system explicitly labels, isolates, and filters it. This is also the point where browsing, crawling, and embedded third-party content become part of the attack surface, not just a content management issue. CISA cyber threat advisories are useful for tracking broader exploitation patterns and related abuse conditions.
In practice, the attacker is aiming for one of three outcomes: override the model’s instructions, trigger an unsafe action through a connected tool, or contaminate the answer so the system discloses or mishandles information. The exact payload varies, but the objective is the same, to convert untrusted public text into executable influence over the assistant workflow.
How defenders contain the blast radius
The defensive priority is to make external text non-authoritative. That means separating retrieved content from system and developer instructions, stripping or neutralising instruction-like language where appropriate, and ensuring the application never gives public text equal standing with privileged prompts. The app should also be designed so a model can quote or summarise untrusted content without being able to obey it as policy.
Testing matters as much as filtering. Teams should simulate indirect prompt injection against the full workflow, not just the chat interface, because the dangerous path is often in retrieval, summarisation, ticket enrichment, or browser-assisted tooling. Good testing checks whether malicious text can change routing, tool calls, output framing, or disclosure behavior when the text arrives through the production integration path.
Isolation is the other key control. If the model can only read public text and cannot directly act on privileged systems, the attacker’s options shrink sharply. If the model can also invoke tools, write records, send messages, or query internal systems, then the public-text injection becomes a control-plane problem as well as a content problem. For appsec teams, OWASP ASVS and the OWASP Web Security Testing Guide provide useful structure for verifying input handling and workflow abuse paths.
Risk and Threat Considerations
Prompt infiltration is risky because it turns routine public content into an attack delivery channel. The damage is often indirect at first, then operationally significant once the model starts acting on the injected instruction or exposing sensitive context through a downstream action.
Failure mechanism: The application merges untrusted external text with privileged prompts or tool-eligible context, allowing attacker-controlled instructions to compete with, override, or redirect the intended workflow.
Impact: The model may disclose sensitive information, produce manipulated outputs, invoke unsafe tools, or corrupt downstream decisions, especially where retrieval and automation are tightly coupled.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and MITRE ATT&CK address the attack and risk surface, while OWASP ASVS sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI01 — Agent Goal Hijack | Prompt infiltration tries to redirect an agent's task from malicious external text. |
| ASI02 — Tool Misuse | Injected prompts become dangerous when they trigger unsafe tool actions in workflows. | |
| ASI07 — Insecure Inter-Agent Communication | Public text can contaminate downstream agent handoffs and shared context channels. | |
| Recommendation — Bound agent task execution so external content cannot replace the intended goal. Restrict tool invocation to validated, policy-checked actions only. Authenticate and sanitize inter-agent messages before they are consumed. | ||
| MITRE ATT&CK | T1204 — User Execution | The attack relies on a system or user processing attacker-supplied content as actionable input. |
| Recommendation — Treat untrusted content as hostile input and prevent it from driving execution. | ||
| OWASP ASVS | V4 — API and Web Service | The workflow exposes web and service interfaces that ingest external text for model use. |
| Recommendation — Validate and constrain API inputs that feed LLM prompts or retrieval pipelines. | ||
Practitioner Guidance
What to verify: Check every place where public text enters an LLM workflow, including crawlers, summaries, ticketing flows, and document ingestion. The question is not whether the text “looks harmless”, but whether the system treats it as instruction-bearing content.
Common mistake: Teams often secure the chat prompt but leave retrieval and orchestration loose. That creates a false sense of safety, because the compromise path usually comes through the integration layer, not the user-facing prompt box.
What good looks like: Public text remains evidence or reference material, never privileged instruction. The model can read it, summarise it, or quote it, but it cannot let that text rewrite system behavior or expand its own authority.
Practitioner takeaway: If an LLM workflow touches public content, the real control objective is instruction separation plus action containment. Once external text can influence tool use or privileged decisions, you are defending a workflow, not just a prompt.