Anlyon Vigil
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 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 and Billing & Pricing.
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.