What are AI guardrails?
AI guardrails (also called LLM guardrails or GenAI guardrails) are preventive safety controls that constrain an AI system's behavior within defined policy boundaries, shaping what a model can see, do, and return.
Guardrails are one of three control types that work together:
Preventive controls (guardrails): Applied before and during inference to stop unsafe behavior.
Detective controls: Logging, monitoring, and alerting that catch violations after they occur.
Governance controls: Policies, documentation, and audit requirements that set the rules.
In practice, three layers of guardrails work together:
Input guardrails: Filter, validate, and reshape prompts before they reach the model.
Processing guardrails: Control which context, data, and tools the model can access during reasoning.
Output guardrails: Evaluate the model's response and block, modify, or reject it before it reaches the user.
These differ from traditional application security, which protects deterministic code and structured inputs. AI guardrails manage non-deterministic systems and natural language, where behavior can be influenced through prompt injection, OWASP's top-ranked LLM risk. Guardrails are how you turn a prototype into a production system while still meeting your safety, security, and compliance requirements.
AI Security Starter Pack
Get the essential templates and checklists to secure AI workloads from code to runtime.
Why AI guardrails matter
AI systems take in untrusted natural language, yet they often run behind public or internal APIs with access to real business data: personal information, financial records, proprietary documents. Traditional controls weren't built for this. A firewall can inspect a network packet, but it can't inspect a prompt or judge whether a model's response is safe. That blind spot is why traditional security misses attacks like prompt injection, retrieval manipulation, and unexpected tool use.
Amazon Bedrock, Azure OpenAI, and Google Vertex AI all ship with basic safety filters, but default filters aren't enough on their own. Teams still need their own policies, identity controls, and runtime monitoring layered on top. Skip that, and normal AI behavior can escalate into a security incident: because the model's output reaches users the instant it's generated, there's no buffer between a bad response and real-world impact.
Regulated industries already treat this as table stakes. Automotive manufacturers, for example, run AI assistants in-vehicle with strict input filtering, controlled access to vehicle data, and runtime checks on every response before it reaches a driver.
Where guardrails are enforced
Guardrails can be integrated at several points in your architecture:
API gateway: Authentication, rate limiting, and coarse content checks.
Orchestration layer: Chains, middleware, and validators that implement prompt filters, context controls, and policy logic.
Cloud services: Provider safety filters (e.g., toxicity or topic filters) that run during inference.
Identity layer: IAM policies that define which data sources, APIs, and tools the model's service account can access.
Tool boundaries: Validation and approval flows for agent actions.
Vector stores: Access controls and document-level filtering to prevent context poisoning or data leakage.
Build pipeline: Integrity checks and provenance validation on model weights, checkpoints, and container images before they reach production. A tampered artifact bypasses every runtime guardrail built on top of it.
Output filters: Classification models or rules that block or rewrite unsafe responses.
Guardrails remove a different class of risk at each layer, so one layer catches what another misses. In its AI Security Readiness report, Wiz found that a lack of AI security expertise is the top AI security challenge teams report.
Types of AI guardrails
Guardrails run as a pipeline. Inputs are checked before they reach the model, the model runs inside a controlled execution context, and outputs are validated before they reach users or downstream systems.
1. Input guardrails
Input guardrails evaluate and reshape incoming requests before inference. This is the first prevention layer against unsafe behavior.
Common input guardrails include:
Prompt injection and jailbreak detection: Identify attempts to override system instructions or access restricted data.
Sensitive data scanning: Detect and redact PII, PHI, credentials, or keys within prompts.
Illegal or disallowed content: Block requests that seek harmful instructions or prohibited material.
Abuse and misuse controls: Enforce rate limits, identify anomalous usage, and block brute-force attempts against safety filters.
In practice, input guardrails may reject a prompt, request clarification, or sanitize the input (e.g., masking identifiers) before sending it to the model.
2. Processing guardrails
Processing guardrails shape the execution context in which the model operates. They determine what the model is allowed to access and how it can act, beyond the text of the prompt.
Processing guardrails typically include:
Context controls: Restrict which documents, fields, or logs can be provided to the model for each request.
RAG safety: Limit which collections a retrieval pipeline can query, how many results it can use, and apply filtering to retrieved content.
Policy enforcement: Encode business rules such as “this model cannot access production payment APIs” or “only return data from the same region.”
Identity and least-privilege controls: Use IAM policies to restrict the model’s service account from accessing unauthorized data sources or services.
Tool and agent guardrails: Define which tools an AI agent may call, which actions require human approval, and how parameters are validated before execution.
Cloud provider safety features (e.g., content filters or topic filters in Azure OpenAI, Bedrock, or Vertex AI) can support this layer, but should be combined with organization-specific rules and runtime access controls.
3. Output guardrails
Output guardrails evaluate the model’s response before it is returned to the user or used by another system.
Common output guardrails include:
Toxicity and content safety: Detect hate, harassment, self-harm content, or other disallowed categories.
Hallucination detection: Compare claims against trusted sources or retrieved context to identify unsupported statements.
Sensitive data leakage: Scan for PII, PHI, credentials, or secrets in outputs and remove or block as needed.
Brand and policy alignment: Adjust tone, include required disclosures, and enforce compliance rules in regulated domains, in line with frameworks like the NIST AI Risk Management Framework.
Output guardrails can block the response, request clarification, or rewrite the response while preserving accurate content.
Many teams combine rule-based checks (allow/deny patterns, redaction rules, prompt policies) with ML-based classifiers (toxicity detection, jailbreak detection, PII detection). Others wrap vendor models with a consistent safety layer across providers using moderation APIs or open-source guardrail frameworks.
Inside MCP Security: A Field Guide
Explore emerging risks in agent and tool-calling architectures and how to secure them.
AI risks that guardrails are designed to address
AI guardrails exist to prevent specific classes of AI security risks. Understanding these threats helps you design controls that protect both your data and your infrastructure.
Most AI risks fall into four categories:
1. Manipulating model behavior
Attackers attempt to influence or override model instructions to produce unsafe actions or outputs.
Prompt injection: Crafting inputs that override system instructions and extract data or trigger disallowed actions.
Indirect prompt injection: Embedding malicious instructions inside documents or data that the model later ingests through retrieval or context.
Jailbreaks: Forcing the model to ignore built-in safety constraints using role-playing, translation, or other indirect request patterns.
Adversarial prompts: Subtle prompt patterns designed to cause incorrect outputs without appearing malicious.
These risks are primarily addressed through input guardrails (filtering, sanitization) and processing guardrails (policy enforcement during execution).
2. Manipulating data and context
Instead of attacking the model directly, adversaries target the data pipelines that shape model behavior, using techniques like data poisoning.
Data poisoning: Injecting malicious or biased data into training or fine-tuning sets so the model learns unsafe patterns.
Context poisoning: Manipulating the documents or retrieval index used by RAG systems to influence responses.
RAG poisoning: Controlling which documents are retrieved so the model repeats misleading information.
Fine-tune hijacking: Compromising fine-tuning jobs to insert backdoors.
These threats require processing guardrails (RAG controls, context filters) and governance controls on how training and ingestion pipelines are secured.
3. Extracting sensitive information and IP
Attackers attempt to recover data from the model or its supporting components.
Model extraction: Reproducing a proprietary model’s behavior through repeated queries.
Membership inference: Determining whether specific records were part of training data by probing model responses.
Sensitive data leakage: The model reproduces memorized content from logs, training data, or vector stores.
These risks are mitigated through input/output guardrails (PII detection, redaction) and processing guardrails that restrict access to sensitive data.
4. Exploiting access through agents and tools
This category covers what happens once a model can act, not just respond. Wiz's State of AI in the Cloud 2026 report found that at least 57% of organizations run a self-hosted AI agent.
Over-permissioned agents: Agents that have broad access to internal APIs, databases, or cloud services.
Tool abuse: Using allowed tools in unexpected ways, leading to unauthorized operations.
Identity escalation: A model acting under a privileged service account without proper isolation.
These risks require processing guardrails (least-privilege IAM, tool allowlists, approval workflows) and runtime monitoring to detect unexpected behaviors.
How AI guardrails work in practice
Guardrails are not a single filter bolted on at the end. They are multiple controls spread across the request path, from the API entry point to output validation, and each layer removes a different class of risk.
A common inference flow with guardrails looks like this:
User request: A user sends a prompt or API call.
Input guardrails: Input guardrails validate, sanitize, or reject the request before it reaches the model.
Context construction (RAG): If the system uses retrieval, it fetches and filters documents from only approved data sources.
Policy enforcement: Business rules and security checks shape what the model can access and which tools it may call.
Model inference: The model generates a response within these constraints.
Tool execution (agents): If the model requests actions, the system validates and executes the parameters under least privilege, or routes them for human approval.
Output guardrails: Output guardrails check the response for safety, supported claims, sensitive data, and compliance before it returns to the user.
Logging and monitoring: The system logs the full interaction for analysis, alerting, and improvement.
This pattern lets you prevent unsafe behavior before it occurs, and detect issues that slip through.
Examples of AI guardrails
The clearest way to understand guardrails is to see what they look like at each layer of a real cloud deployment. Here are concrete examples of controls teams put in place across the request path.
Input – prompt injection and jailbreak filter: A classifier in front of the model flags a customer-support chat prompt that tries to override its system instructions, then rejects or sanitizes the request before inference.
Processing – RAG source allowlist: A retrieval pipeline can only query an approved set of vector-store collections, so a support assistant never pulls documents from an unrelated finance index.
Processing – IAM least-privilege scoping: The model’s service account is limited to read-only access on a single data bucket, so a compromised prompt cannot reach production databases or write to storage.
Output – PII and secret redaction check: An output filter scans the generated response for personal data, API keys, or credentials and blocks or masks them before the answer reaches the user.
Agent – tool allowlist with approval: An agent may call a read-only search tool on its own, but any action that writes data or triggers a payment routes to a human for approval first.
Together, these controls show how guardrails move from filtering text on the way in, to scoping what the model can touch, to validating what comes back out. No single example is enough on its own, which is why teams layer them across the same request.
How Wiz enables comprehensive AI guardrails across the security lifecycle
Guardrails only hold if the infrastructure, data paths, and identities around your models are configured correctly, and that context is exactly what most teams lack. A prompt injection filter doesn't help if the service account behind it can still reach a production database, and a RAG allowlist doesn't help if the vector store it points to is publicly exposed. Wiz AI-SPM (AI Security Posture Management) gives you end-to-end visibility into your AI estate across AWS, Azure, and GCP, from managed AI services and inference endpoints to retrieval pipelines and the identities behind them. Wiz detects misconfigurations in platforms like SageMaker, Azure OpenAI, and Vertex AI that can bypass your guardrails, such as public endpoints with access to sensitive data or agents running under over-permissioned roles.
The Wiz Security Graph maps how infrastructure, identities, data, and AI workloads interact, surfacing toxic combinations like an exposed endpoint reaching a sensitive vector store through a broad service account. That combination is invisible to a guardrail operating only at the prompt or output layer, since neither one has visibility into how the underlying infrastructure is configured.
Wiz extends those controls across the development and runtime lifecycle. Wiz Code scans Infrastructure as Code (IaC) and application code to catch issues like hardcoded model keys before deployment, so misconfigurations never reach production in the first place. Wiz Defend monitors AI workloads at runtime for unusual API patterns or exfiltration attempts, catching what preventive guardrails miss. Built-in Data Security Posture Management (DSPM) capabilities classify sensitive training and inference data and show how it flows into your models, so you know what's actually at risk if a guardrail fails.
In short, Wiz provides guardrails for your guardrails, keeping the infrastructure, data, and identities around your models properly configured and monitored. Get a demo to see how.
Want to see it in action?
See how Wiz maps and protects your AI estate across code, cloud, and runtime.
