What Brex AI is in 2026, and which parts touch money
Brex AI is the set of agents Brex runs inside its own product plus the doors it opens to outside assistants. Inside the product, Brex lists Brex Assistant (expenses, memos, receipts and reimbursements for employees), an Audit Agent and a Review Agent on its intelligent finance page. CEO Pedro Franceschi introduced the agent platform publicly on 5 November 2025.
Outside the product, Brex launched the Brex MCP server in April 2026, per its developer changelog, so assistants such as Claude, ChatGPT, Cursor and Codex can work on your Brex data. Brex also keeps a public Developer API, which is older, larger and much more powerful.
One ownership fact matters for procurement teams: Capital One completed its 5.15 billion dollar acquisition of Brex on 7 April 2026, and the Brex site now describes Brex LLC as a wholly owned subsidiary of Capital One, N.A. Brex still runs its own product and API.
What Brex does not have, as of our check, is a card product built for AI agents to spend with, the way Ramp ships Agent Cards. Brex AI today reviews, codes and explains spend. It does not buy things on its own.
How we measured the Brex MCP server and the Brex API
On 27 and 28 September 2026 we probed Brex with no account and no credentials, the way anyone can repeat it. We requested api.brex.com/mcp, its OAuth protected resource document, a randomly generated control path under the same well-known prefix, a random path at the API root, and the DNS name mcp.brex.com. We then read the tool table in the Brex MCP documentation and downloaded the ten official OpenAPI specifications linked from developer.brex.com.
The control paths changed how we read the result. A random path under /.well-known/oauth-protected-resource/ did not return 404. It returned a generic document named Brex API with the same scope list, while the /mcp path returned one named Brex MCP Server. So the scope list is the platform list shared by every Brex resource, and the MCP identity is proven by the resource name and the documentation, not by the scopes alone. A random path at the root returned 404, so the host is not a catch-all.
mcp.brex.com does not exist (NXDOMAIN). The MCP server lives on the API host. Brex does not publish its server as open source; the Brex MCP packages on npm and GitHub are third-party projects.
The Brex MCP server has 43 tools and 5 of them write
The Brex MCP tool table lists 43 tools. Thirty-eight read: users, departments, locations, cost centers, expenses, cards, limits, the expense policy on a limit, business bank accounts and their transactions, bills, vendors, accounting records, GL accounts, trips and bookings. One more, start_expense_download, kicks off an export job.
The 5 write tools are update_expense_memo, upload_card_expense_receipt_from_urls, replace_attendees_for_card_expense, assign_limit_for_card_expenses and submit_feedback. The closest one to money is assign_limit_for_card_expenses, which moves an expense that already happened onto a different spend limit. It changes which budget absorbs the charge. It does not change how big the budget is.
Brex says it plainly in the docs: approvals and card management are not yet available via MCP. There is no tool to create or edit a limit, issue or unlock a card, approve a request, pay a bill or send a transfer.
Two setup details matter for control. An account or card admin must accept the Developer API agreement and turn on the Brex in AI assistants beta. After that, every user in the account can connect their own assistant with OAuth, and the assistant inherits that person's Brex permissions. Sessions stay active until someone revokes them under Connected integrations.
The scopes behind it, and why the list is longer than the tools
The protected resource document lists 20 scopes. Seventeen are identity or read-only, such as users.readonly, budgets.readonly, accounts.cash.readonly and accounting.record.read. Three carry write capability: cards, expenses.card and expenses.bill.
Two absences are the headline. There is no budgets write scope and no transfers scope in the list, so an OAuth grant through this server cannot be widened into a limit change or a payment. The cards scope is present even though no MCP tool manages cards. In the Developer API that scope sits behind card creation, updates, lock, unlock and terminate, so treat it as the one to watch if Brex adds card tools later.
Because the same document is served for any path under the well-known prefix, these 20 scopes describe what Brex offers across its OAuth resources, not a list tailored to MCP. The tool table is the tighter description of what an assistant can actually do today.
What the Brex API can do that the MCP server cannot
The ten official specifications hold 76 paths and 106 operations. Three groups of those operations are exactly what the MCP server leaves out.
Spend limits. POST /v2/spend_limits and PUT /v2/spend_limits/{id} under the budgets scope create and change a limit: its base limit, a flexible buffer from 0 to 100 percent, the period (weekly, monthly, quarterly, yearly or one time), a per-transaction limit, allowed and blocked merchant categories, owners, members and the expense policy. set_transaction_limit_null removes the per-transaction cap outright.
Cards. POST /v2/cards under the cards scope issues a virtual or physical card with its own spend controls: an amount, a duration (monthly, quarterly, yearly or one time), a lock-after date and an allow or block list of up to 50 merchants. PUT /v2/cards/{id} changes those controls later.
Money movement. POST /v1/transfers under the transfers scope sends ACH, wire or book transfers from a Brex business account. The request has one approval field, approval_type, whose only value is MANUAL, meaning a cash admin must approve before funds leave. When the caller leaves it out, Brex applies the account's default policy.
Amounts are integers in minor units with an ISO currency, so a limit of 50,000 means 500 dollars. Get that wrong in an agent prompt and you are off by a factor of one hundred.
The gap for agents on Brex: the approval is optional and the caller sets it
Brex's decision to keep MCP read-mostly is sound, and it is the most conservative design we have measured among spend platforms. The risk sits one layer down. Teams that want an agent to actually do something on Brex, such as issue a one-time card for a vendor or pay an invoice, end up on the Developer API with an admin-generated token, because that is where the verbs are.
At that point three things hold. The token's scopes decide what the agent can do, and a token with budgets can raise the limit the agent itself spends against. The MANUAL approval on a transfer is a field in the request, chosen by whoever writes the request, which may be the agent. And an API token is tied to the admin who created it rather than to a named agent, so the audit record shows the admin.
None of this is a Brex bug. Brex is a card and banking platform with strong spend limits for people and teams. It simply does not model the agent as the actor, so the separation between the thing that spends and the thing that sets the ceiling is left to you.
A rollout checklist for Brex AI agents
- Start with MCP for anything read-only. Spend analysis, missing receipts and policy questions are exactly what the Brex MCP server is built for, and it cannot change a limit.
- Decide who may connect. Turning on the beta lets every user connect an assistant. If that is too broad, keep the beta off until you have a written policy, and review Connected integrations monthly.
- Never give an agent a token with
budgetsortransfers. Those belong to a human or to a separate service the agent cannot call. - Issue one card per agent with a one-time or monthly amount, a lock-after date and an allow list of merchants, created by a person, not by the agent.
- Force manual approval on transfers at the account policy level rather than trusting each request to set
MANUAL. - Name the agent in your own log. Brex will show the token owner. Record which agent made each call so an auditor can tell them apart.
How AgentsPay fits alongside Brex
AgentsPay does not replace Brex as your card program or bank. It sits in front of the agent as the policy decision point: each agent gets its own budget, per-transaction ceiling, merchant allowlist and approval threshold, and the agent's credentials have no write access to its own policy. Approvals above the threshold go to a person in Slack or email, and every decision lands in an exportable audit trail that names the agent, not only the admin who owns the token.
Because the policy is rail neutral, the same ceiling covers a Brex card, a scoped virtual card from another issuer, an API subscription the agent buys and a stablecoin payment. If you are also weighing Ramp for agent spend, our Ramp AI agents and Ramp MCP breakdown measures the other approach, and the Ramp vs Brex for AI agents comparison puts the two side by side. Teams deciding whether to leave Brex altogether can start with our Brex alternative for AI agents guide.