Prompt Injection Is a Data Problem, Not a Model Problem

Published 25 September 2026. Every product claim and availability status below was checked against the standard bodies' and Microsoft's own documentation on 19 September 2026. Where sources disagree, I say so rather than pick one. This area changes monthly, so check the linked source before you design around any of it.

In Agentic AI Security Architecture I argued for deterministic security boundaries around probabilistic reasoning, and that the real problem with agents is authority: what an agent can do once its reasoning has been bent. This article applies that idea to the attack most teams still try to fix with better prompts.

Most prompt injection defences I review are aimed at the user. They filter what people type, and they write longer system prompts telling the model to ignore instructions. The attacks that matter in an enterprise do not come from the user. They arrive inside the content the system reads for the user.

The one idea that organizes the defence

Prompt injection is a data problem, not a model problem. Put the trust boundary on the data and on what the model can reach, not inside the model.

The model cannot be the boundary, because inside it there is no boundary to enforce. Everything that follows hangs off that point.

Direct and indirect injection are different problems

The OWASP Top 10 for LLM Applications, whose 2026 edition keeps prompt injection at LLM01, separates the two cases. Direct injection is input from "a user, or an attacker with the user's access path." Indirect injection arrives in content the model ingests from an external source, and OWASP adds the detail that matters: "The user did not supply or see those instructions." NIST's adversarial machine learning taxonomy, AI 100-2 E2025, also treats them separately, with indirect prompt injection in its own section beside a section on the security of agents.

The difference changes who you are defending against. With direct injection, the attacker is someone you have already authenticated. With indirect injection, the attacker is whoever can get text into a document, an inbox, a web page or a tool response that your system will later read, and the user who triggers the attack is also its victim.

Why model-level fixes are partial

This is not a pessimistic reading. It is what the people closest to the problem now say in writing.

The NCSC comparison is the useful one for a security team. SQL injection was fixed by parameterized queries, which give the database a hard separation between code and data. No such separation exists inside a language model, so there is no equivalent fix to wait for.

Model-level defences still help. Microsoft's own spotlighting research reported that marking untrusted input cut attack success from more than 50% to below 2% in its experiments. That is a large reduction in the odds. It is not a guarantee, and an attacker only needs one message that works.

Five layers, and what each can stop

The practical question is not "which filter do we buy" but "which layer still holds when the model has been fooled." The grouping below is my own construct, built from controls OWASP, Microsoft and the NCSC describe.

Ingest. Catch what you can before content is stored or indexed. Microsoft Defender for Office 365 Plan 2 now detects prompt injection in inbound email, including hidden and off-screen text and encoded segments, and classifies it as high-confidence phishing. Microsoft notes that a basic test injection from a known sender may not trigger it.

Context assembly. Label every piece of content with where it came from, and keep untrusted text marked and apart. OWASP's 2026 guidance calls for "separate, labeled channels for external content." Permission-trimmed retrieval also matters here: an agent that can read overshared files hands an attacker a wider target.

Model. Prompt Shields in Azure AI Content Safety detects user prompt attacks and document attacks, and both are generally available. Microsoft itself calls it "a probabilistic classifier-based approach."

Tool execution. This is where most of the risk sits. Meta's Agents Rule of Two, which OWASP now cites, says an agent should combine no more than two of three properties in one session: processing untrusted input, accessing sensitive data, and changing state or communicating externally. If it needs all three, a human approves. Separate the agent that reads from the agent that acts, and give each only the tools and permissions it needs.

Output. MSRC lists the exfiltration routes plainly: an image or markdown tag whose URL points at the attacker's server, a clickable link with the data in it, a direct tool call, and covert channels through tools. After a markdown image vulnerability, Microsoft says it moved to "deterministically block the security impact." Do the same in your own applications: do not render external images from model output, and allow links only to known domains.

What Microsoft gives you, as of September 2026

Two inconsistencies are worth knowing. Microsoft uses three names for the same attack class: "document attacks" in Content Safety, "indirect attacks" in Foundry guardrails, and "cross-prompt injection attacks (XPIA)" in Copilot and Foundry Agent Service pages. Search for all three when you review coverage. And spotlighting, which Microsoft's own research presents as a core defence, is not yet available for Foundry agents, the workload where indirect injection matters most.

OWASP's own site is not consistent on editions either. The 2026 resource page is dated 3 August, the announcement is dated 2 September, and the main Top 10 landing page still presents the 2025 list. Cite the 2026 edition: several entries were renamed or reordered, and Excessive Agency moved up to third.

For Microsoft 365 Copilot extensions, the same logic applies to actions. In choosing a Copilot extensibility path I noted that MCP tools marked read-only skip the confirmation prompt, which makes that flag a security control.

What I would actually do

This is my own guidance, not vendor documentation.

1. Inventory every source of text each AI system reads, and mark each as trusted or untrusted. Email, shared files, web content and third-party tool responses are untrusted by default.
2. Apply the Rule of Two to every agent in design review. Where an agent reads untrusted content, holds sensitive data and can act externally, add human approval or split it in two.
3. Make output egress deterministic. No external image rendering, links only to allow-listed domains, and data loss prevention on anything leaving the boundary.
4. Turn on the detection you already own: Prompt Shields with document attacks, Defender for Cloud AI threat protection, and Copilot's audit and Defender signals. Route alerts to the SOC.
5. Red-team through data, not the chat box. Plant instructions in a document, an email and a tool response, and test whether anything consequential happens.

The test of the design is simple. Assume the model will follow the attacker's instructions, then check what it can reach.

If you are putting agents or Copilot extensions in front of email, shared files or third-party tools, that is work Avalon does: trust-boundary reviews of AI data flows, Rule of Two assessments for agents, guardrail and Prompt Shields configuration in Foundry, and prompt injection testing that goes through the data path rather than the chat box. It sits at the centre of my enterprise AI and security practice, and the contact page is the best way to start a conversation.

Sources

All checked on 19 September 2026. Where sources disagree, the text names the disagreement.

Standards and guidance — OWASP Top 10 for LLM Applications 2026 (opens in a new tab) · OWASP 2026 announcement (opens in a new tab) · LLM01:2025 Prompt Injection (opens in a new tab) · NIST AI 100-2 E2025 (opens in a new tab) · NCSC: Prompt injection is not SQL injection (opens in a new tab)

Research and vendor statements — How Microsoft defends against indirect prompt injection attacks (MSRC) (opens in a new tab) · Spotlighting paper (Hines et al., 2024) (opens in a new tab) · Design patterns for securing LLM agents against prompt injections (opens in a new tab) · Meta: Agents Rule of Two (opens in a new tab) · OpenAI: Hardening Atlas against prompt injection (opens in a new tab)

Azure and Foundry — Prompt Shields (opens in a new tab) · Foundry guardrails overview (opens in a new tab) · Foundry Agent Service overview (opens in a new tab) · Defender for Cloud AI threat protection (opens in a new tab) · Alerts for AI services (opens in a new tab)

Microsoft 365 — Copilot prompt defense in depth (opens in a new tab) · Data, privacy and security for Microsoft Copilot (opens in a new tab) · Prompt injection protection in Defender for Office 365 (opens in a new tab)

---

Published 25 September 2026; sources checked on 19 September 2026. Preview features and guardrail coverage for agents change often, so check Microsoft Learn before you rely on any of them. The five-layer grouping, the trust-boundary placement and the recommendations are guidance I propose, not vendor documentation. No client, employer or engagement is named in this article, and any scenario described is an illustrative composite rather than a description of specific customer work.