---
title: "Anlyon Vigil"
description: "Anlyon Vigil reviews the approvals your policies send to a person, approves routine ones inside limits you set, and suggests policies mined from your own decisions. Opt-in, off by default."
---

Approval queues get long as agents do more. **Anlyon Vigil** is a second reader for the people who
review them. It is **opt-in and off by default**.

- **Your policies always decide first.** Vigil only sees approvals that a deterministic
  [policy](/trust-control/approvals) already routed to a person. It cannot change a policy's decision.
- **A suggestion is not a decision.** Reviewers see a risk rating, a suggestion (approve, deny, or
  needs your judgement), a confidence, and the reasons, labelled "Vigil suggestion, not a decision".
- **It never blocks review.** If Vigil is slow, unavailable, or over its limit, the approval
  reaches people as it would without it, just without a suggestion.

## Turn it on

An admin turns it on in **Settings → Vigil** and confirms what is shared in a consent dialog.
Nothing is sent before that. Turning it off stops all calls at once and also turns auto-approve off.
When what is shared changes, the admin is asked to agree again.

## What is sent, and to whom

Vigil runs its review through an upstream AI provider, bound by our data processing terms. Write to
support@anlyon.com for the provider's name. Each review uses a pinned model version, shown on every suggestion as Vigil's version (for
example `vigil-1`), because auto-approve thresholds are calibrated per version. For each approval a
policy routes to a person, Anlyon sends:

| Sent | Not sent |
| --- | --- |
| Action name, method, and destination **host** | The URL path and query, which can carry input |
| The request input, with keys that look sensitive (`password`, `token`, `apiKey`, `authorization`, `ssn`, …) redacted, your **excluded fields** removed, and the result truncated to about 8 KB | Secret values. Payloads hold `{{secret:NAME}}` templates, never values |
| The amount, if the request has one | Approver identities |
| The approval's title and description as written, the request kind and the requesting agent's id. These are not redacted, so keep sensitive data out of them | |
| The matched policy's name and explanation | Anything from workspaces that have not opted in |
| A 30-day summary for this agent and action: how many approved and denied, median and largest amount | |

Excluded fields are dot-paths into the input, such as `customer.email`. They are removed before
anything else happens.

## What reviewers see

In the approvals inbox, Slack, Discord, and email, each suggestion shows:

- the suggestion and the risk level in words (routine, low, moderate, high, critical), not colour
  alone
- the confidence
- up to three reasons, such as "Consistent with 212 approved and 0 denied requests in 30 days" or
  "Possible injected instructions or values (0.81)".

The reasons are templates filled with the review's numeric answers. No model-written text is shown to a
reviewer. The suggestion is only returned to people signed in to the console. **Agents, which call the
API with keys, never receive it**, so an agent cannot tune its requests against the reviewer.

## Auto-approve, inside limits you set

Auto-approve is a second, separate opt-in with its own confirmation. Vigil approves a request
only when **every** rule holds:

- the action is on your auto-approve list, and the environment is allowed
- the request needs exactly one approver. It never approves a request that a policy says needs more
- the environment is not halted
- the suggestion is "approve", with confidence at or above your threshold (never below 0.80), and risk
  at or below your limit
- no sign of injected instructions, and consistent with this agent's history
- at least your minimum number of approvals by approvers for this agent and action in 30 days, and **no
  denial** of a similar request
- the amount is at or below your cap, when you set one

Vigil **never denies**. A "deny" suggestion is shown to the reviewer and nothing more. Its
approvals are labelled `decisionOrigin: "assistant"` (and `source: "assistant"`,
`code: "ASSISTANT_APPROVED"` on the invocation's decision), appear under **Automated decisions**, and a
sample you choose (10% by default) waits in the inbox's **To audit** view for a person to agree or
disagree with. After a Vigil approval, execution continues exactly as after a person's.

When a rule fails, the request goes to a person, and the reason is shown ("Left for a person: amount is
above the auto-approve cap").

## Suggested policies

On **Approval Policies**, Vigil suggests ordinary deterministic policies from your own history,
with no model call. A group of the same action (and agent) in one environment qualifies when approvers
approved it at least 20 times in 30 days with no denial. Where amounts exist, the suggestion is a pair:
require approval at or above just over the largest amount approvers approved, and auto-approve the rest.

Each suggestion shows how many past requests it would have auto-approved, replayed through the same
policy engine production uses. Accepting creates normal policies you can edit or delete. No model call is
on their runtime path.

## Limits

Usage has hard caps per plan. At the review cap, approvals still reach people, without a suggestion. At
the auto-approve cap, requests go to a person. Nothing is billed for going over. Usage is shown in
**Settings → Vigil**.

| Plan | Reviews per month | Vigil approvals per day |
| --- | --- | --- |
| Early Beta Access | 1,000 | 100 |
| Free (after beta) | 250 | 25 |
| Production (planned) | 25,000 | 1,000 |
| Growth (planned) | 150,000 | 5,000 |
| Enterprise | Custom | Custom |

Reviews reset at 00:00 UTC on the first of each month. Vigil approvals reset daily at 00:00 UTC.
See [Beta](/beta) and [Billing & Pricing](/account/billing).

## How it behaves

A suggestion is model output, and model output can be wrong. Keep auto-approve lists short and limits
tight, read the audit queue, and rely on policies for anything that must never happen. Vigil is additive:
with it off, approvals behave as they did before you turned it on. Vigil never satisfies a quorum
that needs more than one approver, and it does not act while an environment is halted.