MITRE ATLAS AML.T0093 Prompt Infiltration via Public-Facing Application: Detection, Mitigation and Response

Any web form, shared inbox, support portal or shared folder that accepts text from outsiders is now a way to plant instructions that an internal AI agent will read later. MITRE ATLAS tracks this as AML.T0093 Prompt Infiltration via Public-Facing Application, in both the Initial Access (AML.TA0004) and Persistence (AML.TA0006) tactics. The malicious prompt sits in the victim's own systems, sometimes for a long time, until a RAG index, an automation rule or a user's request puts it in front of a model. The OWASP Agentic Top 10 ASI01 Guide covers goal hijack once instructions reach the agent; this page covers the entry point: mapping the public inputs that feed AI, controlling content where it lands, finding planted prompts at rest, and cleaning them out. It is for application owners, AI platform teams and SOC analysts.

Key takeaways

• The attacker needs no account. A web-to-lead form, a calendar invite, an email or a support ticket is enough, as several 2025 and 2026 incidents show.
• The payload persists. Planted content stays in the CRM, mailbox or ticket queue and can affect many users and many AI tools, which is why ATLAS lists the technique under Persistence as well as Initial Access.
• Map inputs to models. You cannot defend what you have not traced: list every public-facing input and every AI system that later reads its data.
• Tag provenance at the door. Content that came from outside should carry that label all the way to the model, so the agent can restrict tools when it is in context.
• Clean-up is a search problem. Responding means finding every copy of the planted content across stores and indexes, not only blocking the sender.

How the technique works

ATLAS created AML.T0093 on 29 October 2025 and rates it as demonstrated. The description names three ways the planted prompt reaches a model: a data source indexed by a RAG system, a rule that triggers an AI agent, or a user who asks an LLM to work with the content. It also lists the inputs at risk: email, shared document systems, service desks and ticketing systems, and OCR-mediated paths where instructions are embedded in images, screenshots and invoices. Attackers may first run reconnaissance, or AML.T0084 Discover AI Agent Configuration, to find inputs that an agent watches.

AML.T0093 is the delivery step. What happens next is usually AML.T0051.001 Indirect prompt injection, and the impact often follows through AML.T0086 Exfiltration via AI Agent Tool Invocation or AML.T0053 AI Agent Tool Invocation. ATT&CK v20 also has T1698 Indirect Prompt Injection; see the MITRE ATT&CK T1698 Indirect Prompt Injection guide.

Public-facing inputs and how they reach AI

None of these is a flaw in the form or inbox itself. Accepting text from outsiders is the point of the application. The risk appears when that text later reaches a model that holds tools and permissions the outsider never had: the confused deputy pattern described in the NCSC blog "Prompt injection is not SQL injection" and in the Confused Deputy in AI Agents Guide.

Prevention: control content where it lands

The steps below are NHI Mgmt Group recommendations, drawn from the ATLAS mitigations and our own practice.

1. Build the input-to-model map. For each AI agent, assistant and RAG index, list the data sources it reads and mark which accept content from unauthenticated or external parties. This is the first deliverable; everything else depends on it.
2. Tag provenance. Store a source attribute (external form, external email, internal user) with each record and carry it into the retrieval result or tool output. Agent frameworks can then apply ATLAS AML.M0030 Restrict AI Agent Tool Invocation on Untrusted Data when tagged content is in context.
3. Reduce what outsiders can submit. Cap free-text field lengths to what the business needs, strip hidden formatting and markup, and normalise invisible Unicode at the point of entry. ForcedLeak used a description field that accepted 42,000 characters. These steps do not stop injection, but they shrink the space for long hidden payloads.
4. Validate between components. ATLAS AML.M0033 Input and Output Validation for AI Agent Components recommends schema validation and sanitisation of inputs and outputs for tools and data sources. Apply it where external content enters an agent workflow, and to OCR output before it reaches the model.
5. Drop privileges for external content. The NCSC suggests that an LLM's privileges should fall to those of the least-trusted party whose content it is processing. An agent that triages public tickets should not also hold tools that read the customer database or send email without approval.
6. Close output channels. Restrict link and image rendering to approved domains and keep that allowlist current: ForcedLeak used an expired domain still on an allowlist. See the Agent Egress Control and Network Isolation Guide.
7. Require approval for consequential actions triggered while external content is in context (AML.M0029 Human In-the-Loop for AI Agent Actions).

Detection classifiers for injected prompts help, but the NCSC advises scepticism about products that claim to stop prompt injection, and NIST's CAISI found that adaptive red teaming raised attack success against tested agents from 11% to 81%. Treat filters as one layer, not the control.

Choosing controls by exposure

Small organisations using SaaS agents should start with the vendor's settings for trusted domains, action confirmation and which objects the agent may read; confirm the current options in the vendor's documentation. Large organisations building their own agents should add provenance tagging and a pattern such as plan-then-execute, in which the agent commits to its tool calls before reading untrusted data, from the paper "Design Patterns for Securing LLM Agents against Prompt Injections".

Detection and measurement

Metrics

• Map coverage: share of AI agents with a documented list of external inputs.
• Provenance coverage: share of external input paths whose content reaches the model with a source tag.
• Privileged exposure: number of agents that read external content and can send, post or execute without approval (target zero).
• At-rest findings: instruction-like payloads found per month in scanned stores, and median time to removal.

Responding to planted prompts

1. Find the carrier. From the agent log, identify the record, email, ticket or file whose content was in context when the agent misbehaved.
2. Search for siblings. Use distinctive strings from the payload to search every store the input feeds, including RAG indexes and caches. Planted content is often submitted more than once.
3. Quarantine, do not just delete. Preserve copies as evidence, then remove the content from live stores and re-index.
4. Assess what ran. List the tool calls and outbound requests made while the content was in context. Rotate any credential that may have been exposed and follow the Prompt Injection Incident Response Playbook.
5. Check persistence. Look for memory entries, saved instructions or new records the agent created as a result, as in the calendar case where the assistant wrote a new event.
6. Fix the path. Add provenance tags, tighten field limits or remove automatic triggering for the input that was abused.

Framework mapping

Common failure patterns

• Threat modelling the chat box only: teams test what a user types, not what an outsider can store for the agent to read later.
• Treating CRM and ticket data as internal: records created by public forms are external content, whatever system they live in.
• Stale output allowlists: trusted domains expire or are re-registered; ForcedLeak showed the cost.
• One agent for triage and action: the same agent reads public tickets and holds privileged tools.
• Blocking the sender only: the planted content stays in the store and fires for the next user.

Practitioner checklist

• Map every public-facing input to the AI agents and indexes that read it.
• Tag externally sourced content and carry the tag to the model context.
• Cap free-text lengths and strip hidden formatting at the point of entry.
• Restrict or require approval for tools while external content is in context.
• Separate agents that read public content from agents with privileged tools.
• Keep link and image domain allowlists short and reviewed.
• Scan stores fed by public inputs for instruction-like content.
• On an incident, search all stores for copies, quarantine, re-index and rotate exposed credentials.

Standards and references

• MITRE ATLAS: Prompt Infiltration via Public-Facing Application
• MITRE ATLAS: Restrict AI Agent Tool Invocation on Untrusted Data
• MITRE ATLAS: Living Off AI: Prompt Injection via Jira Service Management
• MITRE ATT&CK: Indirect Prompt Injection (T1698)
• NCSC: Prompt injection is not SQL injection (it may be worse)
• NIST CAISI: Technical Blog: Strengthening AI Agent Hijacking Evaluations
• OWASP: Top 10 for LLM Applications 2025
• arXiv: Design Patterns for Securing LLM Agents against Prompt Injections

Related NHI Mgmt Group resources: OWASP Agentic Top 10 ASI01 Guide · Customer Service AI Agents Security · AI Agents in the IT Service Desk · MITRE ATLAS Guide