Untrusted prompt input is any content added to an LLM context that cannot be assumed to meet enterprise security, policy, or data governance standards. It may come from users, uploaded files, retrieved documents, APIs, emails, or internal repositories. The key issue is not intent alone, but whether the content is validated and controlled.
Expanded Definition
Untrusted prompt input is any content introduced into an LLM context that cannot be assumed to satisfy enterprise security, policy, or data-governance requirements. The term covers user text, uploaded files, retrieved documents, API responses, emails, and internal content when provenance, validation, or filtering is uncertain.
The boundary matters because prompt input is not trusted just because it is internal, familiar, or machine-generated. A retrieved document can still carry malicious instructions, outdated policy, hidden markup, or data that should never influence model behaviour. In security practice, the issue is not whether the content is interesting or useful, but whether it has been vetted for the intended LLM workflow.
This is different from general “untrusted data” in software because the model may interpret instructions embedded inside the data itself. That makes prompt content a control-plane concern, not just a content-quality concern. OWASP’s OWASP Non-Human Identity Top 10 is useful here because it highlights how agentic systems can be steered by content and trust-boundary failures.
Examples and Use Cases
- A support chatbot ingests a customer email and treats embedded instructions as if they were part of the system workflow.
- A retrieval-augmented assistant pulls policy text from a shared repository, but the source document includes altered guidance or hidden prompt text.
- An agent processes API output from a partner system and assumes the returned content is safe to follow without validation.
- An employee uploads a spreadsheet or PDF, and the model extracts text that should be summarised, not executed as guidance.
- A workflow tool forwards internal tickets into an AI assistant, but the ticket text contains copied instructions, credentials, or policy abuse attempts.
In each case, the tradeoff is the same: more context can improve usefulness, but every additional source expands the chance that the model sees instructions, data, and authority signals it should not trust equally.
Security Implications
When untrusted prompt input is handled poorly, the model can follow attacker-supplied instructions, leak sensitive data, ignore policy, or produce actions that exceed the user’s authority. The failure often begins as a trust-boundary problem: the system merges authoritative instructions with content that should have been treated as inert data.
That can create prompt injection, data exfiltration, policy bypass, tool abuse, and downstream workflow corruption. A common operational symptom is surprising model behaviour after ingestion of a specific document, message, or retrieval result. The harm is rarely limited to a single answer because agents may reuse the same contaminated context across multiple steps.
NHIMG reports that 79% of organisations have experienced secrets leaks, with 77% of those incidents causing tangible damage. The same pattern applies when prompt context carries credentials, instructions, or other sensitive material that the system was never meant to trust.
Practitioners should watch for any LLM pathway where external content is promoted into context without strong provenance checks, content filtering, or role separation between instructions and data.
Domain and Governance Relevance
In NHI and agentic AI environments, untrusted prompt input is not just a model-safety issue. It becomes an identity and governance issue when the system can act through APIs, service accounts, or delegated credentials. If a model can read, decide, and then execute, contaminated prompt content can influence both judgment and action.
That changes governance in three ways. First, the source of content must be classified by trust level. Second, the model’s tool access must be limited so that untrusted input cannot directly drive privileged operations. Third, ownership must be clear for the pipelines that retrieve, transform, and inject content into the prompt.
For NHI-heavy workflows, the key question is whether prompt input can affect a machine identity’s effective authority. If it can, then prompt hygiene, retrieval controls, and execution boundaries are part of identity governance, not just application design.
Risk and Threat Considerations
Untrusted prompt input creates a material injection and trust-abuse risk because the model may not reliably distinguish instruction from data. The risk becomes more serious when the LLM is connected to tools, repositories, or delegated credentials that can turn a bad prompt into an actual action.
Failure mechanism: An attacker, malicious document, or compromised upstream system places adversarial instructions in content that is later injected into the model context. The model then follows that content, bypasses intended policy, or uses attached tools in ways the operator did not intend.
Impact: Sensitive data can be exposed, workflows can be altered, privileged actions can be triggered, and decision-making can be steered by untrusted content. In agentic systems, the blast radius can extend from a single response to repeatable misuse of connected identities and automated processes.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP Agentic AI Top 10 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Inventory and Ownership | Untrusted prompt input affects what content and authority enter agent workflows. |
| Recommendation — Inventory prompt ingestion paths and assign ownership for every source that can influence agent execution. | ||
| OWASP Agentic AI Top 10 | AGENT-01 — Prompt Injection and Instruction Hierarchy | This term maps directly to unsafe instruction handling inside agent contexts. |
| Recommendation — Enforce instruction hierarchy so retrieved or user content cannot override trusted system intent. | ||
| CIS Controls v8 | 3 — Data Protection | Prompt inputs can carry sensitive data that must be filtered before model use. |
| Recommendation — Classify and control inbound content before it enters AI workflows or shared context. | ||
| MITRE ATT&CK | T1056 — Input Capture | Prompt injection abuses captured input to influence system behaviour. |
| Recommendation — Treat adversarial prompt content as captured input and monitor for manipulation patterns. | ||
| NIST CSF 2.0 | PR.DS — Data Security | Untrusted prompt input is a data-security issue when content flows into governed AI systems. |
| Recommendation — Protect AI input data with validation, filtering, and provenance checks before processing. | ||
Practitioner Guidance
Common misunderstanding: “Internal” content is often treated as safe by default, but provenance and trust are not the same thing. A document stored in a repository, an email from a known sender, or an API payload from a partner can still be unsafe to inject into an LLM context without validation.
What to watch for: Any workflow that converts raw content into model instructions, especially when the same context also includes secrets, tool calls, or delegated access. The moment content can influence action, it should be treated as controlled input rather than passive text.
Practitioner takeaway: Separate trusted instructions from untrusted content, and treat every ingestion path into the prompt as a governed security boundary.
Related resources from NHI Mgmt Group
- Why do MCP-style workflows create more risk than a single prompt input?
- What breaks when legacy services accept untrusted input before authentication?
- What breaks when privileged AI agents can read untrusted input directly?
- How should security teams handle prompt injection across multiple agent input surfaces?
