--- title: "6 Types of AI Guardrails: Examples, Limits and How to Choose | Aona" description: "Compare six practical guardrail categories: sensitive data, prompt injection, content safety, tool actions, output validation and human oversight. See where each fits." canonical: "https://aona.ai/resources/guides/types-of-ai-guardrails/" --- # The types of AI guardrails, explained. [Resources / Guides](https://aona.ai/resources/guides/) Start with the risk you need to control. This practical guide separates what a guardrail checks, where it applies and who is responsible for the response. ## The control map - Information: What can be shared? - Actions: What can happen? - Judgment: Who needs to decide? Match the risk. Find the boundary. Verify the response. ## AI guardrails pages - [Overview](https://aona.ai/solutions/ai-guardrails/) - [For employees](https://aona.ai/solutions/ai-guardrails-for-employees/) - [For AI agents](https://aona.ai/solutions/ai-agent-guardrails/) - [Guardrail types](https://aona.ai/resources/guides/types-of-ai-guardrails/) ## Six types of guardrails. These categories overlap. Open a row to see the check, response, limitations and Aona's role. ### Sensitive-data guardrails Control what information is shared with AI. Illustrative scenario: A support prompt includes a customer's email address and account reference. What to check: Identify information covered by your policy, including personal data, secrets or confidential business content. How to respond: Block the submission or use an approved redaction path, then review what remains. What it cannot prove: A detector can miss information. Masking identifiers does not automatically make the remaining content anonymous or HIPAA de-identified. Aona policy and data protection: Aona applies configured data-protection policies to supported employee prompts and files, and evaluates content sent through its APIs. [Read the primary reference](https://genai.owasp.org/resource/owasp-genai-llm-top-10-2026/) ### Prompt-injection guardrails Keep untrusted content from becoming instructions. Illustrative scenario: A retrieved document tells an agent to ignore its task and reveal credentials. What to check: Consider the origin of instructions and whether retrieved content is trying to redirect the task. How to respond: Separate trusted instructions from data, constrain tools and permissions, and add checks at relevant boundaries. What it cannot prove: Filtering alone cannot reliably prevent every prompt injection. The surrounding application must limit the consequences of a compromised decision. Application security design: Assess the exact policy check you need with Aona. Instruction hierarchy, retrieval trust and tool permissions remain part of your application design. [Read the primary reference](https://genai.owasp.org/resource/owasp-genai-llm-top-10-2026/) ### Content and usage guardrails Check whether a request fits the intended use. Illustrative scenario: An internal assistant is asked to help impersonate a customer. What to check: Evaluate the request against a clear acceptable-use policy, taking its context and intended assistance into account. How to respond: Apply the configured response and explain the relevant policy to the person or calling application. What it cannot prove: Context matters. Similar words can describe legitimate education or prohibited assistance, so test false positives and missed cases. Configured Aona evaluation: Aona supports configured guardrail evaluation. Agree the policy and validate representative requests for your chosen integration. [Read the primary reference](https://www.nist.gov/itl/ai-risk-management-framework) ### Tool and action guardrails Limit what an agent is allowed to do. Illustrative scenario: An agent can read a ticket, but needs authorisation before issuing a refund. What to check: Verify the requested operation, target, permission and permitted scope before execution. How to respond: Use least privilege, allowlisted operations, limits and proportional human approval. What it cannot prove: A well-written prompt is not an access-control boundary. Enforce permissions in the application or execution environment. Application-enforced control: An Aona content evaluation can inform a checkpoint. Your integration owns tool authorisation, action enforcement and approval handling. [Read the primary reference](https://genai.owasp.org/resource/owasp-genai-llm-top-10-2026/) ### Output-validation guardrails Check a response before it becomes an action or a claim. Illustrative scenario: Generated SQL must be validated before any query reaches a database. What to check: Validate expected structure, allowed operations and relevant factual or business constraints. How to respond: Treat generated content as untrusted input. Reject, safely transform or route it for review before use. What it cannot prove: Valid JSON can still contain a wrong answer. Schema checks, factual verification and safe execution address different problems. Application validation: Use Aona for an explicitly integrated content check where appropriate. Structural validation, grounding and execution safety need their own controls. [Read the primary reference](https://genai.owasp.org/resource/owasp-genai-llm-top-10-2026/) ### Human oversight Put a person at the decisions that need judgment. Illustrative scenario: A person reviews the recipient and content before an agent sends an external message. What to check: Give the reviewer the proposed action, consequences and enough evidence to make a decision. How to respond: Require a meaningful approval, provide a way to intervene and record the decision. What it cannot prove: A checkbox without context can become a rubber stamp. Approval must happen before the consequential action, with a real ability to stop it. Human and application control: Aona policy evidence can inform a review. It does not by itself create approval routing or prove that a human exercised judgment. [Read the primary reference](https://www.nist.gov/itl/ai-risk-management-framework) ## One workflow can need several controls. Take a support assistant that summarises a ticket and drafts a customer reply. 1. **Before the model.** Reduce unnecessary customer data and keep retrieved ticket text separate from trusted instructions. 2. **Before the tool.** Allow the agent to read the right ticket. Require separate authorisation for sending or modifying records. 3. **Before the outcome.** Check the response against the source and give a person the consequential decisions. ## Know what you are evaluating. Use these questions with your security team or an AI vendor. A “yes” on a feature list is only the start. Start with three questions: What is covered? Who enforces the decision? What evidence records the result? ### All seven evaluation questions 1. Which user, app, agent and input path does this control cover? 2. What risk and policy does the check address? 3. What happens when the check allows, rejects, times out or fails? 4. Who applies the decision, and can another path bypass it? 5. Where is data processed, stored and retained? 6. What evidence records the action actually taken? 7. Which allowed, prohibited and ambiguous examples will we test? ## Sources and further reading This is Aona's practical guide, informed by the primary references below. Examples are illustrative; they are not measured product results. - [OWASP GenAI LLM Top 10 2026](https://genai.owasp.org/resource/owasp-genai-llm-top-10-2026/): Prompt injection, sensitive information, excessive agency and output risks. - [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework): A broader approach to governing, mapping, measuring and managing AI risk. - [Aona product and coverage reference](https://aona.ai/product/compare/): Browser, desktop and API responsibilities for the configuration you choose. ## A few useful distinctions. ### Is there one standard list of AI guardrail types? No. Vendors and security frameworks organise controls differently. This guide uses six practical categories to make the choices easier to compare. They overlap and are not a certification checklist. OWASP's risk taxonomy and the NIST AI Risk Management Framework provide broader context. ### What is the difference between input and output guardrails? Input guardrails evaluate information before it reaches a model or another step. Output guardrails evaluate a model's response before a person or system uses it. A tool-action control sits at a different boundary: it decides whether an operation is permitted. A workflow may need all three. ### Are deterministic rules better than model-based guardrails? They suit different checks. Deterministic rules are useful for precise formats and explicit limits. Model-based checks can assess context that a simple pattern misses, but can also make mistakes and be influenced by adversarial inputs. Choose based on the risk, test both allowed and prohibited examples, and review latency, false positives and missed detections. ### Which types does Aona help with? Aona's core role is securing employee AI use through covered-endpoint visibility, configured policy enforcement and sensitive-data protection on supported prompts and files. Evaluation APIs add content checks at caller-controlled checkpoints. Tool permissions, execution sandboxes, comprehensive output verification and approval routing require their own application controls; this guide does not claim those are all Aona features. ### How should we test guardrails? Use representative allowed, prohibited and ambiguous examples across the paths people or agents actually use. Check the resulting action as well as the evaluation, test errors and timeouts, inspect available evidence and retest after policy or client changes. A successful synthetic website example is not an installed-product test. ## Turn the right controls into a practical plan. Map the data, policy and supported coverage with our team. [Book a demo](https://aona.ai/book-demo/) [Review product options](https://aona.ai/product/compare/) Canonical page: https://aona.ai/resources/guides/types-of-ai-guardrails/