An agent that only answers questions needs a model. An agent that refunds an order, merges a file or emails a customer needs something else: somebody has to decide what it can reach, who signs off on what it does, and how anyone proves afterwards what happened.
That is the work we have been doing at AnlyonHQ, and today it ships. Everything below is live on Anlyon's hosted service and included on every plan for as long as the beta runs.
It builds on how Anlyon already works. Your agent names an action and passes input. Anlyon holds the credential, checks the rules, waits for a person when the rules say so, makes the call and returns a receipt with a grade. Because Anlyon makes the call, it can also answer the three questions a security review asks.
What your agents can reach
Keys that stay in your own vault
A secret in Anlyon can now point at a path in AWS Secrets Manager or HashiCorp Vault (KV version 2) instead of holding a value.
Say your Stripe key lives in AWS Secrets Manager under payments/stripe. You add the store to the production environment once, then name the secret:
await client.secrets.putExternal('STRIPE_KEY', {
external: { store: 'prod-vault', path: 'payments/stripe', key: 'apiKey' },
allowedHosts: ['api.stripe.com'],
allowedPlacements: ['header'],
});
When the agent invokes refund-order, Anlyon reads the key from your store, sends the request to api.stripe.com and drops the value. It is held in the API process's memory for at most the store's cache time, 30 seconds by default, and never written to Anlyon's storage. If the store does not answer, the refund is refused with credential_unavailable before anything is sent to Stripe. Secrets read from your own vault.
An imported API that arrives governed
Import an OpenAPI 3 spec and every write comes in as a governed action: counted against a shared limit, with a receipt. What is new is that Anlyon now reads each operation and suggests how to treat it.
Import a billing API with forty operations and the dry run tells you, per operation, a risk class (read, write, irreversible or destructive), whether to require approval, and an impact. DELETE /customers/{id} is suggested as destructive, with approval. POST /v1/refunds carries an integer amount and a currency, so it is suggested as irreversible, with a money impact counted from input.amount, and a note to choose the currency first. A DELETE is never suggested below destructive, whatever the spec says about itself.
The suggestion is read from the spec's methods, words, fields and vendor extensions. No model is called and the same spec gives the same answer. Nothing is applied until you accept it for that operation. Importing from OpenAPI.
No third party holds a sign-in token
When an integration signs in with OAuth, Anlyon now runs the consent flow on its own API, keeps the token encrypted in its own database under a key separate from the vault's, and refreshes it itself, one refresh at a time. Before, a separate connector service held those tokens. Now nobody else does, and the agent still never sees one. The integrations listed today connect with an API key, and sign-in integrations use this path as they are added. Connected accounts.
Who decides what they do
Approve in Slack, on the exact request
A support agent asks to refund $240 on order ord_8812 in production. The request posts to #prod-approvals. The message names the environment first, flagged as production, then the action, the amount, how many approvals it needs, when it expires, and the expected draw on the refund limit. It has two buttons.
Priya clicks Approve. Slack asks her to confirm, naming production. Anlyon maps her Slack account to her Anlyon membership, either because she linked it with Sign in with Slack or because Slack's confirmed email for her matches her verified Anlyon email, checks that her role in production allows deciding, records the vote and runs the refund. The message updates in place to say who approved it.
The support agent runs on an API key Sam created, so Sam cannot approve that request while Priya can. In a workspace with one approver, that person can decide their own agent's request, and the decision is marked self-approved in Slack, in the console and in the audit record. When the approval is bound to a preview, Approve is offered only while that preview matches its binding and has not expired. Deny is always there. Email, Discord and webhooks still notify; the decision happens with the buttons on a Slack request, in the console or through the API. Slack approvals.
Roles that change with the environment
Two roles join owner, admin and member. An approver reads everything and decides approvals. A viewer reads everything and changes nothing.
A role can now differ per environment. Sam is a member in staging, where he builds actions, and an approver in production, where he only signs off. Lee from security is a viewer everywhere. Deciding an approval checks the role in the approval's own environment, so Sam's staging role does not decide anything in production.
Halting and resuming are not symmetric on purpose. A member can halt an environment, because stopping is the safe direction. Only an admin or the owner can resume it. Roles.
Sign in through your identity provider
A workspace admin connects an OIDC or SAML identity provider and verifies the email domains it covers with a DNS record. The owner can then require it: every member signs in through the provider. The owner keeps a password sign-in, so a misconfigured provider cannot lock the workspace out.
SCIM 2.0 provisioning, built for the requests Okta and Entra ID send, keeps the workspace in step with your directory. Directory groups map to roles. When the directory deactivates Lee, Lee leaves that workspace at once, and the API keys Lee created there are revoked. Lee's account and other workspaces are untouched. Single sign-on and SCIM.
Proof of what happened
A record written with the change
Priya's vote is an approval.vote record. It was written in the same database transaction as the vote itself, and so is every approval request, decision, invocation outcome, policy version, halt and resume, key change and member change. If the record cannot be written, the change does not happen. We chose a complete trail over the availability of the change.
Every record has one versioned shape, anlyon.audit.v1, and an id that stays the same through every retry, sink and export, so a receiver deduplicates on it. A workspace admin streams the records to a signed HTTPS webhook, an S3-compatible bucket, Datadog or Splunk, and sets how long they are kept, from 30 to 3,650 days or indefinitely. A batch a destination refuses is kept and can be sent again.
When an auditor asks for October:
const csv = await client.audit.export({ from: '2026-10-01', to: '2026-11-01', format: 'csv' });
That needs a key with the audit:read scope, which no key gets by default, and taking the export is itself recorded. The Python SDK has the same calls as audit.list_events, audit.export and audit.schema. Audit records.
A calmer console
The console has a new layout: a high-contrast sidebar, the work in one inset panel, and softer cards. The approvals inbox, roles, single sign-on, audit sinks and secret stores all live there.
anlyon.dev: what an MCP server can do
Most agents now reach tools through MCP servers, and most teams add a server without reading every tool it exposes. anlyon.dev is an index that does that reading. It reads servers from the official MCP Registry, and as of October 22, 2026 it holds:
- more than 14,500 MCP servers, indexed
- more than 184,000 tools, each classified by what it does
- more than 11,000 tools that can delete or cancel something
- more than 5,000 tools whose effect can't be undone
- more than 2,000 Agent Skills, more than 1,100 of them from official repositories
Paste your MCP config into the audit to see every tool your agent can call, sorted by what it does. Pin a lockfile that fails CI when a server changes its tools, and follow the change feed for the servers you use. The checks are deterministic rules over tool definitions, not a model, and each scan is point-in-time. anlyon.dev reads a remote server's tool list anonymously, with no credentials, and never calls a tool. A clean result is a reading of the definitions, not a safety guarantee.
What it costs
On Anlyon's hosted service, single sign-on, SCIM, roles per environment, audit streaming and export, secrets from your own vault and Slack approvals are included on every plan for as long as the beta runs. There is nothing to unlock. Pricing.
Start
Create a workspace at console.anlyon.com, or read the docs. Every contract change behind this launch is in the changelog with a migration note, and everything above is on one page at /access.