Agents

An agent is a non-human principal that holds credentials to call Anchorage Agentic Banking’s MCP tools on behalf of a user. Agents are first-class: each has its own identity, audit trail, and scoped permission to draw against budgets.

​

Authorization model

An agent acts under exactly one user-org pair at a time. When the agent calls a tool, Anchorage Agentic Banking resolves three things:

1. Who is calling — the agent’s credential identifies the agent.
2. For whom — the agent is scoped to one user-org membership.
3. Against what — the agent has a list of budgets it may draw on.

The list of allowed budgets is returned inline when the agent introspects its identity, so an agent gets everything it needs in one call. An agent authenticates with either an OAuth session or an API key. A client gets an OAuth session by running the browser consent flow; an org admin or the agent’s user mints an API key on the agent’s page in the web UI. Both credentials authenticate as the same agent acting for the same user, so they reach the same tools under the same budget scoping. An API key never expires and authenticates only while its agent is usable. Minting is refused once an agent has ten active API keys. Revoked keys don’t count against that limit, so revoking one frees a slot for a new one. Minting is also rate limited per user: you can mint many keys in quick succession, and once that allowance is spent, further mints are refused for a short while.

​

How an agent pays

An agent pays with crypto payments. Each spend is authorized by the agent’s budget under standing consent and settles on-chain from the org account’s USD balance.

​

Finding merchants to pay

An agent can search the merchants and services it is cleared to pay by plain description of what it needs, then pull the call detail for the one it picks:

• Search by need — the agent describes what it is looking for (for example, “web search” or “image generation”) and gets back the matching merchant services. This searches only merchants that have cleared review, limited to the services payable on the agent’s own network (mainnet or testnet), so every result is one the agent can actually pay. Services from the same merchant are grouped together. Each result carries:
  • a name, a short description, and tags
  • the merchant it belongs to, and whether that merchant runs the service itself or resells another provider’s
  • the payment methods the service accepts
  so the agent can tell up front which services it is able to pay and who it is dealing with.
• Drill into a service — given a service from that search, the agent pulls its payable endpoints — the URLs to pay and the payment methods they accept — plus pointers to the merchant’s API and documentation, so it has what it needs to make the call.

Search returns a focused, ranked set rather than the whole directory, so an agent can go from a goal to a payable endpoint in two steps.

​

Where agent activity appears

Every payment and approval an agent initiates shows up in the Anchorage Agentic Banking web UI under the user’s history, tagged with the agent’s name, including payments approved past a budget cap.

​

Request limits

A few steps around connecting and paying are rate-limited:

• Registering an MCP client and revoking a token are rate-limited: repeated registration or revocation attempts are refused once they arrive faster than the limit allows. A normal connect — one registration, one consent — stays well inside the limit. A request that hits this limit comes back as a standard HTTP 429 with a Retry-After header and the X-RateLimit-Limit, X-RateLimit-Remaining, and X-RateLimit-Reset headers, so a client can wait exactly as long as the response asks and then retry.
• The first time an agent reaches a payment endpoint URL nobody has registered yet counts against that agent’s limit. Once an endpoint URL is registered — whether or not a payment on it completes — later calls to that URL are not limited. A new path under a merchant the agent already knows still counts as first contact if that exact URL hasn’t been registered before. A payment tool call that hits this limit returns an error naming the limit; retry shortly.
• Every request body is capped at 2 MiB. A request that declares a body larger than that is refused with a 413 before it reaches the requested action — unless another protection, such as cross-origin request blocking, refuses it first. A request sent without a declared size — for example, chunked transfer encoding — that turns out to exceed the cap is refused once the cap is hit while reading it.

​

Stopping a runaway agent

$1,000 per UTC day, per agent — no approval can override it. $250 per single payment — also beyond any approval. A payment above that amount is declined outright, and it stays declined however much room the agent’s budget has left. Approving a payment lets that one payment proceed past the agent’s budget cap, and later payments are still measured against the same cap; the per-payment limit sits above budgets and holds either way. The per-payment limit is the smaller of two limits Anchorage sets independently: a per-payment cap, $250 today, and a travel-rule block of$2,099 that no agent payment may exceed whatever the cap is raised to. Today the $250 cap is the smaller of the two, so$250 is the limit an agent meets. Raising the cap raises the limit only as far as $2,099. The two limits are separate controls, and both apply to every payment: the daily cap bounds what an agent spends across a UTC day, the per-payment limit bounds any one payment. Anchorage checks each request against both, and the tighter one for that payment is what declines it. The daily cap is checked per request against the agent’s running total for the day, so the two controls bind in different places: a $600 payment is declined by the per-payment limit even on an agent that has spent nothing that day, and a$200 payment is declined by the daily cap once that day’s total is already at $900. To spend beyond what the two limits allow, a person pays it directly. Revoke the agent’s identity from the web UI to stop it instantly yourself, with no grace window: its credentials are permanently invalidated, every session is revoked, and tool calls fail right away. This is permanent — the revoked agent can never complete OAuth consent again, so reconnecting means creating a new agent and consenting for that one. The agents list opens on the Active tab. Use the Inactive tab above the list to see paused and deactivated agents, or the All tab to see every agent; each tab shows how many agents it covers. Each agent’s status badge reads Paused or Deactivated, so you can tell them apart on any tab. A deactivated agent’s page, and every payment and transaction that names it, stay available. Pause the agent from its page in the web UI to stop it with one action while keeping its identity. The agent’s user or an org admin can pause it, and the pause has the same immediate effect on tool calls and sessions as a revoke. A paused agent shows as Paused in the web UI. The agent’s user or an org admin resumes it from the same page, and the agent then reconnects with a fresh OAuth consent. Anchorage can also pause an agent, for example during an account freeze, with the same effect. Only Anchorage lifts a pause it placed, including one placed on an agent you had already paused. The agent’s page shows the reason for the pause and offers no resume button. Both controls reach the agent’s API keys too. A revoked agent’s keys stop working immediately and permanently. A paused agent’s keys stop working at the pause and are revoked outright, so a client that resumes after the pause is lifted needs a freshly minted key. Removing a member from your organization revokes the API keys of every agent that acts for that member, and stops those agents. Only Anchorage resumes an agent stopped this way, including one you had already paused.