What the Airwallex MCP server and AgentOS do today
Airwallex AgentOS is, in Airwallex's words, "a production-grade toolkit for AI agents to operate on your Airwallex account." It bundles three things. The connectors are the Airwallex CLI, which works against sandbox and production, and the Airwallex AgentOS MCP server at https://mcp.airwallex.com/mcp, which connects chat agents to your production account. The skills are pre-built workflows, in beta. The plugins install both into Claude Code, Claude Cowork, Cursor and Codex in one step.
Setup is short. In Claude Code it is claude mcp add-json airwallex '{ "type": "http", "url": "https://mcp.airwallex.com/mcp" }', followed by an OAuth sign-in to your production account. In Claude.ai and Claude Cowork you pick the official airwallex-agentos connector under Settings and Connectors. Cursor has a one-click install, and any MCP client can point at the same URL.
The five published skills show what Airwallex expects agents to do: contract-to-billing (read a PO or contract, then create invoices and subscriptions), beneficiary-creation (extract supplier bank details from documents and create beneficiaries), card-provisioning (create cardholders and issue virtual or physical corporate cards with spend limits), manage-cashflow (balances, receivables, FX exposure and indicative quotes) and awx-best-practices, an always-on guardrail. For a US finance team that pays suppliers abroad and runs corporate cards on Airwallex, that is a genuinely useful set.
There is a second, separate product. The Airwallex Developer MCP at https://mcp-demo.airwallex.com/developer and the docs-only server at /docs are built for engineers integrating Airwallex. They search documentation and act on the sandbox, never on production, and they also ship as the npm package @airwallex/developer-mcp.
How we probed Airwallex, with a control for every check
We did not rely on the announcement. On 21 October 2026 we read what Airwallex publishes without a login and paired each check with a control that should have produced the opposite result:
- The production host.
GET /mcpreturned405, which is correct for a Streamable HTTP endpoint that only takes POST. A JSON-RPCinitializesent by POST without a token returned401withWWW-Authenticate: Bearer resource_metadata="https://mcp.airwallex.com/.well-known/oauth-protected-resource/mcp/". The root and a randomly generated path both returned404, so the host is not a catch-all. - The production OAuth metadata. The protected-resource document lists 35 scopes. The authorization-server document publishes authorize, token and registration endpoints, the authorization code and refresh token grants, PKCE with S256 only, client authentication methods including
none, and support for client ID metadata documents. Any MCP client can register itself. - The sandbox Developer MCP. The same check on
mcp-demo.airwallex.com/developerreturned405on GET, a scope document with 47 scopes, and404on a random path. - The documentation. Airwallex's
llms.txtindexes about 300 documentation pages. We read the AgentOS, Developer connector, CLI, authorization controls and transaction limits pages in Markdown, as published.
We did not sign in, so we cannot list the exact tools the production server exposes after authentication. Scopes are the stronger evidence anyway: a tool can only do what its token is allowed to do, and the scope list is what anyone can re-check with two requests.
No money-out scope on the production server
This is the part Airwallex got right, and it deserves to be said plainly. Airwallex documents that AgentOS components "do not initiate money-out actions (transfers, FX conversions, or payouts) on your behalf." That kind of promise is usually enforced only by instructions to the model, which a prompt injection can talk around. Here it is also visible in the authorization layer.
Of the 35 production scopes, 23 are reads and 12 are writes. The reads cover balances, contacts, conversions, global accounts, cardholders, cards, card transactions, payment acceptance, payment links, account details, transfers, billing objects, expenses, bills and vendors. The writes are listed in the table below. What matters is what is missing: the production server publishes r:awx_action:transfers_view but no transfer write scope, conversions_view but no conversion write scope, and no scope to create deposits or edit linked accounts. A token issued by this server cannot send a wire, whatever the model is told.
The sandbox server shows what the full set looks like. Its 47 scopes include 20 writes, among them w:awx_action:transfers_edit, w:awx_action:conversions_edit, w:awx_action:pa_edit, w:awx_action:deposits_create, w:awx_action:linked_accounts_edit and w:org_action:billing.checkout_edit. Airwallex withheld exactly the money-moving ones from production. That is a deliberate design choice, and a good one.
The CLI is different. Airwallex calls it the connector with the broadest API coverage, it reaches production with --prod, and the docs say that where the underlying API supports money-out, the components are "explicitly instructed not to execute them." Write actions ask for confirmation in interactive mode, unless the caller passes --confirm. So on the CLI, the money-out guardrail is an instruction and a confirmation prompt, not a missing permission. If an agent runs in a terminal with a broadly scoped login, narrow it with airwallex auth login --prod --scope=....
The agent that spends can issue its own cards
Money cannot leave through a transfer, but it can leave through a card. The production server holds w:awx_action:issuing_cardholders_edit and w:awx_action:issuing_cards_edit, and Airwallex's own card-provisioning skill runs on it to "create cardholders and provision virtual or physical corporate cards with spend limits." So an agent connected through AgentOS can create a cardholder, issue a virtual card and choose the limit on that card in the same session.
Airwallex card limits are among the best we have measured. Every card must carry transaction limits, which can be set per transaction, daily, weekly, monthly, quarterly, yearly or for all time. You can restrict merchant category codes, currencies, an active date range and transaction types such as online, contactless or ATM, and you can route each authorization to your own endpoint with remote authorization. The account also has a default and a maximum per-transaction limit per currency, and a card request above the maximum is rejected. Those account values are commercial settings that only your Airwallex account manager can change.
The question for an agent rollout is who sets the card limit. If the agent issues the card, the agent picks the limit, anywhere up to the account maximum. If it leaves the merchant category list empty, Airwallex allows every category. And each limit belongs to one card, so an agent that issues five cards has five separate ceilings and no total. Airwallex's docs do tell you to require manual approval for write tools, since the server annotates them, but that prompt lives in your MCP client, and only helps if nobody turned on auto-approve.
Invoices, prices and discounts are writable too
Seven of the twelve production write scopes are on the billing side: customers, discounts, invoices, prices, products, subscriptions and usage metering. That is what the contract-to-billing skill needs, and it is useful: an agent reads a signed order form and sets up the subscription without retyping.
It also means an agent can change what customers pay. A discount scope on a token that reads untrusted documents is a revenue control, not a convenience. Payment links are writable as well, through w:awx_action:payment_links_edit. None of this sends money out of your account, but each one changes money that should come in, and none of it is limited by amount in the scope itself.
The fix is the same one Airwallex recommends: grant only the scopes your use case needs. A cash-reporting agent needs reads. A billing agent needs the billing writes and nothing on issuing. A card agent should be the only one with issuing scopes, and its limits should come from a policy you set rather than from its own judgment.
What Airwallex says about prompt injection and shared agents
Airwallex's safety section is unusually direct, and two warnings in it are worth quoting to anyone in your security review. On shared channels, connecting AgentOS MCP "authorizes the agent platform to act on your account within those scopes," so do not add that agent to multi-user channels such as Slack, because "anyone who can prompt the agent may perform Airwallex actions with your privileges that they cannot perform in the web or mobile apps."
On injection, Airwallex tells you to treat untrusted documents and web pages as a risk and to review every tool call, "including reads that could exfiltrate account data." That matters because the flagship skills read exactly that kind of input: supplier documents for beneficiaries, contracts for billing.
The advice is sound. Its weakness is that every control in it is a habit: review each call, keep auto-approve off, scope narrowly, confirm in the web app afterwards. Habits hold for a pilot run by one careful person. They do not hold when several agents run on schedules overnight, which is where a written policy outside the agent has to take over.
What a finance lead adds before an agent touches Airwallex
None of this argues for keeping AI away from Airwallex. It argues for deciding where the limits live before the first card is issued. Before an agent writes to Airwallex, we would put these in place:
- Use the AgentOS MCP rather than a broad CLI login for any agent that does not need to move money. The missing money-out scopes are a real protection, so keep them.
- Split agents by job and scope. Reporting gets reads only. Billing gets billing writes. Only one card agent holds the issuing scopes.
- Never let an agent choose its own card limit. The card agent asks a policy service for the limit, merchant categories and expiry, and issues exactly that.
- Keep a budget per agent across all its cards, not only per card, so a fifth card does not reset the ceiling.
- Require a named human above a threshold, with approval routing for agent payments that records who approved what.
- Prefer merchant-locked, single-use cards for one-off purchases. Airwallex supports single-use cards, and our guide to virtual cards for AI agents covers when to use them.
- Keep agents out of shared Slack channels, as Airwallex itself advises.
We measured the same question across the finance stack. The Tipalti MCP server is read-only while its OAuth server already lists payment write scopes. The Mercury MCP server can only request payments, and Mercury's agent cards are created by people in the app. Airwallex sits between the two: no money-out scope at all, but full card issuing.
How AgentsPay works alongside Airwallex
AgentsPay does not replace Airwallex. Airwallex stays your multi-currency account, FX engine, card issuer and payout rail. AgentsPay sits between your agents and Airwallex and decides, request by request, whether one goes through.
Each agent gets its own identity, a monthly budget, a per-transaction ceiling and an approval threshold with a named approver. When an agent needs a card, it asks AgentsPay first, with the merchant, amount and reason. AgentsPay returns the limit, the allowed categories and the expiry the card must carry, or routes the request to the approver. Every decision lands in an audit trail you can hand to an auditor. Because the same policy covers cards, bank transfers and agent payment protocols, an Airwallex card and a payment on another rail count against one budget.
If you are pricing the Airwallex side, our Airwallex pricing breakdown covers the US plans, FX and transfer fees. The agent side is on our AgentsPay plans and pricing page, and the controls themselves are described under spend controls for AI agents.