What Ramp AI agents are in 2026, and which ones touch money
Ramp AI is not one product. It is a set of agent surfaces layered onto the Ramp card and bill pay platform over roughly eighteen months, and they carry very different amounts of financial authority.
Ramp announced its MCP server on 27 March 2025, letting assistants such as Claude read and act on Ramp data. On 9 July 2025 it published Agents for Controllers, which review expenses against policy and flag or approve them. On 11 March 2026 it launched Agent Cards, which give software its own Ramp identity and card credentials, and on 29 April 2026 it announced a fleet of procurement agents across its procurement product. The agent documentation at agents.ramp.com now describes standalone agents with default roles named Purchasing, Bill approvals, Data analysis, Expense Completion and Full Access, and notes that standalone agents are in limited early access.
For budgeting and risk, split these into two groups. Agents that review, code and summarize spend are low exposure: their worst failure is a wrong GL code. Agents that approve requests, lock or unlock cards, or buy things with an agent card carry the same exposure as the human role they run under. The rest of this page is about the second group.
How we measured the Ramp MCP server and the Ramp Developer API
On 27 September 2026 we probed Ramp with no account and no authentication, the same way anyone can repeat it. We requested the root of mcp.ramp.com, its OAuth protected resource documents, the /mcp route, and several randomly generated control paths, then downloaded Ramp's public OpenAPI specification from docs.ramp.com/openapi/developer-api.json and read every operation.
The control paths matter. Plenty of hosts answer 200 or 401 to anything, which makes a naive probe report endpoints that do not exist. Here the root returned 404, bare random paths returned 404, and the discovery documents returned structured Ramp JSON. A random path ending in /mcp returned the same 401 as the real route, and Ramp's own documentation explains why: any path of the form mcp.ramp.com/<business-identifier>/mcp is an alias for the production server. So the endpoint, the scope list and the API surface below are all confirmed rather than inferred.
Ramp MCP publishes 52 OAuth scopes, 21 of them writes
The protected resource document lists 52 scopes, 31 read and 21 write, and hands out tokens through a PKCE flow at api.ramp.com/developer/v1/token/pkce to public clients that can register themselves at mcp.ramp.com/register. When we first read the same document on 6 September 2026 it listed 54 scopes and 23 writes; an mpp:write scope has since been removed, so the list is actively maintained.
The vocabulary is openly built for agents: agent_wallet_policy:read and agent_wallet_policy:write, cards:read_agentic, agent_account_numbers:read, ai_spend:read, and x402:write plus x402_provisioning:write for the x402 payment protocol. No other finance vendor we have measured names agents this explicitly in its permission model, and Ramp deserves the credit.
The write list is where to slow down. Four scopes change the controls themselves (limits:write, funds:write, cards:write, agent_wallet_policy:write), six move or commit money (bills:write, reimbursements:write, bank_accounts:write, banking_drawdown_requests:write, x402:write, x402_provisioning:write) and one acts on the gate in front of spending (approvals:write). All of them can sit in a single grant.
What funds:write actually reaches: limit, lock date and the policy agent
Ramp models a spend limit as a fund, and the fund is a serious control object. Ramp's public Developer API (OpenAPI 3.0.2, 176 paths and 255 operations, 150 of them writes) exposes PATCH /developer/v1/funds/{fund_id} behind the funds:write scope. Its request body carries spending_restrictions with ten fields: limit, interval (daily, weekly, monthly, quarterly, tertiary, annual, yearly or total), transaction_amount_limit, allowed and blocked category codes, blocked_mcc_codes, allowed and blocked vendor IDs, lock_date and is_temporary_increase.
Three details decide how much trust you are extending. First, limit and transaction_amount_limit are writable, so the ceiling is a value the token can set. Second, Ramp documents lock_date as the date the fund suspends itself, adding that if the date has passed you can set it to a future date or to null to unsuspend. Third, the same body carries is_exempt_from_policy_agent, a boolean that takes the fund out of review by Ramp's own policy agent.
None of this is a flaw for a finance administrator working in the API, which is who these operations were designed for. It becomes a design question the moment the token belongs to software that is itself spending from one of those funds.
What an agent can do through the Ramp MCP tools today
Ramp's agent guide is candid about the action surface. Through MCP an assistant can approve or reject transactions, reimbursements and unified requests, and Ramp lists purchase orders and fund requests among those unified requests. It can edit a transaction's memo, coding and fund assignment, lock, unlock and activate cards, submit reimbursements, create trips and generate Agent Card credentials. Bill approvals are the one notable exclusion: Ramp says they are not yet available through MCP.
Two properties of the session matter for risk. Every action runs with the role of the person who authorized the connection, so when a controller connects Claude to Ramp, the model holds a controller's powers for that session. And read-write sessions expire 24 hours after last use, which means an agent that makes at least one call a day keeps its write session alive indefinitely. Ramp logs every write to the customer's audit log, which is excellent for reconstruction and does nothing to stop the write.
Where Ramp is genuinely ahead of every other platform we measured
This page is not an argument that Ramp is careless. It is the opposite. In our schema series we have measured the agent layers of Microsoft, Salesforce, ServiceNow, SAP, UiPath, Workday, Oracle, Google and AWS, and most of them contain no field that can hold an amount of money anywhere near an agent. SAP's public Joule Studio packages carry 480 property names and zero money fields; Microsoft Graph carries 623 properties across 48 agent governance types and zero money fields. Ramp is the reverse: its agents live inside a platform whose core object is a dollar limit with an interval, a per-transaction cap and a vendor allowlist.
If every dollar your agents spend moves on Ramp cards and Ramp bill pay, Ramp's agent roles plus tightly scoped funds are a strong setup, and for many US mid-market finance teams it is the right place to start. The gap below is narrower and more specific than "Ramp lacks controls".
The real gap: the limit lives where the agent's token can write
Every serious control framework, from SOX to the procurement policy in your own handbook, separates the person who spends from the person who sets the limit. On Ramp, both the spending and the limit setting happen through the same API, the same OAuth server and potentially the same grant. If an agent session holds funds:write or limits:write and runs as a user who can manage the fund it spends from, nothing in the protocol distinguishes the agent raising its own ceiling from an administrator doing it deliberately. With approvals:write the same session can approve a fund request, which is the ordinary way a Ramp limit goes up.
The second gap is scope of rail. Ramp governs money that moves on Ramp. Agents also spend through Stripe keys, cloud and model API credits, SaaS seats bought on other cards, and x402 or card payments issued elsewhere. A policy that lives inside one card platform cannot see those, so the same agent can respect its Ramp fund perfectly and still overspend in total.
A rollout checklist for Ramp AI agents that can spend
- Never connect MCP as an admin. Create a dedicated user or agent identity with the narrowest default role, Purchasing or Expense Completion, and authorize the session as that identity.
- Strip control scopes from agent grants. An agent that buys should not hold
limits:write,funds:write,agent_wallet_policy:writeorapprovals:write. Those belong to a human or a separate service. - Give each agent its own fund with a
transaction_amount_limit, a short interval and an allowed vendor list, rather than sharing a department card. - Leave
is_exempt_from_policy_agentfalse on every fund an agent can touch, and alert on any change to it. - Watch the audit log for fund and approval writes by agent sessions. A limit change authored by an agent should page someone.
- Put one policy across every rail. Count what the agent spends outside Ramp too, or the Ramp limit only caps part of the exposure.
How AgentsPay fits alongside Ramp
AgentsPay does not replace Ramp as your card program or your system of record for spend. 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, by construction. Approvals over a threshold route to a human in Slack or email, and every decision lands in an exportable audit trail.
Because the policy is rail neutral, one ceiling covers what the agent spends on a Ramp card, a scoped virtual card from another issuer, a Stripe key or an x402 payment. If you are already on Ramp, the practical setup is Ramp funds as the hard floor on Ramp spend and AgentsPay spend controls as the policy the agent cannot edit, across everything. Teams weighing Ramp against Brex for this use case can read our Ramp vs Brex for AI agents comparison.