Before content leaves
Send text or supported files to an Aona evaluation at a checkpoint you control. Your integration applies the returned verdict or redaction before the next call.
Explore the API routeFor agents and applications
AI guardrails for agents.
An agent can disclose sensitive data or take an unintended action. Put Aona content checks at checkpoints you control; your application enforces the result, permissions and approvals.
See the two boundaries Application checkpointBEFORE CONTINUING
01 / AGENT PROPOSESCustomer data
Send a reply with customer account SAMPLE-104.
02 / AONA CONTENT CHECKReject original payload
The illustrative policy flags the account reference in submitted text.
03 / YOUR APPLICATIONHold the request
The integration stops the original call or uses a validated redaction path.
In this example, the original customer detail is held at the integrated checkpoint.
Fictional content evaluation. Your integration chooses the checkpoint and applies the result.
Two decisions to keep distinct
Check the data. Control the action.
An agent may expose information and may ask another system to do something. Both moments need a real enforcement point.
Before a tool runs
Check the agent identity, tool, target and limit in your application. Add human approval when consequences justify it. A content verdict does not authorize the action.
See the review stepApplication-owned oversight
Put the action in front of its owner.
A reviewer needs the proposed action, target and evidence before the agent changes another system.
Your application owns tool permissions, approval routing and execution.
What a meaningful review includes
- The specific tool and target, not only the agent's summary.
- The source data and proposed change before approval.
- An actual way to stop the action and record the outcome.
Illustrative application reviewBEFORE TOOL EXECUTION
Agent requests an AUD 60 refund for a fictional order.
- Target
- Order SAMPLE-104
- Tool
- Issue refund
- Evidence
- Source ticket and order record
Awaiting permission and reviewer decision
Record what the integration actually did.
An Aona verdict describes a content evaluation. It does not prove a call stopped or a person approved an action. Keep the application decision and relevant evidence together.
Understand event evidenceTake 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.
- What is covered?
- Who enforces the decision?
- What evidence records the result?
Open all seven evaluation questions
- 01
Which user, app, agent and input path does this control cover?
- 02
What risk and policy does the check address?
- 03
What happens when the check allows, rejects, times out or fails?
- 04
Who applies the decision, and can another path bypass it?
- 05
Where is data processed, stored and retained?
- 06
What evidence records the action actually taken?
- 07
Which allowed, prohibited and ambiguous examples will we test?
Keep going
Connect the control to the work.
Review a specific framework without treating one guardrail as proof of compliance.
Questions
Your questions, answered.
What are AI guardrails for agents?
Agent guardrails address what an agent sends and what it can do. An agent might disclose customer information to a model or tool, follow an instruction in untrusted content, or attempt a consequential action outside its intended scope. Content checks, application permissions and meaningful review address different parts of that risk.
How can Aona check data an agent sends?
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.
Does Aona stop an agent action by itself?
No. An evaluation API returns a content result to the caller. Your application must enforce the result before continuing and own tool permissions, approval and execution. Calls that bypass the integration are outside that checkpoint. Event APIs and webhooks deliver existing evidence; 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.
Aona guardrails
Bring your agent checkpoint.
Walk through the content, evaluation and response your integration needs.