Agent access a security review can sign

Before your agent acts in customers' accounts, a review asks three things: what can it reach, who decides what it does, and where is the proof. Anlyon answers each one in settings you can show, with the user's id on every call, approval and receipt.

Start buildingRead the docs

A few lines on your server, then connect a user.

  1. 1.What can it reach?Named actions only. Keys stay with Anlyon or in your own vault, and the agent never holds one.
  2. 2.Who decides?Your policies first, then the user it acts for or your team, by role in each environment.
  3. 3.Where is the proof?An audit record written in the same transaction as each change, streamed where your team reads it.

An agent that holds its own keys answers a security review with a promise. With Anlyon the keys, the decisions and the record sit where the call is made, so you answer with settings and evidence.

Less risk

The agent never holds a credential, and a person your directory removes loses the API keys they created.

Less cost

No token vault, role system, SSO wiring or audit pipeline to build and keep current for agent traffic.

Less effort

Each question maps to something a reviewer can open: a vault path, a role, a stream, an export.

What a reviewer can open and check. Each answer is a setting or a record.

Not a paragraph in a policy document. Each one names the user the agent acted for.

Every record carries the user

Your server names the user, with a key the model never sees. The model's tools have no user field, so a prompt can't switch users. Every call, approval and receipt carries that user's id, so you can filter by user and show a customer what their agent did.

  • A key can refuse any call that names no user
  • Each user's connections, calls and pending approvals on one page
  • Revoke a connection, or erase a user in one call
Read the guide

The key stays where you keep it

An agent names an action and Anlyon makes the call. A secret can point at a path in AWS Secrets Manager or HashiCorp Vault instead of holding a value: Anlyon reads it when it makes the call and never writes it to its own storage. Each user's own connection is held by Anlyon, never by the agent.

  • If your vault cannot produce the value, nothing is sent
  • Each secret is bound to the hosts it may be sent to, checked again at the call
  • An imported OpenAPI spec arrives with every write governed
Read about your own vault

The right approver, in each environment

A risky step can wait for the user it acts for, in your app, or for your team in the console and Slack. Approver and viewer join owner, admin and member, and a person's role can differ per environment: member in staging, approver in production. Sign-in comes from your identity provider.

  • The credential that asked can never decide its own request
  • Single sign-on over OIDC or SAML, required if you choose
  • SCIM removes a person, and revokes the API keys they created
Read about roles

The record commits with the change

Approval requests, every vote and decision, invocation outcomes, policy versions, halts, keys and members are written to the audit record in the same database transaction as the change. If the record cannot be written, the change does not happen.

  • Stream to a signed webhook, S3, Datadog or Splunk
  • Keep records 6 months on Starter and Pro, 12 on Team, custom on Enterprise
  • Export a date range as JSON or CSV. The export is recorded too
Read about the audit record

The evidence. One record shape, everywhere it goes.

Every sink, every export and the API carry the same record, with a stable id to deduplicate on. The evidence for a date range is one call.

Read about the audit record
audit.ts
// One record, as every sink and export carries it (abridged){  "schema": "anlyon.audit.v1",  "id": "aud_7c1e...",  "type": "approval.vote",  "category": "approval",  "actor": { "type": "user", "id": "usr_..." },  "resource": { "type": "approval", "id": "apr_..." },  "outcome": "approve",  "data": { "decision": "approve", "selfApproved": false,            "status": "approved", "requiredApprovals": 1 }}// The evidence for October, from the SDK (needs audit:read)const csv = await client.audit.export({  from: '2026-10-01', to: '2026-11-01', format: 'csv',});

The checklist. Everything a review usually asks for.

  • Keys that stay in your vault

    A secret can point at AWS Secrets Manager or HashiCorp Vault. Anlyon reads the value when it makes the call and does not store it. If the store cannot produce it, nothing is sent.

  • An imported API arrives governed

    Import an OpenAPI spec and every write comes in as a governed action. Anlyon suggests a risk class, an approval and an impact for each operation, and applies none of them until you accept it.

  • Approve in Slack, on the exact request

    The Slack message shows the request the approver is deciding, with Approve and Deny buttons. Nobody approves their own agent's request while another member can decide it. The only approver in an environment can, and the decision is marked self-approved.

  • Roles that change with the environment

    Approver and viewer join owner, admin and member, and a person's role can differ per environment: member in staging, approver in production. A member can halt an environment. Only an admin or the owner resumes it.

  • Sign in through your identity provider

    Single sign-on over OIDC or SAML, required for the workspace if you choose, and SCIM 2.0 provisioning built for what Okta and Entra ID send. A person the directory removes leaves the workspace, and the API keys they created there are revoked.

  • A record written with the change

    Approvals, votes, invocation outcomes, policy versions, halts, keys and members are recorded in the same database transaction as the change. Stream the records to a signed webhook, S3, Datadog or Splunk, set how long they are kept, and export JSON or CSV.

Single sign-on, SCIM, audit streaming, your own vault and roles per environment depend on your plan.

See pricing

Let your agent act for your users, safely.

A few lines of server code, then send a user a connect link. Nothing to host.

Start buildingRead the docs

$ claude mcp add --transport http anlyon https://api.anlyon.com/mcp