Prompt injection is becoming one of the defining security problems of enterprise AI.
The comparison with SQL injection is useful—but it should not be taken literally.
Both problems expose a familiar security failure: untrusted input crosses a trust boundary and begins influencing behavior that was supposed to remain under trusted control.
With SQL injection, attacker-controlled data can alter the meaning of a database query.
With prompt injection, attacker-controlled content can alter the behavior of an AI model.
NIST defines prompt injection as an attack that exploits the combination of untrusted input with a prompt constructed by a higher-trust party. OWASP similarly identifies direct and indirect prompt injection as a major risk for LLM applications.
For enterprise AI, however, the deeper problem is not simply malicious text.
It is this:
Untrusted information can influence AI reasoning, and AI reasoning can increasingly lead to enterprise actions.
That changes the security architecture.
Why the SQL Injection Analogy Is Useful
A traditional SQL injection vulnerability often appears when trusted SQL structure and untrusted user-controlled data are combined incorrectly.
Conceptually:
Trusted query structure
+
Untrusted input
↓
Altered executable meaning
The long-established response is to preserve a structural distinction between code and data. Prepared statements and parameterized queries prevent user input from changing the intended structure of a query.
Prompt injection presents a related trust problem:
Trusted application instructions
+
Untrusted natural-language content
↓
Unexpected model behavior
Modern AI applications may combine many sources inside the context available to a model:
System instructions
User instructions
Retrieved documents
Web pages
Emails
Tool results
Enterprise records
Conversation history
Persistent memory
Other agents
These sources do not necessarily deserve the same level of trust or authority.
Yet they may all eventually appear to the model as tokens within a shared reasoning context.
NIST describes this problem directly: current generative AI systems combine data and instruction channels, allowing attackers to manipulate resources that the model consumes and thereby influence system operation.
The security question is not simply:
Is this text malicious?
It is:
What authority should information from this source be allowed to exercise?
Where the SQL Injection Analogy Breaks Down
Prompt injection is not simply SQL injection rewritten in natural language.
That distinction matters.
For SQL, the application can use structured interfaces that make the separation between query code and user data explicit. Parameterized queries give the database an enforceable distinction between the two.
LLMs work differently.
Natural-language instructions, external information, examples, retrieved content, and conversational history may all be processed through the same model context.
The model must infer meaning from that context.
There is no general equivalent of a prepared statement that perfectly tells every current language model:
This text may provide facts,
but it must never influence instruction hierarchy.
and guarantees that the distinction will always hold.
That means prompt injection cannot be treated purely as an input-sanitization problem.
OWASP explicitly notes that techniques such as RAG and fine-tuning do not fully eliminate prompt-injection vulnerabilities.
The architectural response therefore has to go beyond trying to make every malicious instruction invisible to the model.
Prompt Injection Is Not Limited to the Chat Box
Direct prompt injection is the obvious case.
A user directly supplies instructions intended to alter model behavior.
But enterprise systems face another important form: indirect prompt injection.
In an indirect attack, the attacker may never communicate directly with the AI application.
Instead, malicious instructions are placed inside information the AI later consumes.
NIST defines indirect prompt injection as prompt injection carried out through control of a resource rather than through direct user input.
Possible sources include:
Web pages
PDFs
Emails
Shared documents
RAG knowledge bases
Code repositories
Database records
Tool responses
MCP resources
Persistent memory
Consider a simple enterprise workflow:
User
↓
"Summarize this supplier document"
↓
AI retrieves document
↓
Document contains hidden or misleading instructions
↓
Model interprets those instructions
The user's request may be completely legitimate.
The application may have no conventional code vulnerability.
Yet the external document can influence the model's behavior.
NIST's work on AI agent hijacking describes this class of attack: agents processing emails, files or websites can encounter malicious instructions embedded in otherwise ordinary-looking data.
This means the security boundary does not end at the user's prompt.
It extends through the entire context supply chain.
The Application Does Not Have to Be Traditionally “Hacked”
Prompt injection challenges a familiar security assumption.
An attacker does not necessarily need:
Remote code execution
Memory corruption
Broken authentication
Stolen credentials
A vulnerable API
A database injection flaw
to influence an AI system.
The software may operate according to its implemented design.
The model may simply assign the wrong meaning or authority to information it was allowed to process.
That creates an important distinction:
Software integrity
may remain intact
while
decision integrity
is compromised.
This does not make traditional application security obsolete.
Authentication, authorization, API security, secrets management, data protection, secure coding, network controls and supply-chain security remain necessary.
But AI introduces another security-relevant layer:
Information
↓
Model interpretation
↓
Reasoning
↓
Generated intent
↓
Potential action
Once that reasoning pipeline can influence enterprise actions, it becomes part of the system's attack surface.
The Risk Changes When AI Moves From Reading to Acting
A prompt injection against a passive summarization system may alter a summary.
A prompt injection against an agent with tools can have much greater consequences.
An agent may be capable of:
Reading enterprise files
Querying databases
Sending email
Updating tickets
Calling APIs
Creating cloud resources
Running scripts
Modifying business data
Invoking MCP tools
Triggering workflows
The impact of successful prompt injection depends heavily on the business context and the amount of agency provided to the AI system.
The important enterprise question therefore becomes:
If the model is successfully manipulated, what can it actually do?
That question is often more useful than:
Can we guarantee that the model will never be manipulated?
Why Prompt Filtering Alone Cannot Be the Security Boundary
Prompt filtering, injection classifiers and model guardrails are useful.
So are:
System-prompt design
Model safety training
Input inspection
Content classification
Output inspection
Red teaming
Prompt-injection detection
Anomaly detection
These mechanisms can reduce risk.
But they solve a different problem from authorization and enforcement.
A classifier might produce:
Prompt injection likelihood: high
That is a security observation.
A separate control must determine:
The agent may not send this file.
The requested tool is not permitted.
This destination is outside policy.
Human approval is required.
The operation is denied.
Those are security decisions and enforcement actions.
This distinction is fundamental.
Detection provides evidence. Enforcement constrains capability.
Probabilistic security signals may inform policy decisions, but high-impact authorization should not depend solely on the same model whose reasoning may already have been influenced.
The Architectural Response: Limit What Manipulated Reasoning Can Become
There is unlikely to be one universal component that solves prompt injection.
Instead, enterprise systems need defense in depth across several boundaries.
1. Preserve provenance and trust information
Applications should know where important context came from.
For example:
User-supplied
Enterprise-controlled
Retrieved internal document
External website
Third-party tool
MCP server
Generated by another agent
Persistent memory
The system should not silently treat these sources as equivalent.
2. Treat external context as potentially untrusted
External content may be necessary for the task while still being untrusted as instruction.
The design should therefore distinguish:
Information the model may use
from:
Authority the system will honor
An external document may supply facts without gaining permission to redefine enterprise policy.
3. Apply least privilege and least agency
An AI agent should not automatically inherit every capability available to its user, application or host environment.
Where practical, authority should be:
Task-specific
Resource-specific
Action-specific
Time-limited
Context-sensitive
Reducing available authority reduces the blast radius of successful manipulation.
4. Authorize tool calls independently of model intent
A model can propose:
Send this document.
Delete this resource.
Execute this command.
Transfer this record.
Call this API.
But proposal should not equal permission.
Before execution, the surrounding application can evaluate:
Who initiated the task?
Which agent is acting?
Whose authority is being used?
Which tool is requested?
Which operation?
Which resource?
Which destination?
Which data classification?
Which constraints apply?
Is approval required?
The resulting allow, deny or approval decision should be enforced outside the model.
5. Use human approval where impact warrants it
Not every operation deserves the same level of control.
Reading public documentation is different from:
Sending sensitive information
Deleting production data
Making a purchase
Changing access permissions
Deploying code
Executing financial transactions
Human approval can provide an additional boundary for consequential operations.
Human approval should not be treated as a substitute for authorization, but it can be an important additional control.
For consequential tool calls, the approval request should show the proposed operation, target resource, destination, and security-relevant parameters. The application should bind approval to those details and verify the match immediately before execution. If the operation or those details change, require fresh approval. This applies established transaction-authorization principles to AI tool execution.
6. Protect persistent memory
Memory creates a particularly important trust problem.
If manipulated content is persisted, an attack may survive beyond the interaction in which it entered the system.
A secure design should consider:
Who may write memory?
What may be stored?
What is its provenance?
How long is it retained?
Which agents can retrieve it?
Can untrusted instructions become persistent?
Can memory be reviewed or removed?
A useful principle is:
Not everything an AI sees should become something it remembers.
7. Treat model output as untrusted until validated for its destination
LLM output can influence additional systems even when it is not itself a tool call.
Generated content may become:
SQL
Shell commands
Code
HTML
API parameters
Emails
Workflow instructions
Configuration
Data sent to another agent
The receiving system should apply the same secure-engineering principles used for other untrusted input.
8. Make actions observable and attributable
Organizations should be able to reconstruct:
Who initiated the request?
Which agent acted?
Which context sources were used?
Which tool was selected?
What authorization decision occurred?
What action executed?
What data crossed a boundary?
Was human approval involved?
Without this information, investigating an AI security incident becomes extremely difficult.
Does Every Enterprise Need an “AI Security Gateway”?
Not necessarily.
Centralizing some of these controls in an AI Security Gateway can be a useful architectural pattern.
For example, a gateway may provide a shared location for:
Policy evaluation
Context inspection
Tool authorization
Data controls
Logging
Output inspection
But the security property matters more than the component name.
Some systems may centralize enforcement.
Others may distribute enforcement among:
Application services
Identity infrastructure
API gateways
Policy engines
Tool brokers
MCP gateways
Data-security controls
Agent runtimes
Workflow systems
EAISF should therefore not assume that one product, gateway or control plane is the universal solution.
The architectural requirement is stronger and more general:
Security-critical authority must remain enforceable outside probabilistic model reasoning.
From Prompt Security to Enterprise AI Security
Prompt injection is an important threat, but treating it as the entire AI security problem would be a mistake.
The broader attack surface includes:
Untrusted context
Excessive permissions
Unsafe tool calls
Delegated authority
Sensitive-data exposure
Memory poisoning
Compromised connectors
MCP tool metadata
Multi-agent interactions
Unsafe outputs
Supply-chain compromise
Insufficient auditability
The better architectural question is therefore not:
How do we build a perfect prompt-injection detector?
It is:
How do we design an AI system that remains bounded even when model reasoning is manipulated or simply wrong?
This moves the problem from prompt engineering into security architecture.
Relationship to EAISF
Within EAISF, prompt injection should be treated as a threat, not as an entire security domain.
It intersects several existing EAISF concerns.
Primary EAISF security domain
Context, Retrieval & Memory Security
The central problem is determining what information may influence AI behavior, what its provenance is, and how much trust it deserves.
Supporting security domains
Tool, MCP & Action Security
Manipulated reasoning becomes more dangerous when it can trigger external actions.
Authorization & Delegation
The system must determine what an agent is allowed to do and under whose authority.
Runtime Policy Enforcement & Human Control
Security policy must be capable of constraining or stopping an action independently of the model's preference.
Relevant EAISF principles
AI reasoning is not authorization.
The model may recommend or propose an action. That does not make the action authorized.
Probabilistic systems require enforceable boundaries.
Security must not depend on perfect model obedience.
Detection and enforcement are different.
Detecting suspicious content and blocking an unauthorized action are different security functions.
Apply least privilege and least agency.
Successful manipulation should encounter a narrow capability boundary.
Treat external context as potentially untrusted.
Documents, websites, emails, tools and memory can all influence model behavior.
Assume compromise or misbehavior can occur.
Architecture should limit damage even when model-level defenses fail.
Questions Enterprise Architects Should Ask
When reviewing an AI application, ask:
- What sources can influence the model?
- Which of those sources are controlled by external or lower-trust parties?
- Do we preserve provenance for retrieved context?
- Can a document, email, website or tool response alter agent behavior?
- What happens if prompt-injection detection fails?
- Which tools can the agent invoke?
- Are tool calls independently authorized before execution?
- Is agent authority narrower than the underlying user's total permissions?
- Can model-generated content cross sensitive data boundaries?
- Can untrusted information enter persistent memory?
- Are memory writes subject to policy?
- Which actions require explicit human approval?
- Can policy enforcement block an action even when the model strongly recommends it?
- Are model outputs treated as untrusted by downstream systems?
- Can security teams reconstruct the context, authorization and tool activity behind an incident?
- What is the blast radius if the model is successfully manipulated?
The answers reveal much more about real security posture than a single prompt-injection detection score.
Key Takeaway
The lasting lesson from SQL injection was not simply:
Detect malicious strings better.
It was to redesign the boundary so that untrusted data could not silently become executable control.
Enterprise AI needs a comparable architectural discipline.
The implementation will be different because language models do not provide the same clean separation between instructions and data that parameterized query interfaces provide for SQL.
That makes layered controls even more important.
The goal should not be to build an AI system that remains secure only when the model interprets every instruction correctly.
The goal should be to build a system in which:
Untrusted information
↓
may influence reasoning
↓
but cannot automatically acquire authority
↓
or bypass independently enforced controls.
The model can reason.
The surrounding security architecture determines what it is actually permitted to do.
References
- NIST — Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations (NIST AI 100-2e2025): https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-2e2025.pdf
- NIST CAISI — Strengthening AI Agent Hijacking Evaluations: https://www.nist.gov/news-events/news/2025/01/technical-blog-strengthening-ai-agent-hijacking-evaluations
- NIST CAISI — Insights into AI Agent Security from a Large-Scale Red-Teaming Competition: https://www.nist.gov/blogs/caisi-research-blog/insights-ai-agent-security-large-scale-red-teaming-competition
- OWASP GenAI Security Project — LLM01:2025 Prompt Injection: https://genai.owasp.org/llmrisk/llm01-prompt-injection/
- OWASP Cheat Sheet Series — SQL Injection Prevention: https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html
- Google Secure AI Framework — Security Controls for Generative AI Systems: https://saif.google/secure-ai-framework/controls
- Microsoft Defender Security Research — When Prompts Become Shells: RCE Vulnerabilities in AI Agent Frameworks: https://www.microsoft.com/en-us/security/blog/2026/05/07/prompts-become-shells-rce-vulnerabilities-ai-agent-frameworks/
- Microsoft Agent Framework — Agent Safety: https://learn.microsoft.com/en-us/agent-framework/agents/safety
- OpenAI — Understanding Prompt Injections: https://openai.com/safety/prompt-injections/