Two agents, one limit, one refused.

Live

Shared limits and receiptsfor AI agent actions

Anlyon enforces one shared allowance, approvals bound to the exact request, and provider-verified outcomes on the actions AI agents take through it, so adding agents or sessions never adds a way around the limit.

Free tier, no credit card.

Works on any API

Put any HTTP API your agent calls under a shared limit, an exact approval and a graded receipt. Declare it as an action over HTTPS. Stripe refunds, GitHub file updates and Resend email sends come with read-back built in, and a verify rule adds it to anything else.

01Any HTTP APIDeclare it as an action. A verify rule reads the result back.
02Stripe refundsRead-back built in
03GitHub file updatesRead-back built in
04Resend email sendsRead-back built in

The problem

The moment an agent stops recommending and starts doing, the question changes. Not what can it reason about, but what is it allowed to touch, and what happens at 3am when it touches the wrong thing.

You can't hand it your keys

The moment an agent can call your Stripe account, a stray sentence in a web page can too. One confused reply shouldn't hold your credentials.

Let it act safely

You can't cap the total, or stop it

A rule on each call does not add up. Ten agents that each stay under it can still change more than you meant to allow, and a new session starts the count again. When it goes wrong, stop can't mean redeploying.

Give them one limit

Nothing can say who did what

The refund went out. Nothing on your side can say which agent issued it, on which version of the action, or who approved it. When the question comes a month later, the answer is a guess.

Keep the record

The difference

Any agent, any system, one place the call is made. Your agent names the action. Anlyon checks the rules, waits for a person when it matters, holds the key, makes the call and keeps the record.

Execution

Let it act without handing over your keys

Define the call once. Your agent invokes it by name and passes input. Anlyon resolves the credentials at dispatch and makes the request, so the model gets a tool name and never a secret.

  • Tools it calls without the key
  • A vault with no read endpoint
  • Every call we made, and its outcome

Controls

Because we make the call, we can stop it

These are not a separate product bolted alongside your agent. They are what becomes possible once the side effect leaves from our side of the boundary instead of yours.

  • You say yes before it runs
  • Staging can't reach production
  • Pin a version, repoint to an earlier one
  • An operations cap per agent key

Setup

Up and running in minutes

Three steps from an empty file to an agent that acts through Anlyon. Nothing to host.

  • Get an API key
  • Connect
  • Define an action, then invoke it

Numbers

5 ms

median to start a run trace

0.3 ms

per span ingested, token & cost rollup included

18 ms

for a full approval round trip. The human is the latency, not us

$0

for traces, spans, and approvals, never metered on any plan

Guarantees

These are enforced in the API, not promised in a marketing deck. They apply to the actions routed through Anlyon. A tool your own code calls directly is not one of them.

Secrets are write-only

No read endpoint exists. Not a permission you could misconfigure: an endpoint we never built. An action references a secret by name and we resolve it at dispatch, against the destination it was bound to.

The agent can't approve itself

The credential that asked can never be the one that decides. No scope grants it and no policy relaxes it. If a decision shouldn't need a human at all, that's an auto-approve policy an admin wrote in advance, not the agent voting.

Blocked means blocked

A capped key gets a clear stop with an error your code can catch. Never a silent drop, never an overage.

Halted means halted

One switch stops the agent acting and stops anything leaving the environment. Even an already-approved call does not run. What you send still queues, so nothing is lost. A request an external server already accepted is not recalled.

An approval is an agreement to one specific call

The request is frozen when it is requested, and execution runs that snapshot. Editing the action while a human is deciding cannot change what their yes sends.

We won't retry your refund

Where a call may have landed but we cannot confirm it, we record an unknown outcome and tell you to reconcile, rather than quietly trying again. Nothing is lost and nothing is silently repeated.

Patterns

Not demos. Three real operations people are afraid to let an agent near, and the shape of letting it anyway.

See the recipes

A support agent that can issue refunds

It decides a refund is warranted. A human decides whether it happens, and the request to Stripe leaves from Anlyon.

  1. 01Define refund-order once, with the Stripe key referenced
  2. 02The agent invokes it by name with an order and an amount
  3. 03Policy parks anything over $100 for a teammate
  4. 04On approval, Anlyon makes the call and records the receipt

Any of those is an afternoon

The free tier covers all three. No credit card, and one command if you use Claude or Cursor.

Start building free

FAQ

The ones that decide whether this is worth an afternoon. Answered plainly, including the one where the answer is no.

Anything still unanswered is worth an email.

support@anlyon.com

Email us

Because then the credential is in the process the model is driving, and the only thing standing between a prompt injection and a refund is your own code remembering to check. Route the call through Anlyon and the key never leaves our side, policy runs on every invocation, a human can be required, the exact definition is pinned to a version, and one switch stops the environment dispatching anything further.

No. Anlyon is an API you call from code you already have. There is a TypeScript SDK and a Python SDK, or one command if you use Claude or Cursor. Replacing a direct HTTP call with an action invocation does not change how the rest of your agent is written.

Then use the local approval gate: an SDK wrapper that waits for a decision before your function runs. Be clear about what it is. Your process still executes the call with your credential, so it gives you the human decision and the record, not the credential isolation.

You can. It is a credential broker, a policy evaluator on the hot path, an approval queue with a dashboard behind it, versioned tool definitions, a limit shared across agents, and a record of what each call did. Most teams get three of those half-built. None of them is your product.

Yes. An impact limit caps the money your agents' governed actions move. Every agent, session and key in the environment draws from the same limit, reserved before dispatch. A new session or key does not get a new allowance. A limit can also count any unit you declare, such as emails or rows. Limits cover governed actions routed through Anlyon inside one environment, and an operator with the impact-limits:write scope can raise, lower or archive one.

Requests the cap covers stop with a 429 and the error code BUDGET_EXCEEDED. Never a silent drop, and never a surprise charge. The cap is on Anlyon operations, not on the money an approved action moves. During Early Beta Access nothing is charged at a limit. Paid plans arrive after the beta.

Your traces export as OpenTelemetry, so the audit record outlives any vendor, including this one. That is the part that is painful to lose, so it is the part we made portable.

No. Anlyon is a hosted service. There is no self-hosting today and no bring-your-own-vault. If that is a hard requirement, email support@anlyon.com and say why.

Pricing

Early Beta Access is free

Run real actions with no credit card and no automatic charges. Free within hard limits. Paid plans arrive after the beta.

See the limits
10,000action executions free each month
14days of traces kept
$0no credit card, no automatic charges

Free tier, no credit card. One command if you use Claude or Cursor.

$ claude mcp add anlyon -- npx -y @anlyonhq/mcp-server