How should security teams prevent AI models from acting on hidden instructions in prompts and documents?

Put a policy boundary between untrusted content and model execution. Inspect inputs for hidden instructions, reasoning-tag references, and tool directives before they reach the model, and require separate approval logic for any action that can change data, send messages, or invoke external tools.

Why This Matters for Security Teams

Hidden instructions in prompts and documents are a practical form of prompt injection. They matter because the model may treat untrusted text as if it were operational guidance, then follow it into tool use, data exposure, or workflow changes. The security issue is not just model quality. It is control failure across input handling, authorization, and action approval. NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it reinforces the need for boundary controls, input validation, and separation of duties around sensitive actions.

The common mistake is assuming the model will “understand” which text is authoritative. In reality, hidden instructions can be embedded in copied email content, uploaded files, web pages, tickets, or retrieval sources. If the application passes those materials straight into the model with the same trust level as system instructions, the model can be steered toward unsafe outputs or tool calls. Where agentic workflows are involved, this becomes an NHI governance issue as well, because the AI system may operate with standing authority that was never intended for the content it ingests. In practice, many security teams encounter this only after an automated response, message send, or data lookup has already occurred, rather than through intentional test coverage.

How It Works in Practice

Effective defense starts by separating content classes before inference. Untrusted user text, retrieved documents, and third-party content should be treated as data, not instructions. Security teams usually need a layered design that combines preprocessing, policy enforcement, and action gating. The goal is to prevent the model from inheriting authority from content it should merely read.

• Classify inputs by source, sensitivity, and trust level before they reach the model.
• Strip or neutralize instruction-like patterns in documents, chat logs, and retrieval snippets.
• Keep system prompts, tool schemas, and policy logic outside retrievable user content.
• Require separate approval for high-impact actions such as sending messages, changing records, or invoking external tools.
• Log prompt, retrieval, and tool activity so security teams can review why a model attempted a given action.

For controls and governance, the most useful pattern is to treat prompt handling as a security pipeline, not an NLP feature. That means input sanitisation, policy checks, and output validation all need their own control points. MITRE’s MITRE ATLAS is helpful for mapping adversarial AI tactics such as prompt injection, while OWASP’s OWASP Top 10 for LLM Applications provides practical issue categories for insecure output handling and tool misuse. When retrieval-augmented generation is used, the system should also rank sources by trust and require stronger checks for externally sourced text than for curated internal knowledge.

Operationally, teams should test whether the model can be induced to follow instructions hidden inside PDFs, tickets, wiki pages, or emails, and whether those instructions can trigger tool calls without an explicit policy decision. These controls tend to break down when retrieval sources are heterogeneous and high-volume because the application cannot reliably distinguish benign content from malicious instruction text.

Common Variations and Edge Cases

Tighter filtering often increases latency and review overhead, requiring organisations to balance safety against developer productivity and user experience. That tradeoff becomes sharper in workflows where the model must summarise large volumes of external content. Current guidance suggests there is no universal standard for how much instruction-like text should be removed versus preserved, so teams need context-specific policy rather than a single global rule.

Edge cases usually appear when hidden instructions are mixed with legitimate operational text. For example, a support ticket may contain a real customer request alongside malicious text intended to redirect the model. The same issue appears in legal, HR, and finance documents where the model must preserve meaning but ignore embedded directives. In those environments, best practice is evolving toward explicit content zoning, where quoted material, retrieved evidence, and executable instructions are handled differently.

Security teams should also watch for indirect prompt injection through agent tools. If a browsing, email, or document-reading tool returns untrusted content, the model may treat that content as if it were a policy update. This is especially risky when the system has access to secrets, NHI credentials, or workflow automation privileges. For broader AI governance, NIST’s NIST AI Risk Management Framework supports a risk-based approach to that separation, and the OWASP Agentic AI Top 10 is relevant where the model can independently act across tools and services.

Related resources from NHI Mgmt Group

• How should security teams prevent AI agents from acting on malicious input?
• How should security teams prevent sensitive data from leaking through AI prompts and copilots?
• How should security teams test AI agents after prompts, models, or tools change?
• How should security teams prevent AI agents from deleting shared files after reading email instructions?