---
title: "AI Agent Guardrails | Policy Checks for Agent Integrations | Aona"
description: "Add Aona policy evaluation at agent checkpoints you control. Understand API decisions, caller enforcement, local agent visibility and human oversight."
canonical: "https://aona.ai/solutions/ai-agent-guardrails/"
---

# AI agent guardrails. Check before the next call.

[Workforce AI Security](https://aona.ai/solutions/)

Bring policy evaluation to the points your agent integration controls. Check submitted text or supported files with Aona, then make the result matter in your application.

You choose the checkpoint. Your integration enforces.

## An application-owned checkpoint

Illustrative logic, not executable API syntax.

### Policy violation

Content does not meet the example policy.

Do not send the original content. Your integration stops the call or uses an approved, validated redaction path.

```text
content prepared
→ evaluate with Aona
← policy verdict: reject
→ caller stops this request
```

A rejection only changes the workflow when the caller applies it.

### Allowed input

Content meets the example policy.

Continue within the permitted scope. Your application still checks tool permissions and the proposed operation before execution.

```text
content prepared
→ evaluate with Aona
← policy verdict: allow
→ caller checks next action
```

Passing a content check does not grant an agent extra permissions.

### Timeout or error

No usable evaluation result.

Use an explicit failure policy. This example stops the call for review. Define your own response before the integration is deployed.

```text
content prepared
→ evaluate with Aona
← evaluation unavailable
→ caller stops for review
```

The example fails closed. Aona does not set this behavior for every integration.

## 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/)

## Two routes. Different responsibilities.

Choose visibility on a managed device, evaluation inside your application, or both where supported.

### Native endpoint: understand local agent context.

Review supported local AI agents and MCP context alongside covered AI traffic on managed devices.

Local agent visibility is available in selected rollouts. Inventory does not establish control over every tool action.

[Review endpoint coverage](https://aona.ai/resources/ai-security-coverage/)

### Evaluation APIs: check content at your checkpoint.

Submit text to a framework or guardrail evaluation, or supported files to a framework evaluation.

Your application applies the verdict, returned redaction and failure policy. Calls outside the integration are outside that checkpoint.

[Explore the API route](https://aona.ai/product/compare/)

## Review the action before it happens.

Give the reviewer the target, proposed change and evidence for consequential decisions.

Limit access. Review the action. Verify the result.

Your application owns permissions, approval and execution.

Illustrative application review: before sending a reply, the reviewer sees the target (Ticket SAMPLE-104), proposed action (send drafted response) and evidence (source ticket and draft).

### Designing a meaningful review

- **Limit permissions.** Give the agent only the tools, identity and access needed for its task. Enforce those limits in trusted systems.
- **Make review meaningful.** For consequential actions, show a person the proposed target, action and evidence before approval.
- **Verify the result.** Check generated outputs and actual system state before treating the task as complete. Preserve useful evidence.

These are agent-security design practices. Tool authorisation, approval routing and execution controls remain your application’s responsibility.

## Know what was checked. Record what happened.

A verdict describes the evaluation. It does not prove that a request was stopped, a tool was restricted or a person approved an action.

Stateless evaluations do not automatically create analytics events. Record the action your integration took, and keep evaluation APIs distinct from APIs that retrieve existing events.

[Understand event APIs and webhooks](https://aona.ai/docs/api-and-webhooks/)

## 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?

## Your questions, answered.

### What are AI agent guardrails?

Agent guardrails are controls around an AI agent's inputs, permissions, tools, actions and outputs. Examples include evaluating sensitive data before a model call, limiting tool access and requiring human approval for consequential actions. Different layers address different risks; a content check alone cannot constrain everything an agent can do.

### How can we use Aona with an AI agent?

Your integration can call Aona framework or guardrail APIs to evaluate supplied text; framework APIs also evaluate supported files. You choose the checkpoint and apply the returned verdict or redaction. Define timeout and error handling, cover alternative paths and record the decision your application actually took. Aona endpoint products separately provide supported AI traffic protection and local agent visibility in selected rollouts.

### Will the API stop an agent by itself?

No. An evaluation API returns a result to the caller. Your application must enforce the decision before continuing. Calls that bypass the integration are not covered. The event API and outbound webhooks deliver existing event evidence; they do not themselves intercept an agent action. Stateless policy evaluation does not automatically create an analytics event.

### Does local agent visibility mean every tool action is controlled?

No. Seeing an agent, MCP configuration or local tool context is different from enforcing every action it can take. Local agent visibility is available in selected rollouts. Validate the specific application, request path and response you need rather than inferring action control from inventory.

### Where should human approval fit?

Use human approval where the consequences justify it, such as sending an external message, changing production data or committing funds. Give the reviewer the proposed action, its target and relevant context. This is an application design practice; Aona's evaluation APIs do not by themselves create approval queues, grant permissions or guarantee that a person reviewed the action.

## Bring your agent checkpoint.

Walk through the content, evaluation and response your integration needs.

[Book a demo](https://aona.ai/book-demo/)

[Review product options](https://aona.ai/product/compare/)

Canonical page: https://aona.ai/solutions/ai-agent-guardrails/