ARIA platform reference

Policy, approvals, and governed actions

ARIA's policy engine checks an agent's action before it happens. Each rule can allow the action, deny it, send it to a human for approval, or log it. If no rule applies, the action is denied.

Availability Included in the ARIA platform license. An administrator enables the policy engine.

Where policy is enforced

ARIA evaluates policy at the points where an agent can cause an effect:

Before a tool call. The tool does not run until the decision is allow.
Before each model round. Pre-model gating can stop a run before it spends tokens on a disallowed path.
Before output is released. Output checks can hold or block a result.
Inside workflows. Workflow tool steps are governed the same way as agent tool calls.
For external systems. Agents that run outside ARIA can submit an action for a decision (see Governing agents that run elsewhere).

If the policy service cannot be reached, governance fails closed by default, so an outage does not silently switch enforcement off.

What a rule can say

Rules combine conditions with AND/OR logic and are evaluated by priority.

Conditions

Comparisons and pattern matches on any field (equals, contains, in a list, greater than, regular expression)
Which tool or action type is being invoked
The risk class of the action
The classification level of the data or mission context
Data residency
The number of model iterations already used in the run
A simple pattern check for personal identifiers in output (SSN-style numbers and email addresses)
Whether the run has read content flagged as a suspected prompt-injection attempt, and where the content came from (prompt-injection defense is a separate ARIA control)
Whether a tool's target host is on an allow-list

Decisions

allow: The action proceeds.
deny: The run stops immediately.
require approval: The action waits in a human queue.
log only: Recorded, never blocks.

ARIA decision timeline for a request to email a vendor bank details form: the request, the proposed send_email tool call, a policy check marked Denied because a block-PII-export rule matched, output validation not reached, and a final outcome stating nothing was released. — ARIA product screenshotA policy denial stops the proposed tool call before execution.

Scopes and revisions

Rules can be scoped to specific agents, workflows, or user roles. A rule that names several scopes applies only where all of them match.

Policy revisions are immutable and each evaluation records a manifest with a SHA-256 hash, so a later review can tell which rules were in force at the time.

Human approvals gated by risk

ARIA assigns each action a risk class: low, medium, high, or critical.

Risk class	Default handling
Low, medium	No approval required
High	Approval required, routed to a designated approver role
Critical	Approval mandatory, routed to a designated approver role, and cannot be bypassed by turning off human-in-the-loop on the agent

Approvals appear in a queue with the requested action and its inputs.
Approvals that nobody acts on expire, and a background sweep closes the actions waiting behind them.
Organizations can require separation of duties so the person who requested an action cannot approve it.
Every approval or rejection is written to the audit log as an authority attestation.

ARIA pending approvals queue with one held release_vendor_payment action marked medium risk and escalated, listing its policy condition, designated approver, escalation contact, requester, and expiry, with Approve and Reject buttons. — ARIA product screenshotReview a held action with its policy, designated approver, and escalation status.

For higher-stakes runs, an optional plan approval step shows a human the exact tool calls and inputs before the first call is made.

Governing agents that run elsewhere

Many organizations run agents built on other frameworks. ARIA offers two ways to put them under the same policy:

Governed Actions API

An external orchestrator submits an action and receives allow, pending approval, or denied, along with a token to confirm execution afterward.

MCP gateway

An MCP-capable agent calls ARIA tools such as policy evaluation, action governance, status polling, and evidence export. ARIA records the decision and the outcome. The agent does the work in its own environment, so ARIA holds the evidence without executing anything itself.

The gateway is enabled by an administrator and uses ARIA API keys with explicit permissions for invoking the gateway and for executing tools. Every gateway call is audited.

Frequently asked questions

What happens if no policy rule matches?

The action is denied by default. Administrators can change this behavior, but the default is the safe one.

Does the policy engine detect prompt injection?

Detection is a separate control: ARIA scans content that agents read and marks the run when something looks like an injection attempt. The policy engine then decides what a marked run may do, for example holding any action that could change something for approval.

Can a human approval be skipped for critical actions?

Not by disabling human-in-the-loop on an agent. Critical-class actions require approval.

Back to the ARIA overview

Want to walk through a policy set against your environment?

Contact ADS