Skip to main content
Aona
Book a demo
Resources / Guides

The types of
AI guardrails,
explained.

Six practical controls. See what each checks, who applies the response and where Aona fits.

Explore the six typesGet the evaluation questions
Control atlas06 types / 03 questions
Start withthe risk.
01
Information

What can be shared?

01Sensitive data03Content and usage
02
Execution

What can happen?

02Prompt injection04Tool and action05Output validation
03
Judgment

Who needs to decide?

06Human oversight
Choose a type to see its checks, responses and limits below.

A practical taxonomy

Six types of guardrails.

These categories overlap. Open a row to see the check, response, limitations and Aona's role.

6 of 6 types
01

Sensitive-data guardrails

Control what information is shared with AI.

Data

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
02

Prompt-injection guardrails

Keep untrusted content from becoming instructions.

Content

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
03

Content and usage guardrails

Check whether a request fits the intended use.

Content

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
04

Tool and action guardrails

Limit what an agent is allowed to do.

Actions

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
05

Output-validation guardrails

Check a response before it becomes an action or a claim.

Actions

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
06

Human oversight

Put a person at the decisions that need judgment.

Oversight

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

Put the pieces together

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.

Take it into your evaluation

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.

  1. What is covered?
  2. Who enforces the decision?
  3. What evidence records the result?
Open all seven evaluation questions
  1. 01

    Which user, app, agent and input path does this control cover?

  2. 02

    What risk and policy does the check address?

  3. 03

    What happens when the check allows, rejects, times out or fails?

  4. 04

    Who applies the decision, and can another path bypass it?

  5. 05

    Where is data processed, stored and retained?

  6. 06

    What evidence records the action actually taken?

  7. 07

    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.

Questions

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.
Aona AI guardrails

Turn the right controls into a practical plan.

Map the data, policy and supported coverage with our team.

Book a demoReview product options
6 Types of AI Guardrails: Examples, Limits and How to Choose | Aona