What Navan AI and Expensify Concierge can do with money in 2026
Navan AI is the AI layer across Navan's travel and expense platform. Its support agent, Ava, handles a large and growing share of traveler conversations (Navan told investors it reached about 60 percent of customer interactions in a recent quarter, including rebooking and refunds). On 2 July 2026 Navan launched an MCP server that lets Claude, ChatGPT, Cursor, Codex and VS Code query spend, bookings, policies, approval flows and card details in plain English. Navan's launch release calls the first version read-only and names the write tools it is building next: approving out-of-pocket expenses, updating travel policies, and booking travel from inside the assistant.
Expensify has two different AI surfaces and they carry different authority. Concierge is the assistant every user talks to. It answers questions, and on request it creates an expense, changes an amount, marks something non-reimbursable or turns on a workspace rule such as requiring receipts above 25 dollars. The Expensify MCP server, launched 8 June 2026, gives outside assistants one Search tool under a single mcp:tools scope, and Expensify's help center is explicit that it cannot create, edit, approve or reimburse anything.
The third surface is the one finance teams should look at before anything else. Expensify Agents (open beta) and Agent rules are AI members of your workspace that act on reports. They can submit a report, approve it, reject single expenses, put expenses on hold, take over a report as approver, route it to a different approver and export it to QuickBooks, Xero, NetSuite or Sage Intacct. A final approval sends the report to the reimbursement queue as Ready to Pay. That is real authority over real money, and it is configured in English.
How we measured the Navan MCP server
On 2 October 2026 we sent unauthenticated requests to Navan's hosted server with no account, so anyone can repeat this in a terminal. Every probe was paired with a randomly generated control path, because some servers answer every URL with 200 and look like they support everything.
A JSON-RPC initialize posted to https://mcp.navan.com/mcp returned 401 with a WWW-Authenticate: Bearer header pointing at the protected-resource document, and the body -32001 Missing Bearer token. A plain GET to the same path returned 405, which matches Navan's docs: HTTP transport only, no SSE. The control paths returned a 400 gateway error rather than a page, so the host is not a catch-all.
The protected-resource document names login.navan.com as the authorization server and lists scopes_supported as an empty array. The authorization server's own discovery document lists 14 scopes, and every one is an identity claim: openid, profile, offline_access, name, given_name, family_name, nickname, email, email_verified, picture, created_at, identities, phone and address. There is no Navan permission scope at all, and dynamic client registration is open.
That is consistent with how Navan describes the design. The developer docs say the assistant "inherits exactly the permissions Navan has already granted you", bound to your role, entity and region. The docs' own role table lists what each role can change: a Manager can approve or reject reports they own and an Approver can approve, reject or request edits. So the only ceiling on what an assistant connected as a manager can approve is the manager's own authority. Nothing in the token narrows it to an amount.
Navan deserves credit for two things most vendors in our series skip. Every tool call is logged with the user, the MCP client name and version, the exact tool and its arguments, and the response size. And the docs state the server cannot bypass approval workflows, policy rules or duplicate detection.
How we read the Expensify agent API
Expensify's endpoint at www.expensify.com/mcp could not be measured from a server. It returned a 403 bot challenge on every path, including our random control path, which tells you about the firewall and nothing about the server, so we do not draw a conclusion from it.
Expensify gives us something better. The New Expensify client is open source on GitHub, and every call the app makes to Expensify's backend is declared as a typed parameter object. On 2 October 2026 we read the main branch and counted 682 API parameter types.
The control first. 56 of those 682 type names are about money, limits or approvals, and they are precise: SetPolicyAutomaticApprovalLimit, SetPolicyExpenseMaxAmount, SetPolicyCategoryMaxAmount, UpdateExpensifyCardLimit, UpdateTravelBillingMonthlyLimit, SetPolicyPreventSelfApproval. Expensify models spend limits for people in real detail, so the method is not blind.
Then the agents. Four types create or configure an agent or an Agent rule: CreateAgent, UpdateAgentPrompt, AddPolicyAgentRule and UpdatePolicyAgentRule. Between them they carry 18 fields. They are IDs, a first name, an avatar, a workspace ID, a personal-agent flag and one field called prompt. None is an amount, a currency, a limit or an approver. Everything an agent is allowed to do lives in that free-text prompt.
Two more facts from Expensify's own help center finish the picture. A new agent is added as a full-access Copilot on the account of the person who created it (the delegate role has two values, full access and submitter, and agents get the first). And the first time an admin creates an Agent rule, Expensify adds RuleBot to the workspace as a Workspace Admin.
The approval limit is a sentence the model reads
Expensify's capability reference tells you how to phrase instructions. To approve, write "Approve reports under $1,000". To escalate, write "Route reports over $5,000 to the finance manager". With the admin role, "Take over reports over $10,000 regardless of who they were submitted to".
Read those as a controller would. The dollar figure is inside an instruction to a language model. It is not stored as a number, it is not checked by a rule engine before the approval posts, and nothing compares it with what the agent approved yesterday. If a report total is ambiguous, if the currency differs, or if a long expense description talks the model into a different reading, the instruction is what gets interpreted. Expensify itself advises that clear, specific instructions "generally produce more predictable results", which is honest, and it is also the definition of a soft limit.
None of this makes the feature reckless. Expensify's structured workspace rules still run underneath every agent: maximum expense amounts, receipt requirements, category limits and holds that block approval and payment until fixed. Those are real limits on expenses. What is missing is a limit on the agent: a hard amount above which this agent cannot approve whatever its prompt says, and a monthly total it cannot exceed.
Where to put a hard dollar limit on an Expensify agent
There is a structured answer inside Expensify, and it is the first thing to configure. Each approver in a workflow can carry an approval limit with an over-limit approver. In Expensify's data model that is the approvalLimit and overLimitForwardsTo pair on the approver's row: if the report total is above the limit, the next approver is the over-limit person instead of the usual one. Because an agent can be selected anywhere a workspace member can, you can put the agent into the workflow as an approver with, say, a 500 dollar approval limit and a named human as the over-limit approver. Reports above 500 dollars then reach a person before they can be paid, whatever the prompt says.
Know the edges of that control. It is per report, so twenty reports at 499 dollars pass cleanly. It does not total what one agent approved this month. And an agent holding the admin role can be instructed to take over or reroute reports, which changes who sits in the workflow, so keep approving agents out of the Workspace Admin role wherever you can, and review RuleBot's admin seat on purpose rather than by default.
The second edge is the bigger one. Expensify governs money that flows through expense reports. An agent that buys things, books travel, renews software or calls a paid API spends money that never becomes an expense report until after it has left your account. Navan's planned booking tools will put agents into exactly that position for travel.
A rollout checklist for Navan and Expensify agents
- Connect MCP as a reader first. Both servers are designed for analysis. Connect them with the narrowest real user who needs the answers, not an admin, because the assistant inherits that person's full authority.
- Turn MCP on per workspace or company deliberately. Expensify has a workspace MCP toggle and Navan SSO companies enable MCP under Integrations. Decide who may connect before people start pasting the server URL into Claude.
- Put every approving agent behind an approval limit. In Expensify, give the agent an approval limit and a human over-limit approver in the workflow. Treat the dollar figure in the prompt as documentation, not enforcement.
- Keep agents out of admin roles. Take over and reroute need admin rights. An approver agent does not need them.
- Watch the cumulative total yourself. Export what each agent approved each week. Neither platform gives you a per-agent monthly ceiling.
- Put a payment layer in front of anything an agent buys. When Navan's booking tools or any other agent can spend, give it a funded wallet or virtual card with a monthly budget, a merchant allowlist and an approval threshold that fires on the amount.
How AgentsPay fits alongside Navan and Expensify
AgentsPay does not replace Navan or Expensify. Keep them as the system for expense reports, travel policy, reimbursement and your accounting sync. AgentsPay sits in front of the money an agent moves on its own: each agent gets its own wallet and scoped virtual card, a budget in dollars that is cumulative across the month rather than per report, spend controls by merchant and category, approval thresholds that hold a payment for a named person above an amount you set, and an audit trail you can reconcile against Navan or Expensify at close.
The difference is where the number lives. In AgentsPay the limit is a stored value checked before the payment is authorized, and the agent's credentials cannot edit their own policy. A prompt can ask for more. It cannot get it.
We have measured the same gap on the corporate card side. Ramp's agents and MCP server and Brex's AI agents both govern cards for people in depth, and our Expensify pricing per user breakdown covers what the Collect and Control plans cost before you add agents to a workspace.