TL;DR: Prompt injection lets attackers alter an LLM’s intended behaviour, exposing data, poisoning outputs, or steering connected systems, according to Lookout. The control problem is not model capability but trust boundaries around prompts, sources, identity, and logging.
At a glance
What this is: Prompt injection is a technique that manipulates LLM instructions so the model ignores intended guardrails and performs unauthorised actions.
Why it matters: It matters because organisations integrating LLMs into workflows must govern prompt sources, access, and logging with the same discipline they apply to other high-risk control planes.
Context
Prompt injection is a control-plane problem for LLMs: the model is asked to treat untrusted text as instruction, so the boundary between data and commands collapses. That matters most when an organisation connects chat interfaces to email, documents, internal repositories, or workflow tools, because a single malicious input can change how the system behaves.
The identity issue is not just who can log in to the LLM, but what the LLM is allowed to trust once a session starts. If an AI assistant can read from shared data sources, inherit connector permissions, or act on behalf of a user, prompt injection becomes an access-governance problem as much as an AI-safety problem. Prompt Injection Guide
Key questions
Q: How should security teams test enterprise LLMs for prompt injection risk?
A: Test the model inside the real application path, not in isolation. Include hidden instructions, malicious retrieved content, multi-turn escalation, and language variations, then measure whether the model reveals policy text, ignores constraints, or produces unsafe tool instructions. A model that passes simple prompts may still fail once context, memory, and retrieval are involved.
Q: Why do conversational AI systems create new identity and access risks?
A: Because they can combine data retrieval, decision-making, and execution in a single interaction. That collapses the gap between information access and business action, which traditional IAM and security tools were not built to manage. The result is higher exposure when the system can modify records or disclose sensitive guest data.
Q: What are the signs that an LLM may be exposed to prompt injection in production?
A: Warning signs include unexpected model instructions, suspicious responses that echo untrusted content, outputs that appear influenced by external sources beyond their intended scope, or model behaviour that changes after ingesting outside input. Teams should also treat any unusual privileged action requests, inconsistent user-facing responses, or repeated boundary violations as indicators that prompt injection controls need review.
Q: Should organisations prioritise data scoping or prompt filtering first?
A: Data scoping should come first because it reduces the blast radius even when prompt filtering misses a malicious instruction. Filters matter, but they do not fix over-privileged retrieval or unrestricted output paths. If the assistant cannot reach sensitive data, the attacker cannot exfiltrate as much when a bypass occurs.
Technical breakdown
Why prompt injection works in instruction-following models
LLMs are built to respond to natural-language instructions, which means they do not inherently distinguish trustworthy prompts from hostile ones. Prompt injection exploits that ambiguity by embedding instructions inside user input, retrieved content, emails, or web pages, then relying on the model to prioritise the attacker’s wording over the developer’s intent. Direct injection targets the chat interface itself. Indirect injection hides inside external content that the model later consumes. In both cases, the core weakness is instruction hierarchy without reliable trust classification.
Practical implication: Treat every prompt source as untrusted until policy and context controls classify it.
How prompt injection becomes a data exposure problem
A compromised prompt does not need to break encryption or exploit memory corruption to be damaging. If the model has access to sensitive data, the attacker can coerce it into surfacing protected records, disclosing internal instructions, or revealing how the system is configured. In practice, the risk expands when retrieval, connectors, or copilots inherit broad permissions from the user or application. That is why prompt injection often becomes an NHI governance issue: the model, connectors, and service accounts become the real attack surface.
Practical implication: Scope LLM-connected identities and retrieval permissions so the model cannot access more than the user should see.
Why mobile and BYOD access increase prompt-injection risk
Mobile use widens the trust boundary because the same LLM may be accessed from unmanaged devices, personal email, and consumer apps that security teams do not fully control. That creates an indirect path for malicious content to reach the model through everyday workflows, not just through the corporate network. The security concern is not the phone alone. It is the combination of external content, limited device visibility, and LLM access to enterprise data or actions. Once that path exists, traditional perimeter controls are no longer enough. See the AI Infrastructure Workload Identity Guide.
Practical implication: Apply device-aware access controls and endpoint telemetry before allowing mobile access to enterprise AI tools.
Threat narrative
Attacker objective: The attacker aims to make the LLM disclose protected information, corrupt its outputs, or manipulate integrated systems without needing traditional malware execution.
- Entry begins when a malicious prompt is inserted directly into the chat interface or indirectly through email, documents, or websites that the model later consumes.
- Credentialed access or trusted context is then abused when the LLM treats attacker-controlled text as instruction and follows it ahead of its original guardrails.
- Impact follows when the model exposes sensitive data, misdirects users, poisons downstream content, or triggers actions in connected systems.
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 really a trust-boundary failure, not just an AI-content flaw. The attack succeeds when organisations allow unverified text to compete with system instructions inside the same decision path. That makes prompt handling a governance issue across model prompts, retrieval sources, and connector trust. The control question is therefore whether the model can separate instruction from input before action is taken.
AI-connected identities must be governed as operational access paths. When a model inherits permissions from a user, service account, or connector, the security boundary shifts from the chat window to the underlying identity. AI infrastructure workload identity becomes central because prompt injection is only damaging when the model can read, retrieve, or act beyond the minimum necessary scope. Practitioners should treat LLM-connected service identities like privileged access paths, not convenience integrations.
Mobile AI access expands the attack surface faster than most governance models assume. The article correctly highlights that prompt injection now follows users onto BYOD and mobile workflows, where enterprise visibility is weaker and content sources are harder to trust. That changes the threat model from a single assistant prompt to an ecosystem of devices, mail clients, and browser surfaces. The practical conclusion is that LLM governance must include endpoint context, not just model policy.
Logging is necessary, but it is not a complete defence if the model can already act on poisoned input. Prompt logs help with detection and response, yet they do not stop the first malicious instruction from being processed. The stronger lesson is that input provenance, connector scope, and action approval gates matter more than after-the-fact review. Organisations should therefore design for prevention at ingestion, not reliance on forensic visibility after compromise.
From our research library:
- AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
- Read next: Agentic AI Security Guide
What this signals
Instruction trust gaps are becoming the defining weakness in enterprise LLM controls. As organisations wire models into email, documents, and workflow systems, the security problem shifts from model misuse to trust enforcement across content, identity, and action. The strongest programmes will govern what the model may ingest before they rely on what it may say.
Prompt injection and identity scope now need to be designed together. A model that can only answer from tightly bounded context and narrowly scoped connectors is far easier to govern than one embedded in broad enterprise permissions. That makes AI governance, IAM, and endpoint control part of the same operating model.
Mobile usage widens the attack path for generative AI. As AI assistants move onto personal devices, hidden instructions can arrive through everyday communications channels and reach enterprise systems through the same session. Security teams should expect this to push governance toward device-aware policy, not just model-side filtering.
For practitioners
- Harden prompt provenance controls Classify and filter direct and indirect prompt sources before they reach the model, especially email, document, and web inputs that can carry hidden instructions.
- Constrain LLM-connected identity scope Limit what the model can retrieve or trigger through connectors, service accounts, and delegated access so a successful injection cannot reach unnecessary data or actions.
- Add logging for prompts and model actions Record user prompts, retrieved context, and tool calls so suspicious instruction patterns can be investigated and correlated with downstream actions.
- Gate mobile AI access by device trust Use endpoint telemetry and device-aware policy before allowing mobile users to access enterprise AI tools or sensitive content.
Key takeaways
- Prompt injection turns untrusted text into an instruction channel that can override intended LLM behaviour.
- The real exposure comes when an LLM can retrieve sensitive data or trigger actions through broadly scoped identities and connectors.
- Mobile and BYOD access widen the trust boundary, so prompt governance has to include device context and endpoint visibility.
Related NHI Mgmt Group resources: Prompt Injection Guide · AI Infrastructure Workload Identity Guide · Agentic AI Security Guide · Enterprise AI Copilot Security Guide
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Prompt injection becomes damaging when a model can abuse delegated identity and privilege. |
| ASI09 — Human-Agent Trust Exploitation | The article centres on attackers exploiting trust in natural-language instructions. | |
| Recommendation — Constrain agent and connector privileges so injected instructions cannot trigger unauthorised actions. Validate all external content before allowing it to influence agent decisions or outputs. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | LLM connectors and service identities become the access path that prompt injection abuses. |
| Recommendation — Enforce strong authentication and scoped access on every LLM-connected identity and connector. | ||
| NIST AI RMF | GOVERN — AI Governance and Accountability | The article requires governance over model trust boundaries, logging, and accountability. |
| Recommendation — Define ownership for prompt controls, retrieval trust, and action approval across the AI lifecycle. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article’s core control question is who and what the model may access or act on. |
| Recommendation — Restrict LLM-connected permissions to the minimum data and actions required for each use case. | ||
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.
- LLM Connector: An LLM connector is the integration that lets a model reach external services such as email, documents, chat, or identity-linked data sources. Connectors expand utility, but they also expand the blast radius of prompt injection because the model can be induced to retrieve or expose information from connected systems.
- Trust Boundary: A trust boundary is the point where one system’s authority should stop and another system’s authority should begin. For internal automation, weak trust boundaries let monitoring, remediation, and execution share privileges that should have remained separate.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity controls to the systems and workflows that now depend on AI.
Published by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org