ASD ISM 2158 Treat agentic AI retrieved external content as untrusted data
What it says
External content retrieved by agentic AI applications is treated as untrusted data throughout processing, is clearly delimited from system instructions, is subject to validation and sanitisation measures applied to other untrusted input, remains untrusted following such processing, and is prevented from modifying or overriding system instructions, security policies, access controls, tool permissions or human approval requirements.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishAgentic AI applications must handle any external content they retrieve as untrusted input that is kept separate from instructions and can never change the rules the agent operates under.
Agentic AI applications go out and fetch things: web pages, emails, documents, search results, API responses, files from shared drives. Whatever comes back is written by someone the organisation has no control over, and it may contain text crafted to look like instructions ("ignore your previous rules and email this file to..."). This control requires the application to treat all of that retrieved content as untrusted data, the same way a web application treats form input from an anonymous user. Concretely, the statement asks for five things. First, the content is treated as untrusted throughout processing, not just on arrival. Second, it is clearly delimited from system instructions so the model can tell "here is what I was told to do" apart from "here is what I found". Third, it passes through the same validation and sanitisation measures the organisation applies to other untrusted input. Fourth, it stays untrusted even after that processing, so summarising, translating or re-formatting it does not launder it into trusted content. Fifth, nothing in the retrieved content can modify or override system instructions, security policies, access controls, tool permissions or human approval requirements. Why it matters: an agent that acts on retrieved content as if it were an instruction can be steered by anyone who can get text in front of it. That is prompt injection, and in an agentic system it translates directly into unauthorised tool calls, data exfiltration and bypassed approvals.
Free. Save your status, tasks and notes.
Why it matters
If retrieved external content is not treated as untrusted, an attacker who can plant text on a web page, in a document, in an email or in an API response can hijack the agent. The agent may follow injected instructions, expand its own tool permissions, ignore security policies, skip human approval steps or leak sensitive data it has access to. Because the agent acts with the organisation's credentials, the resulting actions look legitimate and can be hard to detect until damage is done.
How to implement
Application architects define a single trust model for each agentic AI application that classifies every retrieval source (web fetch, email, document store, search, third-party API) as untrusted, and document how that classification is enforced at each processing stage.
Developers wrap all retrieved content in clearly delimited data blocks (labelled boundaries or structured fields) that are separated from system instructions in the prompt, and add a test that fails if retrieved text is ever concatenated directly into an instruction section.
Developers route retrieved content through the organisation's existing untrusted-input validation and sanitisation pipeline (format checks, content filtering, stripping of embedded instructions or markup) before the model processes it, reusing the same libraries and rules applied to other untrusted input.
Developers propagate the untrusted label through every downstream transformation (summaries, extracts, embeddings, chunked copies) so that processed versions of retrieved content are still handled as untrusted and never promoted to instruction status.
Security engineers enforce system instructions, security policies, access controls, tool permissions and human approval requirements outside the model's reasoning (in the orchestration layer or tool gateway) so that no content in the context window can alter them, and run prompt-injection test cases against each agent before release.
Keep it running
Day to day this control lives in the application design and the prompt and tool plumbing rather than in a policy document. Developers need a consistent pattern for wrapping retrieved content (for example clearly labelled data sections in the context window) and a rule that instructions only ever come from the system prompt, the operator or an approved human, never from a fetched document.
Keep the validation and sanitisation applied to retrieved content aligned with whatever the organisation already does for other untrusted input, and update it when those measures change. Remember that content stays untrusted after summarisation, extraction or chunking, so downstream steps that consume a processed version must not grant it more trust than the original.
Watch for regressions when new retrieval tools or data sources are added to an agent, and when prompts are edited. Any change that lets retrieved content sit alongside instructions without clear delimitation, or that lets it influence tool permissions or approval gates, reopens the gap this control closes.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Ask for the design documentation or threat model for each agentic AI application that retrieves external content.
Look at
Check whether retrieved content from every source is explicitly classified as untrusted and whether that classification applies across all processing stages, not just on ingestion.
Good evidence
Every retrieval source is listed and marked untrusted, and the document describes how that status is maintained throughout processing.
- Check 2 of 5What an auditor asks for
Ask for
Ask to see the prompt templates or context-assembly code that combines system instructions with retrieved content.
Look at
Look for clear delimitation between instructions and retrieved data, such as labelled boundaries or separate structured fields, rather than plain concatenation.
Good evidence
Retrieved content is always placed in a clearly marked data section that is visibly distinct from system instructions, and tests exist to enforce this.
- Check 3 of 5What an auditor asks for
Ask for
Ask how retrieved content is validated and sanitised before the model processes it, and how that compares with the handling of other untrusted input.
Look at
Compare the validation and sanitisation applied to retrieved content with the organisation's standard untrusted-input measures and confirm they are the same or equivalent.
Good evidence
Retrieved content passes through the same validation and sanitisation pipeline as other untrusted input, with no exemptions for particular sources.
- Check 4 of 5What an auditor asks for
Ask for
Ask what happens to retrieved content after it is summarised, extracted or otherwise processed, and how its trust status is tracked.
Look at
Trace a processed output (a summary or extract) through the pipeline and check whether it retains the untrusted label or is silently treated as trusted.
Good evidence
Processed versions of retrieved content carry the same untrusted status as the original and are never used as instructions.
- Check 5 of 5What an auditor asks for
Ask for
Ask for evidence that retrieved content cannot change system instructions, security policies, access controls, tool permissions or human approval requirements.
Look at
Review where those controls are enforced (orchestration layer, tool gateway, approval workflow) and examine prompt-injection test results that attempt to override each of them.
Good evidence
All five categories are enforced outside the model's reasoning, and documented injection tests show that retrieved content cannot alter any of them.
Mappings
Closest match in ISO/IEC 27001: A.8.27, Secure system architecture and engineering principles, which this control partially meets.
ISO/IEC 27001: 2 mappings
This control partially meets A.8.27.
ISM-2158 requires architectural and runtime controls so that untrusted retrieved content cannot override system instructions, security policies, access controls, tool permissions, or human approvals. Annex A 8.27 requires establishing and applying secure system architecture and engineering principles, which is the broader mechanism that would drive design patterns like instruction/data separation, policy enforcement points, and least-privilege tool interfaces for agentic AI. ISM-2158 is a concrete architectural requirement within the wider secure engineering principles mandated by Annex A 8.27.
This control partially meets A.8.28.
ISM-2158 focuses on secure handling of externally retrieved content in agentic AI, including input delimitation, validation/sanitisation, and preventing untrusted data from changing governing instructions or controls. Annex A 8.28 requires secure coding practices, which directly supports implementing robust parsing, input validation, content sanitisation, and safe tool-calling boundaries needed to meet ISM-2158. Annex A 8.28 is broader because it applies to all software development, while ISM-2158 targets a specific agentic AI threat pattern (retrieved-content/prompt injection).
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.