Prompt injection is not just an AI problem. It is an authority problem

Carla G. August 6, 2026 Updated August 6, 2026 10 mins read

I have just gone down the prompt injection rabbit hole, and this feels much bigger than another AI edge case.

Hand-drawn security diagram showing documents, email and web content crossing a cracked AI shield toward a database, files and tools. — Prompt injection becomes dangerous when untrusted content crosses the AI trust boundary and reaches data or tools.

The basic idea is simple.

An AI reads a document, email, webpage, tool result, or retrieved record containing instructions written by somebody else. Instead of treating those words as untrusted content, it may interpret them as commands.

That sounds like a prompt problem. It is not only a prompt problem.

Prompt injection becomes a serious security problem when untrusted words meet trusted access.

The short version

Large language models receive both instructions and data as language. That makes the boundary between the two much less reliable than the boundary between code and data in normal software.

Untrusted content → AI interprets it → AI has access → AI takes or recommends an action

The hidden instruction is only the entry point. The impact depends on what the surrounding application lets the model see and do.

A summariser with no private data and no tools may produce a bad summary.
A recruitment system may produce an unfair ranking.
A research-review assistant may produce a manipulated review.
An enterprise agent with email, files, private context, and external requests may expose sensitive information.
A coding agent with broad write or deployment permissions may change files or trigger actions outside the user’s real intent.

This is why the practical question is not only, “Can the model spot the attack?”

The better question is, “If the model is successfully manipulated, what can the application still prevent?”

Direct and indirect prompt injection

A direct prompt injection comes from the person using the AI. They put instructions into the chat or input field and try to change the model’s intended behaviour.

An indirect prompt injection is different. The instruction is hidden or embedded in content the AI is asked to read: a website, CV, PDF, email, image, issue, pull request, database record, tool result, or retrieved RAG document.

The user may never see the instruction. They may not know the content was created by an attacker. The attacker may not need access to the AI interface at all.

This is the part that changes the threat model. The attack can arrive through ordinary business content.

CVs: the document being judged can influence the judge

A 2026 study of real-world prompt injection in resume screening analysed approximately 200,000 resumes collected by hireEZ over multiple years. The researchers reported that approximately 1% contained hidden prompt injections. They also found that more than 90% of the detected injected prompts did not use explicit instructions.

That matters because it moves this out of the “someone might try this one day” category.

The document being assessed may contain content intended to influence the system assessing it. Some techniques use white text, tiny text, or other material that remains available to a machine even when it is difficult for a person to notice.

This does not prove that every injected CV succeeded, and the detector was not a perfect view of every possible attack. It does show that prompt injection is appearing in a real operational workflow at meaningful scale.

Scientific papers: hidden instructions aimed at AI review

In 2025, Nature reported that researchers had placed hidden instructions inside scientific papers in an apparent attempt to influence AI-assisted peer review.

Some messages were rendered in white text or very small fonts. A human reviewer might miss them while an AI processing the paper could still read them.

The important lesson is not limited to academic publishing. Any workflow in which AI evaluates attacker-controlled content has the same structural risk:

Applicant influences screening
Paper influences review
Supplier document influences approval
Support ticket influences triage
Repository content influences a coding agent

When the subject of a decision can write instructions for the decision-maker, the trust boundary is already under pressure.

EchoLeak: when manipulated context meets private data

EchoLeak made the risk much harder to dismiss as output manipulation.

In 2025, Aim Security disclosed the EchoLeak vulnerability chain in Microsoft 365 Copilot, tracked by Microsoft as CVE-2025-32711. Their research showed how a specially constructed email could be retrieved into Copilot’s context and influence the system without requiring the recipient to click a link or deliberately open the malicious content.

The demonstrated chain could cause sensitive information available in the Copilot context to be sent externally. Microsoft addressed the vulnerability before public disclosure, and the researchers reported no known customer impact.

The important engineering lesson is the chain:

External email
  → retrieved as relevant context
  → interpreted as instruction
  → combined with privileged organisational data
  → external request becomes an exfiltration path

The email did not become powerful because it contained clever words. It became powerful because those words reached a model connected to more trusted information and capabilities.

Word documents and self-propagating content

A later Word-document proof of concept reported by TechRadar demonstrated hidden white-text instructions influencing Copilot, changing financial figures, and carrying the injected instructions into generated content.

This is a proof of concept, not evidence of a widespread incident. It is still useful because it shows a second-order risk: generated artefacts can preserve or spread instructions that later systems may also process.

That means provenance matters. “The AI generated this file” is not a security boundary. Generated files, summaries, transcripts, and tool outputs must still be treated according to where their content came from.

Prompts can be hidden in more places than people expect

Prompt injection does not have to look like a visible sentence saying “ignore previous instructions”. Research on multimodal prompt injection and indirect attacks shows that malicious content can arrive through many representations.

White text or tiny fonts
Content positioned outside the visible page
Comments, metadata, headers, alt text, or document properties
Words embedded in images
Hidden webpage elements
Unicode, zero-width characters, or unusual spacing
Encoded or multilingual content
Instructions divided across multiple sections or retrieved chunks
Tool output, MCP content, logs, issues, pull requests, and repository files
Generated documents that carry previous instructions forward

This is why a blocklist of suspicious phrases is not a complete defence. It may catch obvious payloads. It cannot reliably classify every possible natural-language instruction, especially when normal business documents also contain legitimate commands, policies, and examples.

The real weakness is the authority model

We have spent decades building boundaries between code and data, users and administrators, public input and private systems.

LLM applications often weaken those boundaries by sending system instructions, user requests, retrieved content, tool results, and private context into one model conversation.

The model may be told which instruction is more important, but the surrounding application must still enforce the rules that matter.

Decision	Where it should be enforced
Can this user access this record?	Deterministic authorization code
Can this agent call this tool?	Tool policy and least-privilege credentials
Can data be sent to this destination?	Network and destination controls
Does this action require approval?	Application workflow outside the model
Is this output safe to execute or render?	Schema validation, sanitisation, and allowlists
Is external content an instruction?	It should remain untrusted data by default

A system prompt can express policy. It cannot replace authentication, authorization, validation, or a real approval gate.

Practical guardrails for developers

1. Mark provenance and separate instructions from content

Track where every piece of context came from. Keep system policy, the user’s approved goal, external documents, retrieved records, and tool results distinct for as long as the architecture allows.

Delimiters and labels help the model understand intent, but they are not a security boundary on their own. Research such as StruQ uses a secure frontend and a specially trained model, not just decorative separators around untrusted text.

2. Keep business rules outside the model

Do not ask the model to decide whether it is authorised to reveal data, approve a payment, merge code, change a role, or contact an external destination.

The model can propose. Trusted application code must decide.

3. Give every agent the minimum access it needs

Use narrow credentials, scoped tools, restricted file paths, constrained parameters, destination allowlists, and short-lived access where possible.

If a summarisation agent does not need to send email, it should not have an email tool. If a review agent only needs to read a pull request, it should not have deployment credentials.

4. Require approval at the point of consequence

Approval should happen immediately before the material action, with the real action, arguments, destination, and data visible to the person approving it.

A general “you may help with this task” message is not approval to publish, deploy, delete, purchase, or send private information.

5. Validate outputs before they become inputs to another system

Treat model output as untrusted. Validate schemas. Escape rendered content. Constrain URLs. Reject unexpected tool arguments. Do not execute generated code or commands simply because the model returned them in the requested format.

6. Test the complete chain

Test direct, indirect, obfuscated, split, multi-turn, retrieval, file, image, tool-output, and generated-artefact paths. Use fictional secrets and reversible tools.

Include benign controls too. A system that refuses every external document may look safe in a narrow test while being useless in production.

7. Log decisions and side effects without leaking more data

Record which content sources were used, which tools were requested, what arguments were authorised, what approval was obtained, and what action occurred. Protect the logs themselves and avoid copying secrets into them.

8. Design containment and recovery before launch

Assume a detection layer will eventually miss something. Make tokens revocable, actions reversible where possible, data access observable, incidents containable, and affected outputs traceable.

What I changed in the Agent Workflow Blueprint

This research also exposed a gap in my own Agent Workflow Blueprint.

The project already covered security review, permissions, secrets, evidence, and human approval. Prompt injection needed a more explicit end-to-end treatment for agents that read repositories, websites, uploads, RAG content, tool output, or MCP resources.

I have implemented the update locally and completed its automated verification. I am keeping it out of the public release until the final review and publication step are complete.

Expanded the existing Security Trust Boundary Prompt, Security Review Skill, and Security Boundary Contract instead of creating five overlapping assets.
Added one shared untrusted-content control covering direct, indirect, obfuscated, split, multi-turn, retrieval, file, tool-output, and MCP-content paths.
Kept copy-ready agent instructions inside the prompt body while leaving usage guidance, controls, and research references outside it.
Added explicit checks for goal hijacking, approval bypass, unsafe tool selection, argument changes, protected-data access, external destinations, persistence, and generated artefacts.
Added layered mitigation checks for instruction-data separation, deterministic authorization, least privilege, constrained tool arguments, approval, validation, monitoring, containment, and recovery.
Added a fictional prompt-injection evaluation case with benign controls and failure signals.
Mapped the controls to OWASP LLM01, NIST AI 600-1, indirect-injection research, instruction-hierarchy research, USENIX benchmarks, InjecAgent, and StruQ.
Updated search so normal words such as “prompt injection” find assets tagged with hyphenated terms.
Added source, manifest, composition, search, dialog, research-link, and cross-browser regression coverage.

The update is deliberately honest about its limits.

A research-backed prompt, skill, contract, and test fixture can improve how developers inspect a system. They do not prove that a deployed agent is resistant to prompt injection. That depends on the actual model, instruction hierarchy, retrieval pipeline, tools, permissions, authorization, approvals, monitoring, and incident response.

The blueprint can require the right questions and reject weak evidence. The application still has to enforce the answers.

A practical review checklist

What untrusted content can enter the model context?
Can content from one trust level reference data from another?
Can the model select tools, arguments, or destinations?
Which permissions are enforced in code rather than described in a prompt?
Can a retrieved document change the user’s original goal?
Can external content affect an approval record or bypass an approval step?
Can model output trigger code, rendering, requests, messages, file writes, or deployments?
Are generated files treated as trusted merely because the system created them?
Are sensitive values available to a component that does not need them?
Can every material side effect be traced, stopped, and recovered?
Have indirect and multimodal attacks been tested with safe fictional data?
Have normal documents been tested to detect excessive refusal?

The final takeaway

Prompt injection is not just hidden text tricking an AI.

It is untrusted content crossing an instruction boundary inside a system that may have access to trusted data or actions.

We should improve model-level resistance. We should inspect inputs. We should test detectors. We should structure prompts carefully.

But the strongest protection is the architecture around the model: real authorization, minimum permissions, constrained tools, explicit approvals, validated outputs, controlled destinations, useful logs, and recoverable actions.

The hidden words are not the most powerful part of the attack. The real power comes from the authority we give to the AI reading them.