The execution model
Your agent names an action and Anlyon makes the production call. What that changes, and what it makes enforceable.
Anlyon puts shared limits and receipts on the actions AI agents take through it. Your agent does not perform the production operation. It names an action and passes input, and Anlyon performs the operation on its behalf.
Everything else in these docs follows from that one move, so it is worth being precise about it before anything else.
Without Anlyon
your agent -> an API credential in your process -> production APIThe model is driving a process that holds a live key. Whatever sits between a stray sentence in a scraped web page and a real refund is code you wrote and have to remember to run on every path. There is nothing outside your process that can refuse, pause, cap or attribute the call, because by the time anything could look at it the request has already left.
With Anlyon
your agent -> a named action -> Anlyon -> production APIYou define the call once, referencing credentials rather than pasting them. From then on your agent’s side of the boundary contains no URL, no header and no key:
await anlyon.actions.invoke('refund-order', { charge: 'ch_3P9x', amount: 12000 });Anlyon owns what happens next.
What happens between those two arrows
Every invocation passes the same checks, in this order. Nothing here is optional per call. What varies is whether a given stage has anything to do.
Check the caller's authority
Invoking needs actions:invoke. Referencing a secret is checked when the action is saved, and needs secrets:read, because a reference is a use. No key receives secrets:read by default.
Reserve budget
The calling key’s monthly cap on action invocations is checked and reserved. Past the cap the invocation stops with 429 BUDGET_EXCEEDED.
Resolve the action and its version
The name resolves to an action in the calling key’s environment. If the call is attributed to a run whose agent pins a version of that action, the pinned definition runs. Otherwise the current definition runs. The response reports which one actually executed.
Evaluate policy
Approval policies are evaluated on every invocation, so a policy can tighten the gate and not only relax it. A policy scoped to an identity the request does not carry is treated as indeterminate and requires approval, so withholding attribution is not a way around it.
Park for a human, if required
A gated invocation returns 202 with pendingApproval: true and an approval id. The request that the approver reviews is frozen at this point, so editing the action while they decide cannot change what their yes sends.
Resolve credentials and build the request
Immediately before dispatch, Anlyon re-checks that the environment is not halted, decrypts the referenced secrets, interpolates them into the frozen definition, re-validates the destination, and sends the request. A workspace secret is decrypted here, at dispatch. The read-back of a governed action resolves it again under the same bindings.
Record the outcome
The invocation records the response status, the action version that ran, and the run and span it belongs to. Where the outcome cannot be confirmed it says so rather than guessing. A governed action also returns a receipt grade. See Receipts and grades.
Why this is the interesting part
The controls Anlyon offers are not a separate product sitting alongside your agent. They are consequences of owning the call:
Credentials the model never sees
The key is resolved at dispatch, inside Anlyon, from a vault with no read endpoint. It is never in the context the model reads.
Approvals that mean something
Anlyon can hold the call because Anlyon is the one making it. A wrapper around your own function can only ask your code to wait.
A stop control
Halting stops new dispatch at the point requests leave. You cannot halt a request that never passed through you.
Pinned definitions and rollback
An agent version pins the exact action definitions it shipped with, so rolling back restores behaviour and not just a pointer. It does not undo a request already dispatched.
Idempotency
A retried request replays the original outcome rather than performing the operation twice.
Attribution
An invocation records the action version and the approval that released it. Pass a runId and it also names the agent and run.
The boundary of these claims
All of the above applies to actions routed through Anlyon’s hosted executor. A tool your own code calls directly, with a credential your own process holds, is not routed through Anlyon and is not governed by it.
The SDK also ships a local approval gate, approvals.gate(), which wraps one of your own functions and waits for a decision before it runs. It is genuinely useful when a call cannot move, and it is a different thing: your process still executes the call with your credential, so it gives you the human decision and the record, not credential isolation, and Anlyon cannot attest that your function ran or did not. See Local approval gates.
Where to go next
Actions
Define a production call once and invoke it by name.
Secrets
A write-only vault, referenced from an action rather than read.
Idempotency and retries
Safe replays, and why an ambiguous side effect is not retried for you.
Receipts and grades
What is recorded about every call Anlyon made for you, and the grade a governed action returns.
Governed effects
Three adapters and declared actions, side by side, and what happens when a response is lost.
Bound approvals
An approval bound to a digest of the exact request, recomputed before dispatch.
Impact limits
Shared caps on money, resource changes or a unit you declare, reserved before dispatch.