Prompt injection exposes the data layer gap in AI agent security

At a glance

What this is: Prompt injection is an attack that uses untrusted text to steer an AI assistant into following attacker-controlled instructions instead of its intended task.

Why it matters: It matters because AI assistants increasingly handle email, documents, web content, and internal tools, so identity, access, and data-loss controls must cover both the agent and the data it can move.

By the numbers:

• In November 2023, someone prompted a Chevrolet dealership’s chatbot, which ran on ChatGPT, to agree with anything a customer said and to treat its replies as binding.

👉 Read Orion's analysis of prompt injection and AI data exfiltration

Context

Prompt injection is an AI security problem that appears when an assistant treats untrusted text as if it were instructions. The core governance gap is that large language models do not naturally separate trusted policy from hostile content, so the security model has to live around the model, not only inside it.

For IAM, PAM, and NHI programmes, the issue is no longer just who can authenticate to a tool. It is what an AI agent can read, infer, and move once it has access to mail, files, browsers, and internal systems. That makes prompt injection a control problem at the boundary between identity, authorisation, and data handling.

Key questions

Q: How should security teams stop prompt injection from turning into tool misuse?

A: They should enforce authorization at the tool or resource boundary, not inside the model. Scope each tool to the minimum necessary permission, then deny any call that falls outside that scope. Prompt filtering still has value, but it cannot be the last line of defence because the model is exactly what the attacker is trying to influence.

Q: Why do macOS malware campaigns often become an identity and access problem?

A: Because many campaigns abuse session authority, user approval, or privileged execution to reach their objective. Once a malicious app inherits a trusted workflow, it can steal screenshots, open shells, or capture data without further authentication. That makes the real failure the grant of authority, not only the malware payload itself.

Q: What do organisations get wrong about prompt injection?

A: They often treat it as a purely content-filtering problem. In practice, prompt injection is an instruction-trust problem that becomes serious when the chatbot can act on behalf of the organisation. The fix is not just blocking bad text. It is constraining what the model can access, what it can call, and what it can change.

Q: What should teams do when an AI assistant can already access sensitive data?

A: Treat that assistant as a production identity with explicit scope, owners, and review cycles. Reduce its permissions, remove unnecessary tool access, and require policy checks for any action that could move sensitive data. If the assistant cannot be fully trusted, its ability to reach restricted information must be constrained.

Technical breakdown

Why large language models confuse instructions with content

A large language model processes text as a single stream, so system prompts, user requests, and content fetched from emails or web pages can all compete for attention. Unlike a traditional application, it does not inherently know which text is policy and which text is hostile input. That is why simple phrases like ignore previous instructions can work, and why indirect injection is so dangerous when the model is reading documents on behalf of a user. The weakness is structural, not just a bad prompt design.

Practical implication: separate trusted instructions from untrusted content wherever architecture allows, and do not assume prompt wording alone creates security.

Direct injection, indirect injection, and prompt leaking

Direct injection is explicit attacker input inside the chat. Indirect injection hides commands in content the model later reads, such as a PDF, email, or webpage. Jailbreaking pushes the model past safety boundaries, while prompt leaking tries to extract the hidden system prompt. These techniques often overlap in the same attack flow, because the attacker may first reveal the rules, then use them to steer the model, and finally push it toward an unsafe action or disclosure.

Practical implication: test for all four patterns in red-team exercises, not just obvious user-entered prompt abuse.

Why the real risk is data movement, not model misbehaviour

The enterprise impact is not that a chatbot says something rude or even incorrect. The real loss occurs when the model, acting as an agent, reads sensitive data and sends it to a destination the organisation never intended. Once email, files, or SaaS tools are connected, injection becomes an exfiltration path. That is why data loss prevention has to become context-aware, with policy that understands what is being moved, by whom or what, and whether the movement makes sense for the task.

Practical implication: instrument AI tools with data-layer controls that can block suspicious transfers before anything leaves the environment.

Threat narrative

Attacker objective: The attacker wants to turn a trusted AI assistant into a covert path for data exfiltration or unauthorized action.

1. Entry begins when the attacker places malicious instructions directly into a chat prompt or indirectly into content the AI assistant will later read, such as an email, document, or webpage.
2. Escalation happens when the model follows the hidden instruction, overriding its intended task and using its connected access to read internal data or invoke tools.
3. Impact occurs when the assistant moves sensitive data to an external destination or otherwise performs an action the organisation did not authorise.

NHI Mgmt Group analysis

Prompt injection is not a model bug, it is an authorisation failure. The attack works because the system cannot reliably distinguish policy from payload once both arrive as text. That means governance has to move from language control to action control, with explicit trust boundaries around what an AI assistant may read and move. Practitioners should treat prompt injection as a control-plane problem, not a content-filter problem.

Data-layer verdicts are the decisive control for AI assistants. If an AI agent can be tricked, the control that matters is the one deciding whether a transfer is legitimate before the transfer occurs. This aligns with the broader shift in security from detecting bad text to governing risky movement, especially where agents operate across email, browser, SaaS, and internal files. Practitioners should build for pre-exfiltration verdicts, not post-event review.

AI assistant exposure creates NHI-like governance debt: the more tools an assistant can call, the more its access starts to resemble a non-human identity with meaningful operational privilege. That brings lifecycle questions into the AI stack: what it can access, who owns it, how far it can act, and when its permissions should be reduced. Practitioners should map AI assistants into identity governance, not leave them as ungoverned automation.

OWASP’s ranking is a useful signal, but the enterprise lesson is broader than LLM apps. Prompt injection demonstrates that any system which reads untrusted content and can act on it inherits a trust boundary problem. The field should expect more attacks that target the agent’s context rather than the model’s weights. Practitioners should align controls to the system’s real action surface, not only to the model itself.

What this signals

Prompt injection forces security teams to move from model-centric thinking to action-centric governance. The question is no longer whether the assistant can be persuaded, but whether sensitive data can be moved without a policy verdict. That shift should push programmes toward identity-scoped agent permissions, destination-aware controls, and tighter ownership of every connected AI workflow.

AI assistants now need lifecycle management, not just deployment approval. If an assistant can read mail, browse content, and call tools, it should be reviewed like any other high-risk non-human identity. That means setting ownership, reviewing access, and retiring capabilities when use cases change, rather than allowing broad access to persist by default.

The boundary between LLM security and data security is collapsing. Programmes that already invest in classification, DLP, and identity governance have a better starting point than teams waiting for a model-layer fix, because the durable control sits where data leaves, not where the prompt begins.

For practitioners

• Restrict what AI assistants can move Limit connected tools and apply least privilege to mail, file, browser, and SaaS access so a poisoned prompt reaches less data and fewer actions.
• Add pre-exfiltration policy checks Use data-layer controls that classify sensitive content and block suspicious transfers before an agent can send them to unknown destinations.
• Test indirect injection paths Red-team emails, documents, PDFs, and webpages that an assistant may ingest, because indirect prompt injection is the more scalable attack path.
• Treat AI assistants as governed identities Assign ownership, scope, and review cadence to assistants that can access internal systems, then reduce privileges when tasks do not require broad reach.

Key takeaways

• Prompt injection is an instruction-confusion problem that becomes a security incident when an AI assistant can act on sensitive data.
• The most credible evidence points to a control gap at the data layer, where AI agents can move information without a pre-exfiltration verdict.
• Enterprises should govern assistants like high-risk non-human identities, with scoped access, ownership, and movement controls.

Key terms

• Prompt Injection (Agentic): An attack where malicious instructions are embedded in content that an AI agent reads — causing the agent to execute unintended actions using its own legitimate credentials. A primary vector for agent goal hijacking and identity abuse.
• Indirect Prompt Injection: Indirect prompt injection is an attack where malicious instructions are hidden inside content that an AI system reads later. The model may treat that content as context rather than as hostile input, which can influence tool use, data access, or workflow actions if controls are weak.
• Prompt Leaking: Prompt leaking is the extraction of hidden instructions, examples, or system context that shapes an LLM’s behavior. Security teams care because leaked context can reveal guardrails, internal logic, or sensitive data paths that help an attacker refine later abuse or impersonation attempts.
• Data-Layer Control: Data-layer control is a security approach that decides whether sensitive information may move before it leaves the environment. In AI settings, it evaluates context, destination, and sensitivity so a tricked assistant cannot silently exfiltrate data just because the model was persuaded.

What's in the full article

Orion's full article covers the operational detail this post intentionally leaves for the source:

• A step-by-step explanation of how direct, indirect, jailbreaking, and prompt leaking attacks differ in practice
• Worked examples showing why model-layer defenses alone do not stop poisoned content from influencing assistant behaviour
• The DLP-style control concept the vendor says can judge data movement before it leaves the environment
• Illustrative scenarios across endpoint, browser, SaaS, email, and AI tools that show where the attack surface expands

👉 Orion's full article expands on the attack patterns, the EchoLeak example, and the data-layer control model.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners translate identity controls into operational guardrails for AI-driven systems and other non-human access paths.