Engineers using ChatGPT at work are already pasting stack traces and log lines into it, so the choice in front of you is whether to block it or scope it. A block holds on the managed browser and the corporate sign-in, and fails on a phone, a personal account and the assistant inside the editor. Scoping means giving the assistant governed, audited access to the systems engineers already query, so the clipboard stops being the fast path. A block still has a place, as a short holding measure while that is built.
Start with the artifact. An engineer hits a nil dereference in the checkout service at 2am. They copy the stack trace out of the log viewer and paste it into an assistant, asking why the frames are ordered the way they are. The trace carries three things beyond the error. A production customer ID sits in a frame argument, an internal hostname in the connection string, and a query fragment names a table.
None of that was the question. All of it left with the question. The paste happened for a boring reason. Reading the log needed a VPN session and a saved search, and reading the explanation needed a tool that is not in the log viewer. A clipboard closed the gap.
What does a pasted stack trace leak?
Whatever happened to sit on the frame, and nobody picked those fields. The engineer picked the question. The customer ID, the hostname and the table name came along because they were in the buffer.
Three properties make a paste worse than a deliberate disclosure. It is unreviewable: data loss tooling can flag a paste into a browser tab on a managed device, but not which record went or which environment it came from. It is unbounded: nobody trims a trace in the middle of an incident. It is unrepeatable: the next outage produces a different trace with different fields, so no rule can be written against its shape.
A governed tool call has the opposite properties. It is one record, with a named operation, a named account, and a tool schema you can inspect before you allow it.
Should you block engineers using ChatGPT at work?
For a short window, yes; as a permanent control, no. Blocking works on the managed browser and the corporate sign-in. It does not work on a phone, a personal account, or the assistant built into the editor, so a block changes where the paste happens rather than whether it happens.
The cost arrives later. Once engineers route around the block, you lose the record too. Cyberhaven, which sells data loss prevention software, says in its guide to detecting shadow AI that 32.3% of the ChatGPT use it sees runs through personal accounts. A company workspace is the version you can govern. OpenAI's enterprise privacy page says business data from ChatGPT Business, Enterprise and Edu is not used for training by default, and neither is data ChatGPT reads from connected apps.
A block is still the right call for a short window. If you have no scoped path ready and a regulator is asking questions this month, block, then build. Treat the block as a countdown, not as a control.
What does scoped access look like?
One address, a sign-in per person, and no shared token anywhere in the setup. MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps. Elaichi is a governed MCP control plane: every SaaS account the company uses is connected once, and its tools are served through one organization-wide MCP endpoint, POST /mcp, behind OAuth. OAuth is the sign-in that hands the client a per-person grant instead of a secret pasted into a config file. There is no separate address per team and no token embedded in a client config, as one endpoint versus one per team explains.
Each client reaches that address its own way, as of October 2026:
- Claude. On Team and Enterprise, an owner adds the address under Organization settings, Connectors, and each member then connects it under Customize, Connectors, per Anthropic's setup steps. On Pro and Max, each person adds it themselves.
- ChatGPT. Full MCP with write actions is a beta on Business, Enterprise and Edu, where an admin creates and publishes the app. Pro users can connect MCP servers with read and fetch permissions only, in developer mode. The ChatGPT setup guide walks through it.
- Cursor. Engineers add the address by URL in
.cursor/mcp.jsonor~/.cursor/mcp.json, or install it from a team marketplace a Team admin has shared it to. Cursor supports OAuth for the sign-in. An Enterprise allowlist approves a server but does not install it on anyone's machine.
Connector credentials do not live in Elaichi. A separate credential service holds per-account secrets, encrypted at rest, and owns refresh. A failed refresh marks the connection needs_reauth rather than failing quietly. Sign-in to Elaichi itself can run over your own SAML or OIDC, with SCIM v2 provisioning and group-to-role mapping.
Back to the nil dereference. The engineer asks the assistant for the error and the deploy before it. The assistant reads the issue and its events through the Sentry connector, along with the release's deploys. The customer ID never touches the clipboard, because nobody had to move it.
How does the assistant find the right tool?
By search. In Elaichi, connected tools are never listed one by one, however few there are. The model asks search_tools for a match and runs the result through execute_tool. Control-plane operations stay listed individually, and the search never returns one.
execute_tool is only a naming indirection. It unwraps to the same name and arguments and passes the identical gates, so there is no privilege in it. A restricted tool is withheld from the tool list and cannot be called. Search names it, flagged restricted, with no schema. The search is lexical, with a relevance floor that stops it answering a query about one app with a tool from another. Why tool search needs a relevance floor has the example, and the context-window case for keeping tools unlisted has the reasoning.
What do you have to write before you turn it on?
Restrictions. A restriction is a rule about which connectors and which individual tools a target may reach, and somebody has to sit down and write them. In Elaichi, restriction targets are role or user only; the organization default is the absence of a rule, which means allow everything. Opening the endpoint before any rule exists gives a broad surface to a fast client, and that is the trade-off, stated plainly.
A blanket rule for engineers is therefore written on the engineering role. A rule aimed at a member can only narrow what their role allows, and never replaces or loosens a role rule. Within each layer, allow rules union, block rules union, and blocks always beat allows. Watch for one trap: the allowlist stage engages on the presence of an allow rule, not its contents, so an allow rule that names nothing denies everything.
A sensible first rule allows the Sentry and Jira reads and blocks delete_a_sentry_organization_issue_by_id and sentry_organization_issues_bulk_delete. Blocks can match a tool's name, but allows bind only to the operation behind it. The advertised name is a label that whoever edits the connector's documentation can change, so governance binds the operation, never the label. The name-versus-operation post has the detail.
Frozen arguments handle the case where the tool is fine and one argument is not. Freeze the environment or the Jira project key on an entry. The key drops out of the schema the model is shown, and the frozen value overrides whatever the caller passes at execution. Precedence runs entry defaults, then caller arguments, then frozen values.
How long does a restriction change take to apply?
A restriction change takes about two minutes to take effect, and so does a role change, on MCP, the console and REST alike. A runbook that assumes otherwise will be wrong during the one incident that matters. Why there is a delay at all is covered alongside the offboarding timings.
Five changes are effective on the next call instead: grant revocation, member removal, suspension, revoking a share and disconnecting an account. The OAuth grant, the per-person authorization the client holds, is re-read on every call. In Elaichi, removing or suspending a member revokes every live grant in the same transaction as the membership change.
The operational consequence is simple. If an engineer is mid-incident and reaching something they should not, suspend the member or revoke the grant. Do not edit a restriction and then watch the next call go through anyway.
What does the audit log show afterward?
The one thing a paste can never show: which account the assistant actually reached. The audit log, the append-only record of what happened, holds one entry for each connected-tool call that reaches execution (a call refused earlier writes none). Its connection field is the account the call reached, taken from the execution rather than the intent. Each entry also names the operation, the classification, whether the call was approved and its outcome, and it records the one path argument that names the object, as the target id, and nothing else about the arguments.
actor_kind is set at the point of action rather than inferred later from a user agent. Its values include ai_assistant, which marks the Elaichi Agent. A call from ChatGPT or Claude is recorded under the engineer who signed in, with surface mcp and the client named. Claude, ChatGPT and Cursor are marked verified.
The seat that reads all of this is free: Auditor is a read-only role with no license cost and no permission to run tools. In Elaichi, export to your own Datadog comes with the Black plan, which is launching soon. The audit-log field guide covers the full record.
What happens the day an engineer leaves?
Removal runs through a preflight, and it can refuse. The preflight lists every connection the departing engineer owns, private and shared alike. Only a private connection that a shared toolbox depends on can block the removal, until an admin transfers it to a member. A private connection that nothing beyond the engineer depends on cannot be transferred and is deleted with them. A connection never passes to the organization, to a team, or to the admin running the removal.
A shared connection a team still depends on is deleted only if you explicitly ask for that. Otherwise transfer it to a member who is staying, which leaves every grant on the connection exactly as it was. Delegated toolbox entries, entries on the saved set of tools a person or team works from, surface as a non-blocking warning, and re-pointing the entry at another connection is the fix rather than a credential decision.
Once the removal goes through, every live grant the person held is revoked with it, effective on the next call rather than about two minutes later.
Where does scoped access not help?
Scoped access reduces the reason to paste. It does not police the chat window, and claiming otherwise would be a lie by omission. An engineer who wants to paste a trace into a personal account on a personal phone can still do it. What changes is that the fast path now runs through a tool call, and the fast path is the one people take.
The prompt-injection write gate lives in the Elaichi agent window and does not apply to a raw tool call. What the endpoint offers instead is the frozen argument: a value such as the environment stays fixed whatever text reached the model.
When should a CTO not build this yet?
If you have eight engineers, one internal system to query and no contractual obligation to show who touched what, writing restrictions is overhead you will never read again. Use the assistant, keep secrets out of the log lines, and revisit when the second team asks. The case for waiting is laid out in the post on not needing a gateway yet.
If your real exposure is people who are not employees, start with the leaving path rather than the engineering path. Contractor offboarding and AI access covers the day somebody stops working for you.
If engineering is the second team rather than the first, the team playbooks show the same shape applied to support, finance and legal. The connector catalog lists what is already authored, and Cursor and Jira for an engineering team is the closest playbook.
