The AI Security Stack: Tools, Controls, and Architecture for LLM Deployments

The first layer of the AI security stack is not AI-specific at all. It is the identity and access control infrastructure that determines who can interact with the AI system, what data they can access through it, and what actions they can take using it. This layer fails in AI deployments for the same reasons it fails in traditional application deployments — overly broad permissions, shared credentials, inadequate session management — plus some failure modes specific to AI architecture.

The most common identity failure in AI deployments is the absence of user context propagation through the retrieval and tool execution layers. An application that authenticates users at the front end but then queries a RAG knowledge base or executes tool calls using a shared service account has broken the access control chain. The knowledge base and the tools see a single identity — the service account — rather than the individual user's identity and entitlements. This means authorization decisions that should be made at the retrieval and tool execution layers cannot be made correctly, and the application's access controls are only as strong as whatever filtering the LLM applies based on system prompt instructions. That is not a security control.

Fixing this requires propagating user identity and authorization context through every layer of the AI application. The retrieval query should include the authenticated user's identity and entitlements so the retrieval layer can filter results to documents the user is authorized to see. Tool calls should execute under credentials scoped to the requesting user's permissions, not a shared service account with broad access. This architecture requires more implementation work than shared service accounts, and it is the correct architecture.

The second layer addresses the attack surface created by the fact that AI applications accept natural language input that influences model behavior. Traditional input validation rejects inputs that match known malicious patterns — SQL injection strings, XSS payloads, command injection sequences. Natural language cannot be validated this way. You cannot define a regular expression that reliably distinguishes a legitimate user question from a prompt injection attack, because the distinction depends on context and intent rather than syntax.

Prompt security controls operate through a combination of detection, routing, and architectural constraints. Detection approaches use classifiers trained to identify inputs with characteristics associated with prompt injection — instructions directed at the model rather than the application, persona adoption requests, attempts to reveal or override the system prompt, requests that fall outside the application's intended scope. These classifiers have false positive and false negative rates that must be calibrated for each deployment; overly aggressive detection degrades legitimate user experience while under-detection allows injection attacks through.

Architectural constraints are more reliable than detection for high-risk deployments. Separating the system prompt from user input using structural delimiters that the model treats as distinct contexts reduces injection risk. Constraining the model's output format through structured prompting techniques limits the blast radius of a successful injection. Implementing human review checkpoints for high-risk actions ensures that adversarially influenced outputs cannot directly execute consequential actions without human confirmation. These constraints do not eliminate prompt injection risk — they reduce it and limit its impact.

The current generation of commercial prompt security products — AI firewalls, LLM guardrail platforms — provide detection and filtering capabilities of varying quality. The most mature products offer configurable policy enforcement for output content, input classification, and topic restriction. Evaluate them against your specific deployment's attack surface rather than against vendor benchmark claims, which are typically measured against synthetic attack datasets that do not represent the adversarial inputs your specific application will face in production.

The third layer addresses the data security requirements specific to RAG architectures and other patterns that inject external data into the model's context at inference time. This is the layer where most of the novel AI security risk lives — not in the model itself, but in the data pipeline that feeds context to the model.

The primary control requirements at this layer are authorization enforcement, data classification awareness, and context boundary integrity. Authorization enforcement means that every retrieval operation filters the result set to documents and records the requesting user is authorized to access, and that this filtering happens in the retrieval infrastructure rather than in the model's reasoning. Data classification awareness means that the retrieval system understands which documents contain sensitive or regulated data and applies additional controls — reduced retrieval scope, output filtering, audit logging — when those documents are accessed. Context boundary integrity means that injected context is structurally distinguished from user input in a way that reduces the model's susceptibility to treating adversarial content in retrieved documents as instructions.

Vector database security is an emerging control area that most organizations have not addressed. Vector databases store document embeddings and are queried at inference time to retrieve relevant context. They are frequently deployed with default configurations — no authentication, no network access controls, no audit logging — because they are treated as internal infrastructure rather than as systems that handle sensitive data. A vector database that contains embeddings of confidential documents is a sensitive data store and should be treated as one: authentication required, network access restricted to the AI application, audit logging enabled, and embeddings protected against unauthorized extraction.

Data leakage through model outputs is a control requirement that straddles the retrieval layer and the output layer. A RAG system that retrieves confidential documents and then includes verbatim excerpts from those documents in its responses to users is leaking data through a channel that traditional DLP tools will not detect because the output is model-generated text rather than a file transfer. Output scanning for sensitive data patterns — PII, financial data, confidential terms — is a control that some AI security platforms provide and that can be implemented independently through post-processing pipelines.

The fourth layer provides visibility into AI system behavior in production — the equivalent of SIEM and EDR for AI deployments. Runtime monitoring for AI systems captures interaction logs, detects behavioral anomalies, and provides the audit trail required for incident investigation and compliance documentation.

The logging requirements for a defensible AI security stack go beyond what most AI platforms log by default. Complete interaction logs should capture the full user input, the complete retrieved context including document identifiers and relevance scores, the complete model output, any tool calls made including parameters and responses, the session identifier and authenticated user identity, and timestamps for each component of the interaction. This logging footprint is larger than many organizations anticipate, and the storage and retention infrastructure for it must be designed before deployment rather than retrofitted after an incident.

Behavioral anomaly detection for AI systems requires application-specific baselines. What constitutes anomalous behavior for a customer service AI is different from what constitutes anomalous behavior for a clinical documentation assistant. Baselines should be established for query volume and patterns, retrieval depth and document access distribution, output length and format distributions, tool call frequency and parameter patterns, and error and refusal rates. Deviations from these baselines warrant investigation. A sudden increase in retrieval depth, an unusual distribution of document access, or a spike in refusal rates can all indicate adversarial activity or system compromise.

Alerting thresholds must be calibrated to produce actionable signal rather than noise. An AI monitoring system that generates hundreds of low-confidence anomaly alerts per day will be treated the same way as a SIEM with uncalibrated detection rules — ignored. Start with high-confidence, high-impact alert conditions: failed authentication attempts against the AI application's API, tool calls with parameters outside expected ranges, outputs that trigger sensitive data classifiers, and session patterns consistent with automated probing. Build out detection coverage from that baseline as you develop operational experience with what the system's normal behavior looks like.

The fifth layer is the governance and change management infrastructure that ensures the security controls in layers one through four are consistently applied, maintained, and updated as the AI deployment evolves. Technical controls without governance infrastructure degrade over time — access permissions expand through exception accumulation, logging configurations drift, monitoring thresholds become stale as system behavior changes.

AI system change management must treat system prompt changes, model version updates, and new tool integrations as configuration changes subject to security review and testing. A system prompt change that expands the model's data access scope or modifies its tool authorization logic is a security-relevant change. Model version updates from a provider may alter the model's behavior in ways that affect the effectiveness of existing prompt security controls. New tool integrations expand the AI system's attack surface and require re-assessment of the authorization boundary testing that was performed at initial deployment.

The governance infrastructure for AI security converges with the broader AI governance program. The asset inventory, risk classification framework, and policy documentation that constitute the AI governance program are also the foundation of the AI security program's change management and audit documentation. Organizations that build these capabilities in coordination — rather than as separate initiatives from the security team and the compliance team — avoid duplication and produce more consistent documentation.

The five layers do not need to be fully implemented simultaneously. The prioritization should follow the risk profile of your existing AI deployments. Identity and access controls at the application boundary are non-negotiable for any deployment that accesses sensitive data — implement these first. Data security at the retrieval layer is the highest-priority novel control for RAG-based deployments — implement these before deploying RAG systems with regulated data access. Runtime logging sufficient for incident investigation should be in place before any AI system reaches production.

Prompt security controls and behavioral anomaly detection can be phased in after the foundational controls are operational, prioritizing deployments with the highest adversarial exposure — customer-facing applications, systems accessible to untrusted users, agentic deployments with broad tool access. Governance infrastructure should be built in parallel with technical controls rather than deferred until the controls are complete.

The organizations that build AI security infrastructure before they need it — before a security incident, before a regulatory examination, before a customer security questionnaire that surfaces gaps — will have a compounding advantage as AI adoption deepens. The control frameworks built for today's LLM deployments will extend to tomorrow's agentic systems. The monitoring baselines established now will make future anomaly detection materially more effective. Security infrastructure, like all infrastructure, is most valuable when it is built before it is urgently needed.