Prompt Injection Attacks in Enterprise LLM Deployments

Prompt injection is the defining security risk of the enterprise LLM era. The attack is conceptually simple: an adversary embeds instructions in content that an LLM processes, causing the model to execute attacker-controlled commands rather than the application developer's instructions. In a standalone chatbot with no tool access, the blast radius is limited. In an enterprise deployment where the LLM has tool access to databases, APIs, email systems, code execution environments, and internal knowledge bases, a successful prompt injection can exfiltrate sensitive data, modify records, send unauthorised communications, or execute arbitrary code.

The Attack Taxonomy

Direct prompt injection occurs when an attacker directly manipulates the input to the LLM -- for example, a user who crafts a message to override the system prompt and cause the model to behave outside its intended scope. Indirect prompt injection is more dangerous in enterprise contexts: the adversarial instructions are embedded in content that the LLM processes on behalf of the user, without the user being the attacker. A document retrieved from a file store, a webpage fetched by an LLM agent, a customer support email processed by an LLM -- any of these can contain embedded instructions that the model may follow.

The risk profile escalates with the capability of the LLM system. A read-only question answering system has limited attack surface because the model cannot take consequential actions. An LLM agent with tool access to send emails, query databases, execute code, or call external APIs creates a much larger attack surface because a successful injection can result in real-world consequences beyond the LLM conversation.

Why Standard Input Validation Is Insufficient

The security intuition to validate and sanitise inputs before passing them to a system does not translate directly to LLM prompt injection. Traditional input validation works by checking inputs against a known-malicious pattern set or enforcing a structural grammar. Prompt injection is semantic, not syntactic: the adversarial content looks like natural language because it is natural language. There is no regex that reliably distinguishes legitimate user content from embedded adversarial instructions.

Secondary LLM classifiers trained to detect prompt injection attempts provide a probabilistic mitigation. They are not a complete solution. A sufficiently creative attacker can construct injections that evade classifiers, particularly as classifier training datasets do not cover all attack variants. Defence in depth is the correct engineering posture: multiple overlapping controls, none of which is assumed to be complete on its own.

Privilege Separation as the Primary Control

The most effective architectural control against prompt injection is privilege separation: the LLM does not execute tool calls directly. Instead, the LLM generates an intent representation, and a separate privileged execution layer validates the intent against an allowlist of permitted actions before executing it. The LLM never has direct access to tool execution -- it can only request actions that the execution layer is permitted to approve.

This pattern applies the principle of least privilege to LLM architecture. An LLM agent that needs to query a customer database should have read access to specific tables for specific purposes, not general database access. An LLM that needs to send notifications should request that a notification be sent -- with that request subject to rate limiting, recipient validation, and content filtering by a separate service -- not send emails directly using authenticated credentials.

Audit Logging for LLM Tool Calls

Every tool call executed on behalf of an LLM agent must be logged with sufficient detail to enable forensic reconstruction of a prompt injection incident. The log record must include the tool name, the parameters passed to the tool, the identity that authorised the execution, the timestamp, and a reference to the LLM conversation context that generated the tool call request. This logging is required for incident response, for detecting patterns of injection attempts across the user population, and for demonstrating to regulators that the LLM system has adequate access controls.

OWASP LLM Top 10 and Enterprise Security Programs

OWASP LLM Top 10 lists prompt injection as the highest-priority risk for LLM applications. Enterprise security programs that have integrated the OWASP web application security framework need to extend their threat modelling, penetration testing, and security review processes to cover LLM-specific risks. A standard DAST tool scanning an LLM endpoint for SQL injection vulnerabilities will not detect prompt injection exposure. LLM security testing requires purpose-built tooling, red teaming with adversarial prompt construction, and architectural review focused on the tool access boundary and the privilege model. Most enterprise security programs have not yet made this extension.