Prompt injection is the new SQL injection for AI agents

At a glance

What this is: This interview argues that prompt injection is the AI-agent analogue of SQL injection, with natural-language input now able to steer tool use and data access.

Why it matters: IAM and security teams need to treat AI agents as governed identities because input trust, tool authorization and data access are now inseparable.

Context

Prompt injection is a control-plane problem for AI agents, not just a content-safety issue. When untrusted input can alter what an agent decides to do, the boundary between instructions and data stops behaving like a normal application security separation. That matters for AI agent identity because the agent may already hold access to sensitive information and external tools.

The article frames this as a shift from model-only safety to production trust and safety for systems that can read untrusted data, access personal information and call other tools. For identity programmes, the key issue is that authorisation, data exposure and runtime behaviour now need to be governed together rather than as separate controls.

Key questions

Q: What breaks when prompt injection reaches a tool-using AI agent?

A: What breaks is the assumption that the model's output is low impact. Once the agent can call tools, a malicious instruction can become a database query, a file write, an email, or a deployment action. Without policy checks and approval gates, the agent's legitimate permissions become the attacker's path to impact.

Q: Why do AI assistants with tool access increase prompt injection risk?

A: Tool access converts prompt injection from a wording issue into an execution issue. A malicious instruction can trigger API calls, file writes, or messages with attacker-chosen parameters. The risk rises sharply when permissions are broad, egress is open, and the assistant can act without task-scoped approval.

Q: How should security teams reduce prompt injection risk in AI agents?

A: Security teams should reduce prompt injection risk by constraining what enters the context window, limiting tool permissions, and separating untrusted retrieval content from privileged instructions. The practical goal is not perfect detection. It is to ensure that a successful injection cannot trigger wide data access, uncontrolled writes, or irreversible actions through a delegated identity.

Q: What is the difference between prompt injection and SQL injection from a defender's point of view?

A: SQL injection is prevented by a parser that enforces a hard boundary between query syntax and parameters. Prompt injection targets a language model that has no equivalent parser or privilege bit. The model’s instruction following is learned behavior, so the practical defense shifts from input separation to output containment, tool scoping, and execution policy at the application boundary.

Technical breakdown

Why prompt injection breaks instruction isolation

Prompt injection works because many LLM-based systems place user input, system instructions and retrieved context into a shared prompt window. The model does not have a hard security boundary that reliably separates trusted directives from attacker-controlled text. That means malicious content can masquerade as higher-priority instruction, especially when the application passes raw input into the agent's reasoning loop. The result is not code execution in the classic sense, but behavioural hijack: the model may reveal data, follow hidden instructions or trigger a tool call that the operator did not intend.

Practical implication: Treat prompt construction as a security boundary and minimise the amount of untrusted text that can influence agent decisions.

Why tool access turns model manipulation into data exposure

Once an AI agent can call tools, prompt injection becomes more than a chat issue. The model can be induced to query APIs, fetch documents, forward secrets or take actions on behalf of the attacker if the surrounding application does not strictly constrain tool authorization. This is why the article's threat surface includes the model, the data it can access and the tools it can invoke. In identity terms, the agent is acting as a non-human identity with delegated access, so the security question is whether that delegation is scoped to the task or effectively open-ended.

Practical implication: Bind each tool call to explicit authorization, narrow scopes and auditable task context rather than generic agent access.

Why there is no parameterized-query equivalent for natural language

SQL injection was mitigated by separating code from data through parameterized queries. Prompt injection lacks an equally strong primitive because natural language is the control channel itself, not a structured payload with reliable semantic boundaries. That makes 'sanitize the prompt' an incomplete answer. Defences have to move outward into architecture: constraint of tool permissions, stronger context partitioning, output validation and monitoring for instruction override patterns. The article's point is that the threat is structural, not just a bad prompt template.

Practical implication: Design around the absence of a clean language boundary by constraining what the agent can do even when the prompt is compromised.

Threat narrative

Attacker objective: The attacker wants to turn the agent's own delegated authority into unauthorized disclosure or action.

1. Entry begins when attacker-controlled text enters the agent through user input, retrieved content or another untrusted source that the model reads as part of the prompt.
2. Credential or authority abuse follows when the model treats malicious instructions as legitimate and uses its delegated access to query tools or surface sensitive information.
3. Impact occurs when the agent returns data, performs an unintended action or propagates the injected instruction into downstream workflows.

Breaches seen in the wild

• Gemini CLI prompt injection flaw 2025: Tracebit showed a poisoned README could make Gemini CLI run hidden commands and exfiltrate developer secrets; Google fixed it in 0.1.14.
• Gemini AI Breach — Google Calendar Prompt Injection: Gemini AI assistant prompt injection attack leaks sensitive Google Calendar data.

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

NHI Mgmt Group analysis

Prompt injection is an instruction-boundary failure, not a content-moderation edge case. The relevant governance problem is that the model cannot reliably distinguish data from directives once both occupy the same runtime context. That means old application assumptions about trusted system prompts and untrusted user input no longer hold. Practitioners should treat this as a control-plane issue for AI agents, not a text-filtering problem.

Prompt injection turns delegated access into a non-human identity governance problem. The moment an agent can read personal information and call tools, it behaves like a governed NHI with runtime authority. The real question is not whether the model is 'safe' in the abstract, but whether the delegated authority is constrained to a task, a session and a narrowly defined action set. That is where NHI governance joins AI safety.

Natural language is now an attack surface, so tool authorization must assume malicious instruction content. The article shows that attack cost falls sharply when English can be used to steer the model. This creates a named concept worth tracking: instruction boundary collapse: the point at which a system can no longer separate user-controlled text from trusted control intent. Security teams need to evaluate AI agents against that failure mode, not against generic application security checklists.

Production AI agents require trust architecture, not just model hardening. Red-teaming and robustness testing matter, but the decisive issue is whether the surrounding system can prevent a compromised instruction stream from reaching sensitive tools or data. Enterprises that ship agents without task-scoped delegation, tight tool scopes and observable decision paths are accepting behaviour they cannot reliably govern. The implication is simple: the security model has to move from prompt quality to runtime authority.

The market is heading toward multi-model, multi-control environments, which increases governance complexity. As enterprises stop committing to a single model provider, identity and policy enforcement will have to work across routing logic, model choice and tool access. That expands the blast radius of a weak trust model because the control problem is no longer one model in one app, but many agents making choices across a shared enterprise estate. Practitioners should plan for cross-model governance now.

From our research library:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
• Read next: Zero Trust for AI Agents

What this signals

Instruction boundary collapse: AI agents expose a governance gap that looks like application security but behaves like delegated authority failure. Once untrusted text can steer tool use, the programme has to shift from prompt hygiene to runtime permission design.

The most consequential control is not whether the model understands the prompt, but whether the agent can do anything sensitive when the prompt is manipulated. That is why prompt injection should be handled as an identity and authorization problem across the agent, its tools and the data sources it can reach.

Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems. Organisations failing to scope AI access properly are 4.5x more likely to experience a security incident according to the 2026 Infrastructure Identity Survey, which is exactly the kind of gap prompt injection exploits.

For practitioners

• Constrain agent tool scopes Map every tool an AI agent can invoke and remove any access that is not required for a single task or session. Treat the agent as a delegated identity and require explicit scope boundaries for data reads, writes and side effects.
• Isolate untrusted prompt content Separate retrieved content, user input and system instructions so attacker-controlled text cannot freely override control intent. If the architecture cannot preserve that separation, reduce the agent's authority before exposing it to production data.
• Log tool decisions and prompt context Capture which input sources influenced each tool call, what data was accessed and what action was taken. This is the minimum audit trail needed to investigate prompt injection and explain unexpected agent behaviour.
• Limit personal data exposure to agents Classify whether an agent truly needs access to personal information before it is allowed into production. If the answer is no, remove that data path rather than trying to compensate with downstream filtering.

Key takeaways

• Prompt injection is dangerous because it converts untrusted text into effective control over an AI agent's behaviour and tool use.
• The article's core warning is that AI safety and access control can no longer be separated once agents touch sensitive data and external systems.
• Least-privilege delegation, strict tool scopes and observable agent decisions are the controls that change the risk profile.

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.
• Instruction Boundary Collapse: Instruction boundary collapse occurs when a system cannot reliably distinguish trusted operator direction from malicious content embedded in data it reads. For AI agents, this matters because emails, tickets, webpages, and metadata can all become carriers for commands if the agent processes them as instructions.
• Tool Authorization: Tool authorization is the control that decides which external actions an AI system may invoke, under what conditions, and with what constraints. For autonomous or semi-autonomous systems, it is a core identity control because unsafe tool access can turn a model response into a real-world action.
• Delegated Authority Model: A delegated authority model defines who is allowed to approve, review, or execute control-related decisions across the enterprise. It helps ensure requests reach the correct responsible party, especially when control owners, managers, and process owners sit in different teams, regions, or systems.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.