Prompt injection exposes the identity gap in AI security controls

At a glance

What this is: This is Lakera’s analysis of prompt injection as an AI security threat that manipulates LLM instruction-following to leak data and alter outputs.

Why it matters: It matters because IAM and security teams have to govern runtime trust boundaries for AI systems, not only the content they receive or the prompts they block.

Context

Prompt injection is a runtime trust problem in AI systems: the model may treat hostile text as if it were operational instruction. That breaks the assumption that system prompts and user content remain cleanly separated, which is why classic filtering alone does not close the gap for AI security governance.

The article frames the issue across direct, indirect, and multilingual attacks, showing that adversaries can target instruction-following logic through pasted text, external content, or language-switching. For IAM and security teams, the relevant question is what an AI system is authorised to read, trust, and act on once it is connected to data sources and tools.

Key questions

Q: What breaks when prompt injection is not in place of a real trust boundary?

A: The model treats attacker-controlled text as if it were legitimate instruction, so hidden prompts, external content, or copied text can steer behaviour. That breaks the assumption that user input is safely distinct from system instruction. The practical result is data leakage, policy bypass, and misdirected actions that content filters alone cannot prevent.

Q: Why do prompt injection attacks create governance risk for AI agents?

A: Prompt injection creates governance risk because the model often sits in the control path between text input and tool execution. If attackers can change what the model treats as authoritative, they can influence access decisions, data exposure, or downstream actions without compromising a traditional account. That makes prompt provenance and instruction hierarchy part of AI identity governance.

Q: How do teams know whether prompt injection controls are actually working?

A: Look for end-to-end visibility across prompts, retrieved content, memory, tool calls, and outputs, plus evidence that blocked actions stay blocked under realistic test cases. If the system can only be evaluated with static prompts, the controls are probably too narrow. Behaviour drift under multi-turn workflows is the signal to watch.

Q: What should organisations do when AI systems can both read content and invoke tools?

A: They should separate those permissions and require an explicit policy decision before any action occurs. Read access, reasoning access, and execution access are different governance problems. If those boundaries are collapsed, a prompt injection can move from misleading output to privileged workflow manipulation in one step.

Technical breakdown

Why prompt injection bypasses instruction boundaries

Prompt injection works because an LLM does not natively enforce a hard security boundary between trusted system instructions and untrusted input. Instead, it processes both as text to be weighed in context, which lets an attacker smuggle higher-priority directives into the conversation. Direct injection places the malicious instruction in the user prompt itself. Indirect injection hides the instruction inside external content that the model later consumes, such as documents, webpages, or copied text. The security failure is not syntax, it is trust classification at runtime.

Practical implication: Treat prompt content as untrusted input and govern which sources the AI may consume before the model ever sees them.

Why multilingual prompt attacks matter for AI security controls

Multilingual attacks exploit the fact that guardrails are often tuned more strongly for English than for mixed or non-English phrasing. Attackers use translation tricks, code-switching, obfuscation, or language-specific phrasing to route around static filters while preserving the same malicious intent. This matters because the control weakness sits in detection and policy enforcement, not in model capability alone. If the policy engine does not normalise meaning across languages, the model can still be manipulated even when the prompt looks harmless to a human reviewer.

Practical implication: Validate AI safety controls against multilingual input patterns, not only against the primary language used by your team.

How prompt injection becomes an identity and authorisation problem

Once an AI system can retrieve data, invoke tools, or act across workflows, prompt injection stops being only a content problem and becomes an identity problem. The model’s instruction path can redirect privileged actions, expose sensitive context, or misuse delegated access that was never intended for that request. In that sense, the vulnerable unit is not the prompt alone but the runtime authority granted to the AI system. That is why content moderation cannot substitute for scoped execution, source restriction, and action-level governance.

Practical implication: Define separate read, reason, and act permissions for AI systems so a compromised prompt cannot automatically become a privileged action.

Threat narrative

Attacker objective: The attacker wants to hijack the AI system’s instruction hierarchy so it reveals sensitive context, bypasses safeguards, or performs unintended actions.

1. Entry occurs when an attacker supplies a crafted prompt directly or embeds malicious instructions inside external content that the model will later process.
2. Credential or context abuse follows when the model treats attacker-controlled text as trusted instruction and exposes hidden prompts, sensitive data, or internal context.
3. Escalation happens when the manipulated model changes outputs, bypasses safeguards, or invokes tools and downstream actions that exceed the original request.
4. Impact is achieved when the AI system leaks information, produces harmful content, or executes unintended workflow actions on behalf of the attacker.

Breaches seen in the wild

• EchoLeak (Microsoft 365 Copilot) 2025: A crafted email could make Microsoft 365 Copilot leak data from its context with no click, a zero-click prompt injection fixed as CVE-2025-32711.
• ForcedLeak (Salesforce Agentforce) 2025: A critical Agentforce flaw let attackers steer an AI agent through a Web-to-Lead form to leak CRM data via an expired allowlisted domain.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Prompt injection is an identity control failure, not just a content moderation problem: the attack succeeds because the AI system is trusted to decide which text is instruction and which text is data. That is an authorisation failure inside the runtime, not a simple filtering miss. Security teams therefore have to treat prompt trust as part of identity governance for AI systems, not as a content safety add-on.

The biggest gap is trust boundary ambiguity: AI systems that read email, web pages, documents, and chat history are often allowed to blend untrusted and privileged context in a single reasoning loop. That design assumption breaks as soon as adversarial instructions arrive through any of those channels. The practical implication is that runtime trust needs to be narrowed before the model can generalise across sources.

AI systems now inherit the old IAM mistake of overbroad interpretation rights: if a model can see something, teams often assume it can safely use it. Prompt injection proves that read access is not benign when the reader can also generate actions or extract hidden state. Practitioners should separate visibility, inference, and execution as distinct governance decisions.

Multilingual prompt attacks expose a control-plane blind spot: guardrails tuned to one language create a false sense of coverage while attackers move the same payload across linguistic forms. That is a language-normalisation and policy-design problem, not just a detection problem. The implication is that AI security programmes must measure control effectiveness across input variants, not only expected user language.

Runtime governance must replace prompt-only thinking: the article makes clear that secure AI design is about what the system is authorised to consume, retain, and act upon at runtime. The named concept here is the identity gap in AI security, meaning the mismatch between textual trust controls and actual execution authority. Practitioners should redesign governance around that gap, because prompt hygiene alone does not constrain AI behaviour.

What this signals

Identity gap in AI security: the failure is not that models can be prompted, but that many AI programmes still grant broad interpretive authority without a corresponding runtime governance model. Once an AI system can ingest external content and call tools, prompt safety has to be treated as a policy and authorisation problem, not a text-filtering exercise.

Enterprises should expect prompt injection to keep evolving because the core weakness is structural: AI systems mix untrusted input with operational context. That means security teams need controls for source trust, action gating, and multilingual validation before agentic use cases can scale safely.

For practitioners

• Constrain AI read scopes Limit which sources, chat histories, and external documents an AI system can ingest when the resulting context could influence downstream decisions or tool use.
• Separate read and act permissions Give the model visibility into only the data needed for the task, then gate any tool call, retrieval, or workflow action behind a distinct authorisation check.
• Test multilingual attack paths Run red-team scenarios in mixed-language, translated, and obfuscated prompt forms so defensive controls are evaluated against the full attack surface, not just English.
• Inventory indirect injection sources Map every place external content can enter the AI context, including copied text, scraped pages, tickets, and uploaded files, then classify each as trusted or untrusted.
• Review agent tool authority For AI systems that can invoke tools, validate that prompt influence cannot directly reach privileged actions without a separate policy decision at execution time.

Key takeaways

• Prompt injection turns ordinary text inputs into a security control bypass when AI systems cannot reliably separate instruction from untrusted content.
• Lakera’s analysis shows the risk across direct, indirect, multilingual, and agent-style attack paths, which means the attack surface is broader than simple prompt filtering.
• The practical response is to govern what AI systems may read, trust, and execute at runtime, with distinct controls for context ingestion and action authority.

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.
• Device Trust Boundary: The device trust boundary is the point where an endpoint is considered sufficiently verified to access systems, data, or services. It defines the security line between trusted and untrusted device states, based on posture, identity, integrity, and policy. In practice, it governs whether a device can authenticate, connect, or receive sensitive access.
• Backend Execution Authority: The ability for an authenticated user action to influence server-side commands or internal control flow. In identity terms, this matters because a narrow permission can become a much larger privilege when the platform translates input into execution rather than mere data handling.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.