The inventory row that starts this
Legal asks whether anyone is putting customer data into an AI assistant. You export the extension inventory from your browser management console. One row answers the question badly:
Extension Managed profiles First seen Host permissions
AI Assistant 143 of 212 2026-02-11 read and change all site data
Five more rows look like that one. Six assistants, most of the fleet, two of them added in the past two weeks (Cyberhaven's Shadow AI report sees the same pattern).
A shadow AI browser extension log is the first artifact most IT teams get, and it is useful. It sizes the surface. It also stops well short of the question legal asked. The instinct after reading it is to block all six extensions by policy. Blocking moves the traffic. The phone, the personal browser profile and the assistant's own web app all sit outside the console that produced the row.
What does a shadow AI browser extension log actually prove?
It proves installation and permission scope. Nothing about content.
Read carefully, the row gives you five facts:
- The extension ID, which pins the vendor and the build.
- The managed profiles it is present on, and the count.
- When it first appeared, which tells you whether this is new.
- The host permissions it declared at install time.
- Whether it is still enabled.
That is an inventory of capability, not a record of behavior. An extension holding read and change access to all site data can read an open Salesforce tab. The log does not say that it did. The copy itself travels through the operating system clipboard, and your perimeter sees ordinary encrypted web traffic. Treat the count as your blast radius and stop there.
The four things that row cannot tell you
Four gaps matter, and each one breaks a conclusion somebody will try to draw from the inventory.
Content. No paste text, no uploaded file, no prompt. A paste is a client-side action. It leaves no record in the system the data came from.
Account. The row does not say whether the person signed into the assistant with corporate SSO (single sign-on, your identity provider issuing the session) or a personal account. Those two have very different retention and discovery consequences.
Purpose. An assistant used to reword a sentence and one used to summarize a customer's support history look identical in an extension inventory.
Coverage. The console sees managed browser profiles. It does not see the mobile app, the unmanaged laptop, or the web interface used without an extension. A number derived from the inventory is a floor, not a measurement.
Which logs to pull before you write the policy
Three partial records beat one. Pull all three before the policy meeting.
Your identity provider's OAuth grant list shows which third-party applications hold a live token against your Google or Microsoft tenant. OAuth is the browser sign-in flow that hands an application a scoped token instead of a password. That list finds assistants connected straight to mail and files, which the extension inventory never sees.
SaaS admin consoles come next. Connected applications and session activity in Salesforce, Notion or Zendesk show what was authorized against the system that holds the data.
Last, the admin console of any assistant you already pay for. On an enterprise plan you usually get workspace-level visibility of who is signed in.
None of the three shows you a paste. That is the honest state of the evidence, and it is why a policy written from the inventory alone tends to be argued about rather than followed.
Why the paste happens at all
People paste because copy is the only read path available to them.
A support agent with forty open tickets wants a summary of a customer's history. The assistant cannot reach Zendesk, so the agent becomes the data pipe: open the desk, select the thread, switch tabs, paste. A finance analyst wants last quarter's figures explained, so the sheet goes into the chat window. Neither person is defying the policy. They are routing around a missing connector, and the company data now sits in the chat history of a tool nobody sanctioned.
That is the useful reading of the extension inventory. Six assistants installed is six people-shaped requests for a read path. If the assistant can read the ticket with permission, the paste has no job.
The fix shape: one endpoint, read-only first
Give the assistant governed read access through one organization-wide endpoint, and start with read-only restrictions.
MCP is the Model Context Protocol, the open standard an AI client uses to discover and call tools in other systems. Elaichi is a governed MCP control plane. Every SaaS account the company uses is connected once, and the tools those accounts expose are served through a single address: POST /mcp, standard MCP over Streamable HTTP, stateless, behind OAuth. There are no per-toolbox URLs and no embedded tokens in a client config. Elaichi's catalog covers 450+.
Claude, ChatGPT and Cursor can each be pointed at that one address through their own admin console. Two layers then decide what anybody reaches. Role-based access control (RBAC) sets what a member may do, and every member holds exactly one role. Resource sharing decides what they can see at all: a member sees only what they own or what was explicitly shared with them, and no organization-level permission silently widens that listing.
Restrictions are the third layer, and the one this problem turns on. A restriction names which connectors and which individual tools a target may reach. Targets are a role or a user, never the whole organization. The organization default is the absence of a rule, and the absence of a rule means allow-all. The first restriction you write is the one that changes anything.
Read-only access in the order you would set it up
Connect the accounts, write the allow rules, pilot one client, then read the audit trail.
One trap is worth stating before you touch the rules. the allowlist stage engages on the presence of an allow rule, not its contents, so an allow rule that names nothing denies everything. An allow rule naming nothing denies everything. It is the strictest rule you can express and the easiest one to create by accident.
Write blocks for deletes as well as allows for reads, because blocks always beat allows. A block matches the advertised tool name or the pinned operation. An allow matches the pinned operation only, so a vendor renaming a tool cannot widen what you permitted. The reasoning behind that asymmetry is set out in why a block binds the name and an allow binds the operation.
For arguments that are not a model's decision, use frozen parameters. A frozen key is stripped from the advertised schema, so the model never sees it, and the frozen value is merged over caller arguments at execution.
Role and restriction changes in Elaichi take effect within about two minutes, on the MCP endpoint, the console and the REST surface alike. Grant revocation, member removal and suspension are effective on the next call, because the grant is re-read from the organization store every time. Plan the pilot around those two numbers rather than assuming either one.
What the assistant sees once several accounts are connected
Past a threshold of 30 tools, the connected tools collapse behind two meta-tools, search_tools and execute_tool.
The threshold counts control-plane operations and connected tools together, and the control-plane catalog alone is dozens of operations. One connected app is normally enough to trip it, so collapse is the normal case rather than an edge case. Control-plane operations stay listed individually. Tools withheld by a restriction are excluded from the count, because they were handed to nobody. Search ranking applies a relevance floor so the model is not handed a tool from an app nobody asked about, which the ranking floor post works through from first principles.
What happens when the person on that row leaves
Removal runs a preflight, and it refuses rather than guessing.
Personal connections referenced by a toolbox entry have to be resolved first: transferred to the organization, a team or another member, or deleted. Unreferenced personal connections are cleaned up. A private connection is not transferable at all, because a credential only its owner could ever use does not become somebody else's when its owner leaves. Delegated toolbox entries surface as a non-blocking warning, and re-pinning is the fix. removing or suspending a member revokes every live grant in the same transaction as the membership change, so the endpoint stops serving that person on the next call. For a contractor whose last day was yesterday, the order of operations is different and contractor offboarding for AI access covers it.
What the audit trail answers that the extension row cannot
It answers which account was reached, by whom, through which tool, and whether the call worked.
Elaichi writes one entry per tool-call attempt, succeeded or failed, and both name the account. The recorded connection is the account actually reached, taken from the execution rather than from the intent. That matters the first time somebody asks which of two Notion workspaces an agent wrote to. actor_kind is a recorded field rather than an inference, and its values include ai_assistant, so an AI action is marked at the point of action instead of being guessed later from a user agent string.
Argument names and counts are recorded. Argument values never are. Two error strings exist per failed call, and the one written to the trail is never derived from the third party's response, so a remote error body cannot ride the log pipe into your SIEM. The trail is append-only and eventually consistent, so a row can take a moment to appear. A compliance reviewer reads it on the Auditor seat, which is read-only and free.
The limit of this fix, stated plainly
Governed read access removes the reason to paste. It does not remove the ability.
The six extensions stay installed until you change browser policy, and a person who wants to paste can still paste. Do both: sanction a read path, then narrow the browser. One without the other either starves people of a tool they will find anyway, or leaves an unmanaged surface next to a managed one.
A second limit is worth knowing before anybody oversells this internally. The prompt-injection write gate lives in the Elaichi agent window and does not apply to a raw tool call. What holds on the endpoint is RBAC per operation, the forbidden classification that no OAuth scope can reach, output redaction, scope limits and full audit logging.
When the extension row is all the tooling you need
If you can name every person on that row and speak to all of them this week, a control plane is premature.
Twelve people, one system, one assistant: a conversation, a sanctioned account and a browser policy get you further than a purchase. The two plans are Gold and Black, with a 14-day trial. Gold is $15 per user per month, or $120 per user per year, with a 14-day trial that does not ask for a card. Buying before you have a second client or a second team to govern means paying for an address model you are not using yet. The threshold worth waiting for is set out in the case for holding off on a gateway.
If the clients your people use already ship connectors of their own, one plane against many clients is the comparison to read. The systems you can connect are listed in the connector catalog, the per-team rollouts sit under use cases, and the rest of this thread continues in Shadow AI.
