Why a Gusto connection is always an admin's
An HR lead asks for Gusto in Claude so they can stop exporting a CSV every time somebody asks who reports to whom. The access problem arrives before the setup does. Gusto vets and approves every app that reaches its API and gives customers no direct API access for their own systems (support.gusto.com, read October 2026). Only primary or full-access admins can authorize an app, and each token covers one company (docs.gusto.com, read October 2026). Gusto assigns an app's scopes during that review and rejects calls outside them (docs.gusto.com, read October 2026).
So there is no narrow Gusto login to hand a recruiter. Whoever authorizes the app does it as an admin. The real question is what each person on the HR team reaches through that one connection.
Two field-level details matter before anyone asks about sensitive data:
- Pay rate. Compensation fields return only to an app holding the
compensations:readscope. - SSN. The employee
ssnfield "always returns an empty string" regardless of scope (docs.gusto.com, read October 2026). Gusto's API does not expose it to any third-party app.
Elaichi's console does not show which scopes Gusto granted Elaichi's app. If you vet any Gusto-connected tool, Elaichi's included, ask the vendor which scopes Gusto granted its app at review. Don't infer it from the feature list.
Inside Gusto's own console, the access lines are drawn differently from API scopes. SSNs are visible only to All-access admins, and people managers never see SSNs or bank details (support.gusto.com, read October 2026). Gusto's developer docs do not say whether app data is filtered by the authorizing admin's console role. Only a primary or full-access admin can authorize the app. So plan as if the connection reaches what such an admin reaches, within the scopes Gusto granted. That's why the cuts for an AI tool have to be made somewhere else: in the connecting app's own scopes, or in a policy layer sitting in front of it.
When Gusto's own MCP server is the better answer
Gusto runs its own MCP server at mcp.api.gusto.com. Admins pick data categories when connecting it (gusto.com, read October 2026). Gusto states that an AI connection reads only what the authorizing user can see in Gusto (gusto.com, read October 2026).
That's a real, usable option. Here's the actual trade-off, stated plainly rather than as a sales pitch:
| If your HR team... | The better fit is |
|---|---|
| Only needs Gusto in Claude, nothing else | Gusto's own MCP server: one vendor, Gusto's native permission model, no second system to administer |
| Also needs Slack, a project tracker, or a document store in the same chat | A control plane like Elaichi: one address, one place to write per-role rules, one audit trail across every app |
| Wants to run payroll from a chat window | Elaichi's gusto connector has no payroll-run tools; check the tool list of Gusto's own server before assuming either way |
| Needs per-role cuts inside HR (e.g., recruiters blocked from home addresses and terminations, but HR generalists not) | Elaichi, or any layer that can restrict at the tool level per role. Gusto's own server takes data categories at connection time and reads what the authorizing user can see |
Elaichi is a governed MCP control plane. MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps. In practical terms for this comparison: every connected app sits behind one organization-wide address. Restrictions are written once per role and apply across all connected apps at once. Every tool call, Gusto or otherwise, lands in one audit trail. Removing someone from Elaichi ends their access through Elaichi only. Their underlying Gusto account still exists and has to be deprovisioned separately, in Gusto or through your identity provider.
Gusto in Claude: the share is the first gate
One HR admin connects Gusto once in Elaichi and shares that connection with the HR team at use. That share is the access boundary for Gusto in Claude. A member sees only what they own or what was explicitly shared with them. No organization-level permission widens that listing, owners and admins included.
A shared connection runs on its owner's credential. Every HR member's call reaches Gusto as the connecting admin account; no grantee can open, see, or re-share the credential itself. The opposite shape is worked through in Salesforce access per rep in ChatGPT. There, each person connects their own account and the app's own permissions draw the line. Grants and connections are read fresh on every call. So revoking a share takes effect on that person's very next request, with no propagation delay to account for.
The second gate closes a side door the first gate leaves open. Any other primary or full-access Gusto admin in your company could connect their own Gusto account independently and bypass the share entirely. Write a block rule naming the gusto connector whole for every role outside HR. In Elaichi, restriction targets are role or user only; the organization default is the absence of a rule, which means allow everything. So each role carries its own rule. Elaichi checks restrictions at browse, connect, advertise and execute, plus a final check on the fully substituted outbound URL. A blocked connector cannot be connected, and its tools are never advertised to that role. A restriction change takes effect within about two minutes.
What to cut inside the HR team
Finer cuts inside HR are restrictions per role, written as blocks on individual tools. A recruiter role, for example, takes blocks on the home-address reads, the termination reads, and the benefit tools, while keeping employees, departments, and work addresses. A blocked tool is invisible to the model. It reaches neither the tool list nor search, so the model never learns it exists to try calling it.
Use blocks here, not an allow rule, and the reason is structural, not stylistic. An allow rule becomes that role's entire allowlist across every connector the role uses, not only Gusto. A recruiter role given one allow rule for a handful of Gusto reads loses every other connected app. That holds unless each of those is separately named in an allow rule too. The case where an allow rule is the right instrument is worked out in holding a help desk to Intune reads. There the connector carries far more writes than reads. Blocks only subtract from an otherwise-full set of permissions; blocks beat allows wherever both apply to the same tool. A rule on a user replaces the role rules for that user rather than adding to them.
The reasoning behind the block/allow asymmetry sits in why blocks match tool names but allows match the operation. The choice between a tool-level block and a whole-connector block is worked through in six cases for per-tool versus per-app rules. How the roles themselves get drawn in the first place is in designing roles for AI agents.
What the Gusto connector carries
Elaichi's gusto connector connects via OAuth, through Elaichi's own registered app with Gusto. OAuth is the browser sign-in that hands Elaichi a revocable grant instead of a stored password. It carries 22 tools total: 17 read, 5 write, 0 payroll-run.
Read tools (17), by category:
| Category | What it reads |
|---|---|
| Identity | The signed-in user |
| Company | Company record, custom fields |
| Org structure | Departments |
| Benefits | Company benefits, employee benefits, benefit types |
| People | Employees, terminations, contractors |
| Addresses | Home addresses, work addresses |
| Webhooks | Webhook subscriptions |
Write tools (5), named explicitly:
| Tool | Does |
|---|---|
create_a_gusto_employee_benefit |
Adds a benefit enrollment for an employee |
update_a_gusto_employee_benefit_by_id |
Modifies an existing employee benefit record |
create_a_gusto_webhook_subscription |
Registers a new webhook |
delete_a_gusto_webhook_subscription_by_id |
Removes a webhook |
gusto_webhook_subscription_verify |
Verifies a webhook subscription |
An HR team that only looks things up blocks all five write tools by name. The same restriction-not-scope route is the only one available in QuickBooks, which ships no read-only accounting scope at all. See QuickBooks read-only for a finance team.
One trap to name explicitly: leaving "Create and change data" unticked on Elaichi's consent screen does not make Gusto read-only. That checkbox governs Elaichi's own internal operations, not what a connected third-party app's tools can do. For a connected app like Gusto, the single "Run your connected tools" permission covers reads and writes alike. Only a destructive delete call requires the separate destructive-action checkbox on top. Read-only Gusto access is achieved through a restriction (blocking the 5 write tools), never through a consent-screen toggle. The other 600+ connectors are in the connector catalog.
Adding the endpoint in Claude
The address is https://api.elaichi.ai/mcp for every organization, with no per-toolbox URLs and no tokens to paste. On Claude Team and Enterprise, an Owner or Primary Owner adds it under Organization settings, Connectors, Add, Custom, Web. Members then connect it under Customize, Connectors (support.claude.com, checked October 2026).
Each HR member signs in once through Elaichi's consent screen. The client registers itself, so there's no client ID or secret to enter manually. The person picks their organization; every scope the client requested is pre-ticked except delete, which is never pre-ticked by default. With "Run your connected tools" ticked, a second step offers All my tools or only chosen toolboxes. All my tools includes the shared Gusto connection, the setting you want here. It automatically picks up any connections shared with that person later, with no re-authorization needed.
One structural limit: Claude's own per-connector tool permissions cannot separate one connected app from another. Elaichi's connected tools all run through a single execute_tool function. So any Claude-side permission set on that tool applies to every connected tool at once, Gusto included (claude.com, checked October 2026). That's the concrete reason the per-role cuts described above have to be written in Elaichi rather than in Claude's native connector settings. Claude has no mechanism to grant Gusto-read but not Slack-write at the per-tool level. Connected tools also never appear in Claude's static tool list; the model finds them at runtime with search_tools and runs them with execute_tool. When an HR member reports a missing tool, start with the missing-tool checklist. Step-by-step client setup is in connecting Elaichi to Claude.
What one Gusto tool call leaves behind
The audit log is the append-only record of who did what. Elaichi writes one entry per tool-call attempt, succeeded or failed. Employee data does not land in the trail: argument values are never logged, and the record holds call metadata, not the response.
The entry also records the surface and the OAuth client. So an HR lookup made from Claude is attributed to the specific member who asked, routed through Claude, not to a shared service account. The trail is eventually consistent, so a row may take a moment to appear after the call completes. Audit logging is part of the Gold plan; forwarding it to your own Datadog comes with the Black plan, launching soon.
Who owns the Gusto connection when that admin leaves
The connection owner is an admin, which makes offboarding the part teams forget. When that admin leaves, Elaichi's offboarding preflight lists every connection they own, shared ones included, so it isn't discovered after the fact. Transfer the Gusto connection to an HR admin who is staying. A transfer sets a new owner and keeps every share on the connection. The credential behind it is still the departing admin's Gusto sign-in, though. So before that Gusto account is deprovisioned, have the staying HR admin connect Gusto with their own admin account. Then share that connection with the HR team.
Transferring the connection in Elaichi does not touch the underlying Gusto account. The credential behind the connection is still the original person's Gusto sign-in. So that account still needs its own deprovisioning directly in Gusto or through your identity provider. Pick the admin who will own the connection going forward before anyone hands in notice, not after. The wider version of this problem, any connection, any app, is in offboarding when the agent holds access.
The same shape applies to an HR team on a different payroll system; see reading Rippling in Claude. Other teams and the apps they run are listed on the use cases page.
