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 OAuth 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.

​

Crypto and card rails

An agent can use both payment rails; each individual spend goes through one of them explicitly, picked by the agent at call time:

​

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, “weather data” 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 — budget-cap overruns on the crypto side and every linked-card purchase alike.

​

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, across both rails — no approval can override it. 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. Anchorage can also pause an agent — for example during an account freeze — which has the same immediate effect on tool calls and sessions. A paused agent shows as Paused in the web UI; unlike a revoke, pausing doesn’t touch the agent’s identity, so once Anchorage lifts the pause the same agent reconnects with a fresh OAuth consent.