You can now pause an agent from its page in the web UI. The agent’s user or
an org admin pauses it with one action, which stops its tool calls and
sessions right away and revokes its API keys. The same people can resume a
pause they placed. A pause Anchorage places stays until Anchorage lifts it,
and an account freeze or removing the agent’s user from your organization
takes over a pause you placed the same way.
See Stopping a runaway agent.
The spend bars on an agent’s page now show how much of the budget is left
and the share used, for example “$1.85 remaining · 8% used”. If the cap was
lowered below what was already used, the meter shows how far over it is. See
What the org member sees.
Org admins can select the held amount beside the USD balance, on the
Payments page or the organization’s Budgets tab, to open Held
funds. It lists each hold that makes up that amount: how much, why it is
held, the payment or deposit history it belongs to, the agent that started
it, and when it was placed. An account with more than 500 holds shows only
the total. See Accounts.
Compliance screening of incoming stablecoin deposits was strengthened. A
deposit that does not pass screening is held or blocked and shows its
screening status in Deposit History.
The inference endpoint creates messages in Anthropic’s Messages API format at
POST /v1/messages. Point Claude Code at it with ANTHROPIC_BASE_URL and the
agent’s API key, or point an Anthropic SDK’s message-creation calls at it the
same way. Requests pass through unchanged, including cache_control blocks,
the provider’s answer and streamed events come back as sent, and each message
is billed from the agent’s budget like a chat completion. Errors use
Anthropic’s error shape. See Call a model.When a merchant offers both a metered option and a fixed-price option, an
agent now pays the metered one for paid URLs and non-streamed chat
completions. The payment reserves the merchant’s per-request maximum, charges
the amount the merchant reports, and releases the rest, so a charge can be
anywhere up to that maximum. A cost estimate for such a merchant shows the
maximum. The budget must cover the maximum: a metered payment whose maximum
exceeds the remaining budget is declined and does not wait for approval.
A maximum above the supported size, streamed chat completions, and image,
video, and audio generation use the fixed-price option. See Crypto payments.
An agent’s transaction list shows only the payments that agent made, so one
agent can no longer read another agent’s purchases. You see all of your
agents’ payments on the Payments page. See
Who can see a payment.
A payment to a merchant that charges by metered usage now shows the amount
the merchant charged, in the payments list, payment details, and the
agent’s transaction list. It used to show the per-request maximum that was
held, though your balance and budgets were always charged the actual amount.
A payment request never follows a redirect to a different address (scheme,
host, or port) than the one it is sent to. When a merchant redirects a paid
request to a different address, the payment was already delivered and may
still settle, so its reserved funds stay held; don’t pay again under a new
idempotency key. Redirects within the same address still work.
An agent can now pay merchants that charge per request by metered usage. Each request is held at the merchant’s per-request maximum and charged
the actual amount the merchant reports, and the rest is released. See
Crypto payments.
You can now add Anchorage Agentic Banking to ChatGPT as a custom MCP server
and sign in over OAuth. This needs a paid ChatGPT plan, on chatgpt.com. The
Agents page has a ChatGPT tab with the steps, the name, and the server
URL. See
Per-client setup.
The agents list now 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. See
Stopping a runaway agent.
A plain org member now opens a payment’s detail page only when one of their
own agents made it. Another member’s payment opens as a not-found page,
including from a direct link, the same way it’s already left out of their
Payments page. Org admins open any payment in the org as before. See
Who can see a payment.
An agent can now generate audio on
https://inference.agentic.anchorage.com/v1,
paying from its budget with the same API key it uses for chat completions:
speech at POST /v1/audio/speech, sound effects at
POST /v1/audio/sound-effects, and music at POST /v1/audio/generations.
Speech and sound effects usually return the audio directly; music
usually returns a job to poll for the result. The Inference page’s Audio tab names
the route each model is called on. See
Generate speech, sound effects, or music.A call to
POST /v1/chat/completions, streamed or not, now settles on a
different chain from image and video generation, so its transaction shows
that chain. Billing, approvals, and the budget that pays for the call are
unchanged. Crypto payments lists which chain each
kind of inference call settles on.Retrying an inference or generation request with the
Idempotency-Key of a
request you already paid for now reaches that payment, even if the agent’s
budget was removed since. A request with no key, or a new key, still needs a
budget. See Failure modes.An organization with mainnet access now admits a new member only when
Anchorage has verified their identity. Anchorage sends invitations into such
an organization with the identity attached. An org admin’s own invitation
there, or an add of a member with no verified identity, is refused with a
message saying so.
Accepting an invitation is refused the same way when no verified identity is
linked, and the invitation stays open until Anchorage links one. Joining an
organization open to your email domain is refused too, so ask its admin to
have Anchorage invite you. See the Quickstart.
A new guide walks through connecting an agent whose harness, such as OpenClaw
or Hermes, runs on a server or a Mac mini with no browser: mint an agent API
key on any device with a browser, give it to the harness, point the harness at
the MCP endpoint, and make the first paid call. It also covers when a person
can approve the connection from another device instead. See
Connect your harness.
A retry that reuses an earlier payment is now marked as a replay only when
it returns the first request’s recorded result. When the provider has to be
asked again, the response reports the reused payment without the replay
mark. See
Managing idempotency keys.
Connecting a new agent through the browser consent screen or a pairing code
now works when your org’s budget allows only specific merchants. The new
agent can pay the merchants the org budget allows when you connect it. If a connection
failed for this reason, connect the agent again. See
Budgets.
A plain org member now sees each other member’s name and role on the member
list, and org admins see every member’s email address and budget use as
before. A plain member’s own email and budget use stay on their profile page.
Another member’s profile page is available to org admins only. See
What the org member sees.
An agent can now generate videos at
POST /v1/videos/generations on
https://inference.agentic.anchorage.com/v1, paying from its budget with the
same API key it uses for chat completions. A video that takes longer than
the request returns a job id and a URL to poll for the result. A
generation is one payment, however many times you poll it. See
Generate an image or video.An agent can now generate images at
POST /v1/images/generations on
https://inference.agentic.anchorage.com/v1, paying from its budget with the
same API key it uses for chat completions. A quick generation returns the
images directly; a longer one returns a job id and a URL to poll for the
result. A generation is one payment, however many times you poll it. See
Generate an image or video.POST /v1/chat/completions now accepts "stream": true and relays the
completion as the provider produces it, so an OpenAI-compatible SDK’s
streaming mode works unchanged. A streamed call is billed and approved the
same way as any other call. The charge for the full completion is submitted
when the stream starts and stays pending until the payment settles on chain.
See Streaming.When the typed-judgment provider is slow to answer and many requests to
POST /v1/decide are already waiting on it, a new request now gets the same 429 rate-limit error
as the endpoint’s other rate limits, straight away, instead of waiting on the
slow provider. Retry it shortly. See
Typed judgments.The Inference page now groups models into Text, Image, Video, Audio, and
Other tabs, each priced in the unit the model is billed in: USD per 1M tokens
with the context window and maximum output for text models, per image, per
second with length limits, or per 1K characters, per track, or per generation
with input and duration limits. Text, image, and video models are callable
through the inference endpoint today; the audio and other tabs say their
models are listed for pricing only. A model priced by input length shows
each tier’s price under the base price with the threshold it applies from, a
free model is marked Free, every published price shows as published, and each
row’s identifier has a copy button. A How to connect card walks through
the API key, the
base_url, and the auth header, with curl, Python, and
TypeScript snippets naming a text model from the list; Connect your
harness shows the block for Hermes or OpenClaw. The Agents page and
each agent’s page link there with Set up inference, and signed-in users
reach the page from the new Inference entry in the sidebar.
GET /v1/models now also carries each model’s display name, context window,
maximum output, categories, billing mode, and availability, plus its kind,
whether it is callable and at which endpoint path, whether it is free, and
which pricing keys are limits.
See Choose a model.Linked cards are no longer available. You can’t link a card, and agents can’t
request card purchases. Agents pay with crypto from their budgets; see
Crypto payments.
An agent’s API key now works against
POST /v1/decide on
https://inference.agentic.anchorage.com/v1. Send a piece of text and one or
more named yes/no, multiple-choice, or scored questions, and get one answer
per question. It’s free and doesn’t draw on the agent’s budget. See
Typed judgments and
Call a model.Fix
Paid inference forwards a provider's real error after payment and accepts a wider range of idempotency keys
POST /v1/chat/completions now forwards the inference provider’s own status
and body for a complete 4xx/5xx rejection after payment, honoring a
Retry-After header on the provider’s own rate limit, instead of a generic
failure. A refusal before the request reaches this endpoint (a
compliance check on the connection) now returns this endpoint’s own JSON
error shape instead of plain text, so an OpenAI-compatible client can parse
it like any other error. Idempotency-Key now accepts up to 255 characters
rather than 255 bytes, so a key using multi-byte characters is no longer
rejected as too long while still reading well under the limit.A crypto payment’s detail page now shows the HTTP method (GET or POST) used
for the paid request, alongside the payment’s other details.
An agent’s API key works against
POST /v1/chat/completions, an
OpenAI-compatible completions endpoint. Point any OpenAI-compatible client
at https://inference.agentic.anchorage.com/v1, and each call bills the agent’s
budget the same way a crypto payment does. The Agents page now shows
this base_url alongside the existing MCP connection card. See
Paid inference and
Call a model.Merchant names are now cleaned when they are created or edited. Hidden
formatting characters — the kind a website can slip into a payment request to
make text render oddly, or to display a name in the wrong order — are removed,
and a very long display name is shortened to 200 characters. A business name
you submit for compliance screening is not shortened: a name longer than 200
characters is rejected so the name screened stays the name you entered. If
nothing is left after cleaning, creating the merchant fails, and an edit to an
existing merchant is rejected with its current name unchanged. Ordinary names,
including accented and non-Latin ones, are unchanged.
When card verification fails, you return to the cards page with a message.
Whether it fails or you close the verification window, the card stays listed
as Pending, ready to verify again from its Pending status or to unlink
with Remove. If a verification
attempt left you on a “Page not found” screen, open the cards page and
select the card’s Pending status to finish.
You can now see a received payment’s screening status on the payment itself,
in addition to the payments page. The label is the same one shown on the
payments page: Screened, Under review, Blocked on screening,
Not screened, or Screening status unavailable.
Start at llms.txt for the live service
catalog, authenticated tools, and public API description. Use this index in
place of the retired enrollment and payment walkthrough.
The Agents page has a Replit tab. It gives you a one-click Add to
Replit link and the display name and server URL to paste into Replit’s
Add MCP server dialog. After Test & save, Replit opens the usual
consent screen where you pick the agent this connection acts as. The public
merchant catalog page has the same tab for its no-sign-in endpoint.
Payments you receive now show their compliance screening status next to the
transaction: Screened, Under review, Blocked on screening, Not
screened, or Screening status unavailable. Payments you send are
unchanged.
Clients that honor tool safety hints now prompt for approval before a cost
estimate, the same way they do before a payment. Previewing what a paid URL
would cost issues the same request — method, headers, and body — that paying
for it would, before any money moves, so a preview against an endpoint that
writes or deletes was never a read in the way its tool safety hint claimed.
See Cost estimates.
The per-payment limit on agent spend is now the smaller of two limits
Anchorage sets independently: a per-payment cap, and a travel-rule block of
$2,099 that no agent payment may exceed whatever the cap is raised to.Nothing changes for you today: the cap is $250, so the limit an agent
meets on the crypto rail and the linked-card rail alike is still $250. A
payment above it is declined outright, whatever room the agent’s budget has
left, and no approval lifts it. What changed is the headroom: raising the
cap now raises the limit as far as $2,099 without a further change.The separate $1,000-per-UTC-day cap per agent is unchanged. See
Stopping a runaway agent.
Retrieving credentials for an approved linked-card purchase now checks that the
card is still usable. If the card was paused, revoked, or expired after the
approval — or its printed expiration date has passed — the retrieval is refused
with a plain-language reason and no credential is minted. Approvals themselves
are unchanged, and a purchase on an active, unexpired card behaves exactly as
before.
An agent reads a payment’s approval status and details only for the payments it
created. A payment another agent created is not visible to it, even when both
agents belong to the same organization. This does not change what people see:
org admins and members keep the same view of payments they had before.
Minting is refused once an agent has ten active API keys. Revoking a key frees
a slot, so you can mint a new one once you’re at the limit. Minting is also
rate limited: you can mint many keys in quick succession, and once that
allowance is spent, further mints are refused for a short while. Either
refusal shows a plain-language reason on the agent’s page.
An agent can now authenticate with an API key, so a client that runs with no
browser connects without an OAuth consent. An org admin, or the user the agent
acts for, mints a key on the agent’s page and the client sends it to the MCP
endpoint as a bearer token. An agent can hold several keys, one per client or
workflow.The key appears once, at mint. Copy it then; if you lose it, mint another.
Keys never expire, and revoking one from the same page takes effect
immediately.Linked-card operations still run under an OAuth session, because a card
purchase returns live card credentials and depends on a person approving that
purchase in the browser.A key stops working with the agent it belongs to. Revoking or pausing the agent
stops its keys immediately, and removing from your organization the member an
agent acts for revokes that agent’s keys.
When a card’s network can’t set up agentic payments for cards from that
card’s issuer, the error on the cards settings page now names the network and the
issuer, when the network reports them, instead of a bare status code. If
you see this error, try a different card.
On the crypto rail, where a merchant charges the payment itself rather than
returning the resource, the payment completes when the merchant acknowledges
it. A merchant that answers without acknowledging — no readable
acknowledgement, one naming a different payment, or one reporting failure —
returns an error quoting the merchant’s own response, so an agent can read why.The payment reached the merchant either way, and the merchant may still take
it, so paying again under a new idempotency key risks paying twice. Confirm
on chain, or with Anchorage, before re-attempting — the merchant holds the
credential and is the party that would submit it.
Merchant enablement requests are paused. An org admin can no longer request
merchant enablement, and Anchorage is not deciding open requests for now.Every decision already made stands: an org that is already merchant-enabled
stays enabled, and the org settings page still shows the most recent request’s
status and the reason for a denial.
Merchant compliance screening runs when a merchant is reviewed for activation
and again on periodic rescreens. A merchant that compliance screening flags is
refused at review or deactivated later, and agents can no longer pay it.A merchant deactivated on 2 or 3 September stays deactivated. Ask Anchorage to
review it again.
Repeated code attempts for one email address during sign-in are now limited.
If you enter a correct one-time code and it’s rejected, wait a moment and
try again.
Merchant compliance screening was strengthened. Merchants are screened when
they are reviewed for activation and again on periodic rescreens; a merchant
that screening flags is declined at review or deactivated later, and agents
can no longer pay it.
agentic.anchorage.com/robots.txt and /llms.txt return those files. If you
fetched either one before and got the sign-in page with a success status,
fetch it again./llms.txt is an index for agents, in the llms.txt
format. It points at the unauthenticated merchant catalog, at the
authenticated endpoint that holds the wallet and payment actions, and at the
description of the public API. An agent looking for a service to pay for
should read it first and then search the catalog, since the catalog pages
render results for a query rather than listing every service./robots.txt opens the landing page, the merchant catalog, /llms.txt, the
agent instructions, the OpenClaw skill file, and the public API description to
crawlers. Signed-in pages stay closed to them.Discovery covers both files and the unauthenticated
catalog endpoint.Connecting an MCP client before you have picked an organization, on your
first sign-in or when you belong to several, now sends you to the
organization picker and brings you back to the consent screen once you pick
one. You accept an invitation or join an organization open to your email
domain if you need to, choose which agent the client links to, and the
connection completes, where the client used to receive an error. Two cases
still need a restart from the client: taking more than thirty minutes to
pick, or a client authorize request too long for the browser to remember.
Both land you on the dashboard after you pick.
When a payment on one of the newly payable URLs is signed but never makes it
onto the chain, the funds it reserved are released and the payment is closed
automatically, once the network confirms the payment can no longer be
completed. The budget it drew against becomes available again without anyone
having to intervene.
A payment on one of the newly payable URLs comes back carrying the merchant’s
own answer to it, whether the merchant accepted the payment or refused it. The
response is marked as shortened only when it was actually too long to return
whole, and the completion message names the rail that handled the payment.
Agents do nothing differently.
Agents can now pay paid URLs whose merchants quote a price in a way the
platform previously could not settle. Agents do nothing differently: how to
pay is read from what the URL asks for at payment time, and a cost preview
prices the same URL the same way. The newly payable quotes are payable on GET
requests only: a price quoted in answer to a write is refused rather than
paid, because paying it would leave the agent unable to tell whether calling
again repeats the change.
Extra request headers on a payment or cost preview — an API key, a content
type — reach the paid URL whether the agent passes them as a JSON object or
as a JSON-encoded string, and a headers value of any other shape is refused
with an error naming what was sent, before anything is fetched or paid.
Previously the object form was silently ignored, so a payment could settle
against the response the URL gives an unauthenticated caller.A request body must be a string: a body sent as an unencoded JSON document
is refused with an error asking for the string form, before anything is
fetched or paid. Previously that shape was silently sent as an empty body.
Registering an MCP client and revoking a token are now rate-limited: repeated
registration or revocation attempts are refused once they arrive faster than
the limit allows. An agent’s first reach of an endpoint URL nobody has
registered yet is rate-limited per agent. Once an endpoint URL is
registered — whether or not a payment on it completes — later calls to that
URL are not limited, and a normal connect — one registration, one consent —
stays well inside the limit.A registration or revocation request that hits its 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. A payment tool call that
hits its limit returns an error naming the limit; retry shortly.Every request body is also 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 that turns out to
exceed the cap is refused once the cap is hit while reading it. See
Agents for the details.When a payment or cost preview cannot reach the paid URL — the hostname does
not resolve, the connection is refused or unreachable, or the request times
out — the agent now receives an error naming the host and the cause, so it
can report the failing address instead of retrying blindly. These failures
used to return the generic reference-ID error. A URL whose host points at a
private or reserved network address is reported the same way as one that does
not resolve. Failures inside Anchorage Agentic Banking still return the
reference-ID message so support can trace them.
A cost preview for a paid URL now names the payment rail its price applies to,
alongside the amount, asset, chain, and recipient it already reported.A preview still moves no money, and it quotes the merchant’s terms rather than
clearing the payment: an agent that gets a price can still be refused when it
pays, because paying applies budget, screening, and wallet checks a preview has
nothing to run them against. The agent-facing tool text now says so, so an
agent reports a price as a price rather than as an approval.
The Deposit page fetches the details for whichever deposit option you pick, so
picking one is what shows you where to send funds. The page tells you while it
is fetching them.
A payment to a merchant who also banks with Anchorage Agentic Banking now
credits the receiving account from the same on-chain transfer that debits the
payer, so a paid balance reflects the money that arrived and reconciles
against the chain.
Improvement
Your first sign-in lands on the organization picker, where you accept an invitation or join an organization open to your email domain
Signing in identifies you, and you choose which organization to enter. Your
first sign-in lands on the organization picker, which lists your pending
invitations and every organization open to your email domain. Accept an
invitation or click Join, and you are a member; later sign-ins take you
straight to the organization you belong to.An organization is open to your email domain when it admits anyone with an
address at that domain. When one matches an address you have verified and you
are not a member, it appears under Organizations you can join with a Join
button — on the organization picker when you have no organization yet, and on
Settings once you do. You join at the standard member role, so accept the
invitation instead when someone invited you as an admin. An organization you
were removed from stays out of that list; ask an admin there to restore your
access.
A payment record now carries two budget versions: the version read when the
payment started, and the version in effect when the funds were authorized.
When they match, nothing changed mid-payment. When they differ, you can see
which rule applied. Both appear on the payment detail page and in the payment
record the API returns.This records the budget the payment draws on directly. A budget nested under a
parent is still checked against its parents as well, and their versions are
not recorded.
A Solana payment that settles on chain in the brief moment between the
merchant receiving the signed payment and Anchorage recording that delivery
now completes automatically: the settlement is recognized whichever side
finishes first, and the payment reaches its normal completed state with funds
accounted for exactly once. Payments on Base already behave this way.
In the rare case a crypto payment is interrupted at the moment of signing —
before any payment authorization is recorded — the agent now receives a
structured conflict explaining that reserved funds stay held and that
retrying with the same idempotency key re-enters normal payment
processing.
Every org admin now has the Deposit page and its navigation entry, so any
organization can fund its account by deposit. Incoming deposits still go
through the same compliance screening before the funds release to your
available balance.
While an account is locked for review, the Deposit page now withholds its
crypto deposit addresses — generating a new address and viewing the current
one are both refused, and the page explains the lock in place of the
address. The account’s deposit history stays visible throughout,
and deposits already on their way to a previously issued address still
arrive and follow the usual screening steps. A frozen account is unchanged:
it still accepts deposits and still shows its deposit addresses.
Creating or editing a budget — including the budget created with a new agent
— now requires the merchant scope to either allow all merchants or name at
least one; an empty allowlist returns a clear validation message. To
deliberately stop a budget’s spending, pause it — pause is reversible. An
existing budget with an empty allowlist can still be edited to a valid
merchant scope, paused, or revoked.
A Solana payment authorization is signed against recent network state and can
only land on chain for a short window. When that window has provably closed
and the network shows no settlement, the payment now declines automatically
and its reserved funds release — matching what already happens on Base. A
payment whose settlement did land on chain completes as usual.
When Anchorage consolidates duplicate entries for one merchant in the
merchant catalog, budgets whose allowlist names the duplicate now follow
to the surviving entry automatically. The budget keeps admitting the same
real-world merchant, and its cap and spend-to-date stay untouched. See
Budgets.
When a paid URL quotes its price, the quote may also name the resource
being sold. That name must now sit at the same address as the URL actually
reached — the same host and port, so a sibling or CDN subdomain counts as a
different address. A mismatch refuses the payment before anything is
signed, and a cost estimate for the same URL reports the same refusal.
Merchant screening is keyed by the resource’s address, so a mismatched
address could otherwise let one merchant present itself as another. Quotes
that omit the resource name keep working unchanged. See the failure-modes
table in Crypto payments.
A pending invitation to an organization whose setup did not finish now shows
Setup incomplete in its row instead of an Accept button — accepting
becomes available the moment Anchorage completes the organization’s setup.
Declining stays available throughout. Signing in also now requires an
organization that is ready for you: an invitation to an organization with
incomplete setup admits you once that setup completes, or once another of
your invitations or memberships points somewhere active. (Organizations are
active from the moment they are created — see the entry below — so this
state is rare and always something Anchorage resolves, never a step you wait
out.)
The organization chooser — including the pending-invitations view shown
before you belong to an organization — now names the account you are signed
in to and includes a sign-out button. Signing in with the wrong account
recovers in one step: sign out from the page and sign back in with the right
account.
A new organization is active from the moment Anchorage creates it. Anyone it
invites can accept and sign in straight away, and paying, transferring, and
approving a queued payment all work immediately.Anchorage’s onboarding checks on an organization and its members still run in
full — they complete as the organization is set up. This replaces the separate
activation step described in the 2026-07-27 entry below.An organization can still be frozen, which stops payments and transfers and
pauses its agents, and approving a queued payment stays blocked until it is
unfrozen.
The merchant directory at
/merchants now returns results whether or not you
are signed in: a signed-out search shows the same live merchants a signed-in
user sees.An invited member can now sign in for the first time with the email address
the invitation was sent to, whatever its domain — a personal address, or a
contractor’s own company address, for example. Signing in creates their
account and shows them the invitation; accepting it is what adds them to the
organization, with the role the invitation specified. An expired, revoked,
or already-accepted invitation grants nothing.Sign-in for a domain with an identity provider configured still goes through
that provider. Someone invited from outside that domain signs in with an
email code and accepts the invitation the same way.Two cases decline an invitation at the moment it is accepted: an organization
that has since restricted membership to its own email domain, and one still
awaiting activation. Both leave the invitation open — the first needs a fresh
invitation from an address the organization now admits, the second only needs
activation to finish.
A new organization now starts in a review state and must be activated by
Anchorage’s compliance team before it can be used — signing in, paying,
transferring, and approving a queued payment wait until activation. Existing
organizations are already active and unaffected. Merchant availability is
likewise reviewed by Anchorage’s compliance team.
Visiting agentic.anchorage.com without being
signed in now shows a short starting page linking to sign-in, these docs, the
product overview, and a way to reach us. If you are already signed in, you go
directly to your account.
You can now switch to sandbox mode to try deposits and payments on a test
network without moving real funds. Your sandbox balance is kept separate from
your live one, and test-network deposit addresses differ from your live ones —
copy the address shown for the network you are on. Switch back to your live
account at any time.
Approving a payment that is waiting in the approval queue now checks the
organization’s status first: if the organization is frozen, the approval is
rejected with a message naming the reason and the payment stays in the queue.
The same check runs when an approved payment is re-issued. Nothing is lost —
once the organization is unfrozen, the approval and re-issue work as before.
On a computer you can now collapse the navigation sidebar to give the page
more room, and open it again from the menu button in the top bar — the
sidebar stays the way you left it as you move between pages. The bar holding
the logo and the light and dark theme controls now sits at the top of every
screen, on computers as well as phones.
The navigation menu on phones opens from the top bar, the Escape key
closes it, and keyboard focus moves into the menu when it opens and
returns to the menu button when it closes. Switching between light and
dark themes is available directly from the top bar on phones. The
sidebar also keeps the current section highlighted while you view its
subpages — for example, a card’s detail page keeps Cards highlighted —
so it is always clear where you are.
Paging through long lists — purchase requests, budgets — uses an opaque
marker to fetch the next page. A corrupted or outdated marker now returns a
clear invalid-request error, and restarting the listing from the first page
recovers. Markers issued before this release are invalidated once at rollout,
with the same recovery.
This documentation now lives at docs.anchorage.com/agentic-banking. Old
links under agentic.anchorage.com/docs redirect here automatically, so
bookmarked pages keep working. The docs MCP server moved with it: requests
to the old address are redirected with the method preserved, which most
MCP clients follow transparently — if yours does not, update its
configured address to docs.anchorage.com/mcp. Updating saved links is a
good idea either way.
Finding a merchant now happens in one place: the merchant catalog, browsable
by anyone in the web UI — signed in or anonymous — and searchable by agents
over MCP. An agent’s results are limited to what it can actually pay on its
network (mainnet or testnet), and this catalog search is now the only way
an agent discovers where it can pay; the earlier separate list of allowed
merchants has been retired in its favor. Each result now also shows
the merchant a service belongs to, whether that merchant runs the service
itself or resells another provider’s, and the payment methods the service
accepts, so an agent can tell up front what it’s able to pay and who it’s
dealing with. Services from the same merchant are grouped together, and
pulling a single service’s detail lists the payment methods its endpoints
accept. Only merchants that have cleared review appear in results.
Agents can now report problems with the merchant catalog as they browse it. When
an agent cannot find a merchant it expected, finds that no merchant offers what
it needs, hits a service that does not work, or gets search results that miss the
mark, it can send that feedback to Anchorage Agentic Banking — noting the search
it tried or the service in question. The reports help us fill gaps in the catalog
and fix listings that have gone stale.
The Deposit page now warns when a Solana deposit address still needs its token
account created. If you see the warning, complete the setup before sending
funds to that Solana address. Existing ready addresses are unchanged.
Agents can now make crypto payments with USDC on Solana, alongside USDC on
Base — Anchorage Agentic Banking automatically settles on Solana when a
merchant prices a request there. You can also fund your account by depositing
USDC on Solana; it credits your account’s USD balance on that network
(mainnet or testnet — Base and Solana deposits feed the same balance, not
separate ones per chain) and is screened like any other deposit. Existing
Base payments and deposits are unchanged.
After you attribute a self-hosted deposit sender once, later deposits from the
same sender in your org can reuse those details automatically. The deposit still
runs screening before funds become available, so a fresh review can still block
the funds.
Agents can now find merchants and services to pay by describing what they
need — for example, “web search” or “image generation” — instead of needing
a URL up front. Search returns the matching live merchants, and an agent can
then pull a service’s payable endpoints and documentation links to make the
call. Only merchants that have cleared review appear in results.
Linked-card compliance screening was strengthened. As before, a card that does
not pass is refused at link time and stays in your card list, marked with the
reason.
When a deposit reads Needs attribution, you can now enter the sender’s
name and country directly from your deposit history. Submitting those details
runs the review and releases the funds in the same step if it passes.
When an agent connection does not pass compliance screening, its whole
session now ends and the agent must reconnect to continue. No action
required — a runaway agent is stopped at the connection.
Each deposit now shows where it stands in review: Needs attribution,
Reviewing attribution, Cleared, or Blocked on screening. A deposit
becomes available to spend once it reads Cleared. The label sits next to
each deposit in your deposit history, so you can tell at a glance whether
funds are ready or still in review.
Paid URLs that return large payloads now come back to your agent whole:
responses up to 10 MB are delivered in full, so data-heavy APIs behind a paid
URL work as expected.
Linked-card support now runs compliance screening when a card is linked and on
each purchase. A card or purchase that does not pass is refused; rejected cards
stay visible in your card list for audit, marked with the reason. No action
required — if a link or purchase is refused, the web UI explains why.
The first public release of Anchorage Agentic Banking, alongside the
launch of this docs site.
- Two payment rails. Crypto payments to paid URLs on the open internet, and linked-card purchases via a one-shot credential scoped per merchant. Each agent can use both rails and picks one per spend.
- Agent-scoped budgets. Org admins pre-authorize crypto spend with a USD spend limit and a merchant allowlist; agents see the limit, not the account balance.
- Per-purchase passkey approval for linked cards. Each card purchase an agent requests goes through a fresh passkey approval in the browser.
- Safety cap that no approval can override. $1,000 per UTC day, per agent, across both rails.
- Instant revoke of any agent from the web UI, with no grace window.
- Sign-in via work SSO or a one-time email code.