# Ramp in Claude for finance, minus admin reach

> Ramp in Claude for a finance team, without giving every analyst an admin seat: one authorized connection, read-only scopes, restrictions on the finance role.

**TL;DR** Only a Ramp Admin or Business Owner can authorize a Ramp developer app, so the connection a finance team shares carries that reach. Elaichi bounds it twice: a typed list of Ramp read scopes on the OAuth app, and an allow rule on the finance role naming the read tools. Claude then points at one endpoint, and every tool call is recorded with the Ramp account it actually reached.

## Who can authorize a Ramp app, and what the finance team inherits

Finance wants Ramp in Claude: what did we spend with this vendor last quarter, which bills are still unapproved, who has not attached a receipt. The blocker arrives before the first question. Ramp's own pages name who can authorize a developer app. Only users with Developer API authorization permission can do it, typically Admin and Business Owner (<https://docs.ramp.com/developer-api/v1/authorization>, <https://support.ramp.com/accessing-the-developer-api>, checked October 2026). You are not handing five analysts an admin seat to get a spend question answered.

So one admin authorizes, and the team shares what that authorization produced. In Elaichi, a governed MCP control plane, one Ramp admin connects the Ramp account once. MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps. The connection is then shared with the finance team at `use`. That is the grant that lets a person call something they do not own. It is distinct from `edit`, the share level that lets them change the connection. A shared connection runs on its owner's credential, so every call reaches Ramp as that admin account. The analysts never see or hold the secret, and they gain no new role inside Ramp.

What actually bounds a shared call is three layers, each narrower than the last, and none able to widen what the layer before it allows:

1. **The admin's Ramp role**: whatever Admin or Business Owner can see in Ramp, which Ramp sets and Elaichi cannot override.
2. **The OAuth app's scopes**: the read/write list configured in Ramp's developer app, which bounds the credential itself.
3. **Elaichi's restrictions**: the allow/block rules on the finance role, which bound which people can reach which tools.

Ramp does not document that an OAuth app's calls are narrowed to the authorizing person's role. In practice, treat the connection as carrying the admin's full reach unless scopes and restrictions say otherwise, and put the boundary where you control it. In Elaichi that is layers 2 and 3: the scope list on the OAuth app, and restrictions on the finance role.

## Setting up Ramp in Claude: does the connector want your own OAuth app?

Only if the connector's page shows the card. Most OAuth connectors in Elaichi connect through an operator-set default OAuth app that every organization inherits. Where a connector needs the organization's own app instead, its page carries a card titled **Add your OAuth application**. An admin holding `connector:manage` fills it in. Org Owner and Org Admin hold that permission by default. If the card is not there, skip this section and connect the account directly.

When the card is there, the order matters:

1. In Elaichi, open **Connectors** in the sidebar, open the Ramp connector, and press **Add OAuth app**. The **Redirect URL** field is read-only and has a copy button. Copy it now.
2. In Ramp, create a developer app. Ramp's pages give more than one menu path, so follow Ramp's current one (<https://support.ramp.com/accessing-the-developer-api>, checked October 2026). Paste Elaichi's Redirect URL wherever Ramp asks for a redirect URI. Ramp requires HTTPS and an exact match, so do not retype it.
3. Configure the app's scopes in Ramp. Start read-only, which is also Ramp's own advice (<https://docs.ramp.com/developer-api/v1/authorization>, checked October 2026).
4. Back in Elaichi, paste the **Client ID** and **Client secret**, type the scope list, and press **Save OAuth app**. The change is recorded as `connector.oauth_app.updated`.

Then the Ramp Admin or Business Owner connects the account in Elaichi. That person owns the connection. Pick an owner who is staying. When an owner leaves, Elaichi's offboarding lists every connection they own. A shared connection the team depends on is deleted only if an admin asks for that. Otherwise the admin transfers it to another member, which keeps every share as it was. The Ramp side still needs its own deprovisioning.

## Which Ramp read scopes to type, and why the box replaces the defaults

Type only the read scopes the team's questions need, and type the complete list. Elaichi's **Scopes** box is wholesale: left blank it keeps the scopes Elaichi requests by default, and a typed list replaces those defaults entirely. One scope per line, written exactly as Ramp writes it.

One caution follows from that. The console never shows the scopes Elaichi requests by default. So a typed list has to be complete. Include any non-resource scopes Ramp lists, such as `offline_access` if the app relies on refresh tokens. After saving, check that the connection still works once its first access token has expired.

Ramp's scopes come in `resource:read` and `resource:write` pairs, with no wildcard, and a token holds only the scopes it was issued with. For finance's read-only questions, the scope set generally looks like this. Confirm the exact names against Ramp's current authorization page before typing them:

| Question the team asks | Likely Ramp read scope |
|---|---|
| What did we spend with this vendor | `transactions:read` |
| Which bills are unapproved | `bills:read` |
| Who hasn't attached a receipt | `receipts:read` |
| What's outstanding in reimbursements | `reimbursements:read` |

Per Ramp, asking for a scope the app is not configured for fails at sign-in with `invalid_scope` (<https://docs.ramp.com/developer-api/v1/authorization>, checked October 2026). A call that needs a scope the token lacks gets a 403 from Ramp. Elaichi records that as a failed tool call with an error code. Nothing escalates to a broader scope automatically. The fix is always the same sequence: add the scope in Ramp, add it to Elaichi's list, reconnect. Copy the exact names from Ramp's authorization page rather than guessing from a pattern.

This is the hard edge of the whole setup. A write scope you never type cannot be talked back into existence by a prompt, a misreading, or a clever tool call. Adding approvals or reimbursement submission later is a deliberate act: a new scope in Ramp, the same scope added to Elaichi's list, and a reconnect.

## Which Ramp tools stay out of the finance role

Write one allow rule on the finance role naming Ramp's read tools. One consequence catches people out. Once the role holds an allow rule, every connector that no allow rule on the role names is denied for that role. That is not just Ramp's other tools. Allow rules on the same role add up. So give the finance role an allow rule for each other app it uses, naming a whole connector where that is fine. Otherwise the team loses those apps. The mental model is simple: **scopes bound the credential, restrictions bound the people.** Scopes are set once in Ramp and apply to everyone who shares the connection. Restrictions are set in Elaichi, target a role or a user, and can change without touching Ramp at all. A restriction change takes effect within about two minutes. In Elaichi, restriction targets are role or user only; the organization default is the absence of a rule, which means allow everything.

Two traps decide whether the rule does what you meant:

- **An allow rule that names nothing denies everything.** In Elaichi, the allowlist stage engages on the presence of an allow rule, not its contents, so an allow rule that names nothing denies everything. Leaving the tool list blank locks out the whole finance team.
- **An allow rule that names the Ramp connector as a whole *and* some of its tools reaches all of Ramp.** The tool entries grant nothing once the connector-level entry is present. Name the tools, or name the connector, not both.

Blocks always beat allows. A withheld tool is invisible, missing from the tool list and from search alike. So an analyst who asks Claude to approve a transaction gets no such tool rather than a refusal message.

One correction catches people out at the consent screen: unticking **Create and change data** does not make Ramp read-only. That checkbox governs Elaichi's own operations. For a connected app, **Run your connected tools** runs reads and writes alike, and only a delete costs the destructive scope. Read-only access to Ramp is the scope list plus a restriction, never a consent checkbox. The matching rules are worth reading once in [how blocks and allows resolve differently](/blog/block-matches-name-allow-matches-operation/). The wider pattern is in [least privilege without breaking the work](/blog/least-privilege-tool-calls-without-breaking-automation/).

## Adding the one endpoint in Claude, and what the trail shows afterward

There is one address for the whole organization: `POST https://api.elaichi.ai/mcp`. No per-user URL, no token to paste. On Claude Team and Enterprise, an Owner or Primary Owner adds it under Organization settings, then Connectors, Add, Custom, Web. Members then enable it under Customize, Connectors and sign in with their own grant. On Pro and Max it is Customize, Connectors, "+", Add custom connector (<https://support.claude.com/en/articles/11175166>, checked October 2026).

Each analyst signs in once, picks the organization, and leaves **Run your connected tools** ticked. Delete is never pre-ticked. Claude's per-connector tool permissions land on Elaichi's `execute_tool`, a single permission that gates every connected tool at once, regardless of which app it belongs to. That is exactly why the per-tool boundary for Ramp has to live in Elaichi's restrictions and not in Claude's own settings. Claude's settings cannot distinguish a Ramp read from a Ramp write. The two places an admin approves apps are compared in [approving apps for Claude across a company](/blog/approve-apps-employees-connect-to-claude/).

Afterward, Elaichi writes one entry per tool-call attempt, succeeded or failed. The audit trail is the append-only record of what ran. It names the Ramp account actually reached, the operation and tool, whether approval was needed, the outcome, and an error code. Argument names and counts are recorded; argument values never are, so a transaction amount does not end up in the log. The entry carries the surface (`mcp`) and the client, and Claude's name is marked verified by its redirect URIs. A call from Claude is recorded with the person as the actor, not as an assistant. An Auditor seat to read it is free. [What belongs in an agent's audit record](/blog/what-an-ai-audit-log-must-capture/) goes into the fields themselves.

## When Ramp's own hosted MCP server is the better fit

When each person only needs their own Ramp data. Ramp hosts its own MCP server at `https://mcp.ramp.com/mcp`, labeled "Ramp MCP is in Beta" in Ramp's docs, with OAuth sign-in. Employees see only their own data, and admin tools require Admin or Business Owner. Admins grant access at Company, Integrations, Ramp MCP, Manage Access (<https://docs.ramp.com/developer-api/v1/ramp-mcp>, <https://support.ramp.com/ramp-mcp>, checked October 2026). Custom clients and gateways need their redirect URI allowlisted by Ramp first.

The two paths solve different problems, not the same problem with different branding:

| | Ramp's hosted MCP | Elaichi as control plane |
|---|---|---|
| Data scope per person | Each person's own Ramp role, enforced by Ramp | Whatever the admin's connection carries, narrowed by Elaichi's restrictions |
| Cross-app view (Ramp + Xero + Slack, etc.) | No, Ramp only | Yes, one address and one restriction set per role |
| Second vendor in the path | None | Elaichi sits between Claude and Ramp |
| Audit trail | Not described on Ramp's MCP pages | One trail across every connected app |
| Offboarding | Deprovision in Ramp or your IdP | removing or suspending a member revokes every live grant in the same transaction as the membership change, and the Ramp account still needs separate deprovisioning |
| Best fit | "Where are my own receipts," "what did I spend" | "What did the team spend with this vendor," shared operational questions no single analyst's Ramp role answers |

If the question is personal, "where are my own receipts," "what did I spend," Ramp's server is the better fit. There is no second vendor in the path. Elaichi is the better fit when the question is operational and shared. Use it when no single analyst's Ramp role covers the question. Use it when Ramp needs to sit beside Xero, Slack, or Salesforce on one address with restrictions written once per role. Use it when one audit trail has to cover every app a finance analyst touches in Claude.

For the wider shape of this, read [what an MCP control plane is and who needs one](/blog/what-is-an-mcp-control-plane/). The same playbook for a different ledger is in [keeping Claude out of your Xero invoices](/blog/finance-team-claude-xero/). The choice between a whole-app and a single-tool rule is worked through in [six cases for per-tool restrictions](/blog/per-tool-vs-per-app-restrictions/). The [Ramp connector](/connectors/ramp/) sits with the rest of the catalog under [connectors](/connectors/).

## FAQ

### Can a finance analyst use Ramp in Claude without a Ramp admin seat?

Yes. Ramp documents that only users with Developer API authorization permission, typically Admin and Business Owner, can authorize a developer app (docs.ramp.com/developer-api/v1/authorization, checked October 2026). In Elaichi, that admin connects the Ramp account once and shares the connection with the finance team at use level. A shared connection runs on its owner's credential, so analysts call Ramp without holding a Ramp admin seat, and without ever seeing the credential.

### How do you make a Ramp connection read-only for a team?

In two layers. First, configure only read scopes on the Ramp developer app, since Ramp scopes come in resource:read and resource:write pairs with no wildcard, and type that same complete list into Elaichi's Scopes box, because a typed list replaces Elaichi's defaults wholesale. Second, write a restriction on the finance role allowing only Ramp's read tools. Unticking "Create and change data" on Elaichi's consent screen does not do this: for a connected app, "Run your connected tools" runs reads and writes alike.

### How long does a Ramp restriction change take to apply in Elaichi?

A role or restriction change takes effect within about two minutes. Role membership and restriction changes resolve through a short cache plus edge propagation on every surface, MCP clients and the console alike. Some changes are faster: revoking a share and disconnecting an account take effect on the caller's next request, because the grant and the connection are read fresh on every call. In Elaichi, removing or suspending a member revokes every live grant in the same transaction as the membership change.

### Should a company use Ramp's own hosted MCP server instead?

Use Ramp's hosted server when each employee only needs their own data. It sits at https://mcp.ramp.com/mcp, is labeled a beta in Ramp's docs, signs in with OAuth, and scopes each person to their own Ramp role, with admin tools requiring Admin or Business Owner (docs.ramp.com/developer-api/v1/ramp-mcp, checked October 2026). A control plane such as Elaichi is the better fit when a team shares one admin-authorized view, when Ramp is one of several apps behind one address, or when one audit trail has to span all of them.

### Who can add the organization's own OAuth app to a connector in Elaichi?

An admin holding the connector:manage permission, which Org Owner and Org Admin hold by default. The card is called "Add your OAuth application" on the connector's page, and it appears only where the connector needs the organization's own app or one is already stored. The Redirect URL field is read-only with a copy button; paste it wherever the provider asks for a redirect URI. Changes are recorded in the audit trail as connector.oauth_app.updated.

## Read next

- [Xero in Claude, without letting it edit invoices](/blog/finance-team-claude-xero/) — Xero in Claude for a finance team: analysts read invoices and reports, and no assistant can edit or void an invoice unless one named person is allowed to.
- [QuickBooks read-only for a finance team in Claude](/blog/finance-team-claude-quickbooks-read-only/) — QuickBooks has no read-only OAuth scope, so QuickBooks read-only has to be enforced by whatever calls the API. Here is how to do it with one restriction.
- [Restrict one AI tool or the whole app? Six cases](/blog/per-tool-vs-per-app-restrictions/) — Restrict one AI tool when a role needs part of an app, and block the whole app when it needs none of it. Six cases, and what new tools do to each rule.