Why recruiters want Ashby inside ChatGPT
Recruiters want it because most of what they ask an applicant tracking system is a reading question. Where is this candidate, which interviews are unscheduled, which requisitions have nobody at onsite this week. Those answers sit in Ashby, and the recruiter is already typing in ChatGPT.
The risk sits in the same tool list. An app that can read a candidate record can usually also move it, reject it, or delete it. So when you connect Ashby to ChatGPT for recruiters, the real question is not whether the model can read. It is what stops it writing.
This playbook covers the connection and the two restriction rules that hold the recruiting role to reads. It ends with the audit query a reviewer runs afterwards to show nothing changed.
How to connect Ashby to ChatGPT for recruiters
You add Elaichi to ChatGPT once as a custom app, and each recruiter signs in with their own account. There is no Ashby-specific address to hand out. Elaichi serves MCP at one endpoint, https://api.elaichi.ai/mcp, and that same address serves every organization. MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps.
Ashby is one connector in Elaichi's catalog of 650+ connectors, listed at /connectors/ashby/. An endpoint here means one HTTPS address a client posts to.
On ChatGPT Business, only admins and owners can enable developer mode and deploy a custom MCP app. They create one from Workspace settings, then Apps, then Create (OpenAI's developer mode and MCP apps page, checked October 2026). OpenAI also warns on that page that functionality, UI and permissions may change as it iterates. Date any menu path you write into a runbook. The client-side detail is covered in the ChatGPT setup walkthrough.
The order that saves rework is: plan, restrictions, connections, then clients. Elaichi's MCP endpoint is paused unless the organization has an active Gold or Black subscription. Governance restrictions come with both plans.
Why consent alone will not keep it read-only
No consent checkbox holds a client to reading a connected app. On Elaichi's consent screen, "Run your connected tools" covers running every tool the person can reach in Ashby, writes and deletes included. "Delete data and remove access" covers Elaichi's own records and people, not Ashby's. Unticking "Create and change data" does not make a connected app read-only either.
The client's own per-app control does not fix this from the outside. ChatGPT's app permission options are Always ask, Allow read actions, Allow low-risk actions and Allow all actions (OpenAI's app permissions article, checked October 2026). Those act on the tool names a server advertises, and with Elaichi connected tools are never listed one by one, however few there are. The model finds a connected tool with search_tools and runs it with execute_tool. execute_tool is never marked read-only. A read-only client setting therefore prompts on every Ashby call, reads included, rather than holding Ashby to reads.
Other clients land in the same place. Codex prompts for any tool not marked read-only, set per server with default_tools_approval_mode (OpenAI's Codex MCP docs, checked October 2026). Cursor asks for approval before using MCP tools by default (Cursor's MCP docs, checked October 2026). Neither prompt can tell one connected app from another.
The layer that can tell one Ashby tool from another is a restriction in Elaichi. A restriction is a rule that says which connectors and tools a role, or one named member, may reach.
Restriction one: block the Ashby tools that change records
Write block rules on the recruiting role naming every Ashby tool that writes or deletes. A block beats an allow inside the same layer. A block also matches a tool by name or by the operation it performs, so renaming one cannot slip it past.
Get the names from the console. Open the Ashby connector and read its tool list, which shows every tool with a restricted flag for the person reading it. Sort the list into reads and everything else, then name everything else in the rule. One rule can carry up to 1,000 connectors and 1,000 tools.
The other shape is an allow rule naming only the Ashby read tools. It carries a trade-off. An allow rule turns on an allowlist for its whole layer just by existing. Once the recruiting role has one, every connector and tool its allow rules do not name is blocked for that role. That holds across all connectors, not only Ashby. So an allow rule for Ashby also needs allow rules for every other app recruiting uses. A block-only layer fails the other way: anything it does not name stays reachable. So the block list has to be complete. The mechanics are set out in why blocks match names and allows match operations.
Two things to expect. A restriction change applies within about two minutes. And a blocked tool is not invisible: search_tools still names it, flagged as restricted and with no schema. The refusal tells the recruiter an admin can lift it through an access request. Approving one creates an access grant for that single person. No console screen or API route lists or revokes grants afterwards, so treat an approval as a lasting decision.
Restriction two: keep Ashby off every other role
When no restriction rule reaches a member, nothing is restricted for them. A Member, the base paid role, holds the permission to create personal connections. So anyone in the organization can connect Ashby with their own account unless a rule says otherwise.
So write a block rule naming the whole Ashby connector on each role that is not recruiting. In Elaichi, restriction targets are role or user only; the organization default is the absence of a rule, which means allow everything. A rule aimed at one named member also needs the override permission. A rule aimed at a member can only narrow what their role allows, and never replaces or loosens a role rule.
Blocking a connector whole also blocks every fork that declares descent from it, walking the lineage up to eight hops. It does not block a connector someone builds from scratch against the same API. A connector's identity is its slug and its declared lineage, never the host it calls. That is why Elaichi flags the permission to create connectors as high trust. Among the system roles, only Org Owner and Org Admin hold it. Role shapes for this are covered in designing roles for AI agents.
Whose Ashby account does the call run as?
The account that connected it. Every call through a connection fetches that connection's own stored credential, whoever is calling. A shared Ashby connection runs every recruiter's call as its owner. If one coordinator connects Ashby and shares it with the team, the whole team reads Ashby with that coordinator's permissions.
For per-person reach, each recruiter connects Ashby themselves. The repeatable way is a template. Build one and share it at use. Each recruiter then stamps their own toolbox and picks their own Ashby connection, the same pattern as per-person Dropbox connections in ChatGPT. A toolbox is a named list of tool entries. Sharing a template creates no toolbox for anyone. A toolbox shared with a team runs each entry on the connection pinned in it, under the authority of whoever pinned it.
That delegation has an offboarding consequence. If the person who pinned a connection stops being an active member, those entries resolve as unmet for everyone, the toolbox owner included. They stay that way until somebody with edit access re-pins them. Removing or suspending a member also revokes their grants in that organization, and their clients fail on the next call. See offboarding AI access for the full order of operations.
If one entry should always run with the same argument value, locked-in values on a toolbox entry do that. The AI client cannot change them. The caveat: anyone who can use the connection themselves also has the same tool without the lock. Locking AI agent tool arguments covers that case.
The audit query that proves the recruiter role only read
Open the audit log, filter the category to Assistant, search the connector name, and set the date range to the last 30 days. Connected-tool calls sit in the Assistant category because their action is assistant.toolbox_tool. The MCP category holds client grants, not tool calls. The audit log here means the per-organization record of what ran.
Each row's detail panel carries the two lines a reviewer needs. "What it did" reads Read data, Changed data or Deleted data, taken from the tool's recorded classification. The Approval line on a read reads "Didn't need approval because it only read data". A call from a client reads "Allowed by the access ChatGPT was granted". The summary sentence names the surface, the person, the item and the connection.
The proof of restriction one is that no Ashby row in the window reads Changed data or Deleted data. Export the filtered view as CSV for the evidence file. An export stops above 10,000 entries rather than saving a partial file.
One honest limit. A call a restriction refused writes no audit row, because the refusal happens before any executor runs. So the log shows what ran, not what was stopped. Pair it with the restriction's own rows, restriction.created and restriction.updated, which record when each rule was written and by whom. Reading every event in the organization needs the audit permission. Org Owner, Org Admin and the free, read-only Auditor role hold it. Without it, a member sees their own events plus events on connections they own or can edit. Elaichi keeps 90 days of audit history, and export to your own Datadog comes with the Black plan, which is launching soon. The wider list of what a record should hold is in what an AI agent audit log must capture.
When a restriction set is more than you need
One recruiter, one app, read-only questions, no compliance ask: you do not need any of this. Connect the app directly and move on. If Ashby publishes an MCP server of its own, check Ashby's documentation first. That path adds no second vendor and runs inside Ashby's own permission model.
The case for routing Ashby through Elaichi starts when recruiting is one team among several, each with several apps. The answer to "who touched which candidate" then has to come from one place, not from each vendor's own log. That is the argument in MCP governance, and the honest counter-argument is in when you don't need an MCP gateway yet. The nearest sibling playbook, if HR is next on the list, is reading Rippling in Claude without running payroll.
