HR can read Rippling in Claude, not run payroll

What can HR do with Rippling in Claude?

HR can read Rippling in Claude through Elaichi, and cannot run payroll from it. The questions HR asks are lookups: who reports to whom, which department and work location a person sits in, which employment type a contractor is on. Elaichi's Rippling connector answers them with read tools such as list_all_rippling_workers. It has no tool that runs payroll or terminates a worker, so neither can happen through it, whatever a prompt says.

The writes the connector does carry are narrower. They create, change and delete custom objects and their records, add and remove business partners, and change supergroup membership. One allow rule on the HR role keeps all of them out of reach. Rippling sits in the HRIS category with the other HR systems Elaichi connects.

MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps. Elaichi serves Rippling's tools from one organization-wide MCP endpoint, POST /mcp, behind OAuth (the sign-in flow that gives a client a scoped grant instead of a password). In Claude Team and Enterprise, an owner adds that address once under Organization settings > Connectors. Each HR member then connects it under Customize > Connectors and signs in with their own grant. On Pro and Max, each person adds it under Customize > Connectors (Claude's help center, as of October 2026). Rippling is a connector Elaichi authors, maintains and serves from its own infrastructure, one of 600+ in its catalog.

How do you set up Rippling in Claude for an HR team?

Connect Rippling privately, check the HR role, write the rule, pin the reads into a toolbox, and only then share the toolbox. Sharing comes last because, until a rule exists, the default is allow-all.

1. Connect the Rippling account and keep the connection private. Calls through a shared connection run on its owner's Rippling account, so Rippling sees and logs that one user for the whole team. Connect it with an account whose Rippling permissions fit everyone it serves, and who will stay. Credentials never live in Elaichi. A separate credential service holds per-account secrets, AES-256-GCM at rest, and owns refresh. A failed refresh marks the connection needs_reauth rather than failing quietly.
2. Check the role. Every member carries exactly one role, enforced by a unique index, so the HR role is a complete persona rather than an add-on. It needs tool:execute, which gates the whole endpoint ahead of every other check. Without it, tools/list comes back empty and a call returns an in-band error naming the permission.
3. Write the rule. A restriction is a rule about which connectors and which individual tools a target may reach. In Elaichi, restriction targets are role or user only; the organization default is the absence of a rule, which means allow everything.
4. Pin the reads into a toolbox, freezing any argument the model should not choose.
5. Share the toolbox with the HR team, with use. Sharing is one building block: a grant of view, use or edit, given to one user, one team or everyone in the organization. A member sees only what they own or what was shared with them, and no organization-level permission widens that, owners and admins included.
6. Add the endpoint in Claude and have the HR team sign in.

If the HR group already lives in your identity provider, SCIM v2 can provision its members and map the group to the HR role.

One caution on step 3. A rule aimed at a member can only narrow what their role allows, and never replaces or loosens a role rule. A rule for one HR manager can narrow what the HR role allows and cannot add to it. To let one person past a role rule, they file an access request and an admin approves it.

Should HR allow Rippling's reads or block its writes?

Allow the reads. An allow rule naming the people reads, such as list_all_rippling_workers, list_all_rippling_departments and list_all_rippling_teams, shuts out everything it does not name. That covers every write on the connector. Any tool the connector gains later also stays closed for HR until someone adds it on purpose, which is the property a promise about payroll needs.

One caveat before you save it. Once the HR role holds an allow rule, every connector that no allow rule on that role names is denied for the role, not only Rippling's other tools. Allow rules on the same role add up, so give the HR role an allow rule for each other app it uses, naming the whole connector where that is enough, or the team loses those apps.

The cost is upkeep, plus one sharp edge. Each new read HR wants is one more entry in the rule. And the allowlist stage engages on the presence of an allow rule, not its contents, so an allow rule that names nothing denies everything. After saving, ask Claude to find one of the reads to confirm it is still there.

Know what a read returns, too. The list_all_rippling_workers tool returns each worker's compensation and termination details along with title and manager. Share the toolbox only with the people who may see pay. Rippling sees every call as the connection owner's account, so choose an owner whose Rippling permissions fit the whole team. Elaichi's rules narrow what HR reaches; they never widen it past what the Rippling account behind the connection allows.

A block list is the other shape. Block the writes by name and leave every read open, including reads the connector gains later. The mirror-image cost is that a write added later stays open until someone blocks it. Blocks still help as a backstop: they always beat allows within a layer, so a block holds even if someone later widens the allow rule.

The two rule types also match differently. A block matches on the tool name or on the pinned operation, the canonical action under the name, while an allow matches on the pinned operation only. Whoever edits the connector's documentation can change a tool's advertised name, so the name is a token the governed party controls. The reasoning behind that split matters most for long rule sets.

OAuth scopes add a second layer. A delete such as delete_a_rippling_custom_object_record_by_id also needs mcp:destructive on the grant, and a tool classified forbidden is reachable under no scope.

Can HR see the withheld Rippling tools in Claude?

Only by name. Elaichi checks the rule at every place a member can reach a connector or tool, including listing, connecting, advertising, executing, the final outbound-request check and opening a stored tool file. A tool the HR rule withholds is left out of the tool list and cannot be called. If Claude searches for it, Claude sees the name, flagged restricted, with no schema. The model cannot be talked into running it.

In MCP, a client learns what a server offers by sending a tools/list request. The specification lets that list vary with the authorization on the request (MCP specification). In Elaichi, connected tools are never listed one by one, however few there are. Claude looks a Rippling tool up with search_tools and calls it through execute_tool, and a withheld tool comes back from that search only by name, flagged restricted.

Search has a relevance floor, so a weak match returns nothing rather than a tool from an app you did not ask about. The reasoning behind the floor is written up separately.

Which Rippling arguments should HR freeze?

Freeze any argument whose value should be settled before the model sees the tool. Frozen parameters are a per-entry map over a tool's flattened argument space, set on a toolbox entry (one tool tied to one connected account). A frozen key is removed from the schema Claude is shown, so there is nothing for the model to fill in. A frozen value is merged over the caller's arguments at execution, so passing the key anyway cannot un-freeze it. The order runs entry defaults, then caller and model arguments, then frozen parameters, and the frozen value wins.

Custom objects are the clearest HR case. If you keep HR data in a Rippling custom object, allow list_all_rippling_custom_object_records and freeze its custom_object_api_name to that one object. HR then reads that object's records, and no question can widen the read to every custom object in the account.

The lock belongs to the toolbox entry, so it holds only for calls made through that entry. If HR also has use on the Rippling connection itself, the unfrozen tool is reachable directly. That is why the Rippling connection stays private and only the toolbox goes to HR.

How do you prove no AI client changed anything in Rippling?

Filter the audit trail. It holds one entry for each connected-tool call that reaches execution (a call refused earlier writes none). The connection on every entry is the account the call reached, read from what executed rather than from what was requested. That matters the day an unexpected change shows up and you run two Rippling environments.

Each entry carries the operation and tool, the connection, the classification and whether the call was approved, with its outcome and an error code when it failed. The trail logs the one path argument that names the object, as the target id, and nothing else about the arguments, so a worker's details passed into a call stay out of it.

The actor_kind field is recorded, not inferred. Its values include user, system, staff, scim, api_token and ai_assistant, which marks only the Elaichi Agent. A call from Claude is recorded under the person who signed in, with surface mcp and the OAuth client named, and Claude is marked verified. "Did Claude change a record" then has an answer in the entry rather than an argument.

To produce the evidence, filter by connection, action kind and time range. The trail is append-only, newest-first and cursor-paginated, and it also filters by free text, category and actor. A departed member shows as "Former member" rather than vanishing. It is eventually consistent, so pull the report after the fact rather than mid-call. Give the reviewer the Auditor role, a free read-only seat that lacks tool:execute, so no tool call is possible from it. The trail inside Elaichi is on Gold. Beyond the in-app trail, export to your own Datadog comes with the Black plan, which is launching soon.

Does the employee data stay in the EU?

Partly. Elaichi has three regions, eu, us and apac. For an eu organization, the data store and the execution of its org-scoped requests and tool calls are pinned to the EU. User accounts, sign-in sessions, API tokens, SSO settings and MCP OAuth token records are kept globally. Every organization's audit trail, whatever its region, is stored in one log instance in the EU, and files stored from tool results go to one private EU bucket. Connections created since 2026-10-05 have their credentials placed in the organization's region. Older connections stay where they were until reconnected.

Pick the region when you create the organization, because it cannot change later. Where Rippling keeps its own records is Rippling's setting, not Elaichi's.

Why not use Rippling's own MCP server?

If Rippling is the only app HR will reach from an AI client, Rippling's own server may be the simpler choice. Rippling calls it "a first-party Model Context Protocol (MCP) connection" (Rippling's MCP overview, checked October 2026). It works "while strictly enforcing your company's security policies and role-based permissions". The server is hosted by Rippling and exposes "curated, approved tools". Its MCP Gateway is "the admin control panel for who can connect to the Rippling MCP and which tools they receive access to". That is Rippling's own permission model, with no second vendor to review.

Elaichi earns a place once HR works in more than one app. One address serves Rippling, Greenhouse and Slack, in Claude, ChatGPT and Cursor alike. A single set of rules on the HR role covers all of them, and a frozen argument can pin any tool's input. The audit trail spans every connected app, and removing a person ends their access through Elaichi to every one of those apps at once. Their accounts inside each app are a separate step. Rippling's overview does not describe those cross-app pieces, and they are what a second vendor has to justify.

What does this setup not prove?

It governs the MCP path and nothing else. Someone who signs into Rippling's own web app and runs payroll there leaves a record in Rippling, not in Elaichi. If your control objective is "nobody ran payroll", you need both trails. If it is "no AI client ran payroll", the Elaichi trail answers it on its own.

The prompt-injection write gate lives in the Elaichi agent window and does not apply to a raw tool call. What the endpoint does enforce is narrower: permission checks per operation, the forbidden classification, redaction of output, limits set by OAuth scopes, and an audit row for each call that reaches execution.

Timing is the fact most often stated wrongly. A role or restriction change takes effect within about two minutes, on MCP, console and REST alike. Grant revocation, member removal and suspension are effective on the next call. Tell the HR lead two minutes.

When is a control plane too much for HR?

If one HR person uses one Rippling login and no other app is connected, none of this earns its upkeep. Rippling's own server, or no AI client at all, is a smaller problem than a control plane nobody owns. The same holds when the assistant only needs a read-only handbook and touches nothing that can change state.

The case for holding off on a gateway is real, and it reads best before a rollout rather than after one. Governance starts paying when a second system joins, when more than one person holds the credential, or when someone outside HR has to answer what the assistant did.

What happens when someone leaves the HR team?

Their access ends on the next call. In Elaichi, removing or suspending a member revokes every live grant in the same transaction as the membership change. The grant's revoked_at flag is re-read from the organization store on every call, so a removed or suspended member's next call fails.

Removal also runs a preflight. It lists every connection the departing member owns. A private connection a shared toolbox relies on blocks the removal until an admin transfers it to one other active member, never to the admin running the removal, or deletes it. A private connection that nothing beyond the member depends on cannot be transferred and is deleted with them. A shared connection the HR team still depends on is deleted only if the admin explicitly asks, so transfer it to someone who is staying, which leaves every grant on it as it was.

A move sideways, from HR into a narrower role, is a role change. Budget about two minutes for it rather than the next call.

For the same setup on the revenue side, see how a sales team gets scoped Salesforce access in ChatGPT. For the harder version of the leaver question, read the contractor access walkthrough. The full catalog is at /connectors/, and the other eleven teams are mapped at /use-cases/.