A shadow AI browser extension log proves which AI assistant extensions are installed and how widely. It also shows what each one asked to reach, down to the websites it can read or change. It does not prove that anyone pasted company data, which account they used, or what happened on a phone or an unmanaged laptop. Read it as a measure of exposure, then pull the records that answer the rest.
Legal asks whether anyone is putting customer data into an AI assistant. You open the Apps & extensions usage report in the Google Admin console, and one row answers the question badly:
App name App type Install type Installs Permission
AI Assistant Chrome extension normal 143 9
Its detail page lists the websites the extension asked to read or change data on, and for this one that means every site. Five more rows look like it: six assistants, across most of a fleet of 212 managed browsers.
The report is useful: it sizes the exposure, and Google's documentation notes that the same screen can block or force-install an extension for an organizational unit. It also stops well short of the question legal asked. The instinct is to block all six. Blocking moves the traffic to the phone, the personal browser profile and the assistant's web app, none of which this console sees.
What does a shadow AI browser extension log actually prove?
It proves installation and requested access, and nothing about content.
For each extension, Chrome's report gives you five facts:
- The app name and its ID, which pin the vendor.
- How it was installed: by admin policy, normally, by other software on the machine, or unpacked in developer mode.
- How many browsers, profiles and ChromeOS devices carry it.
- How many permissions it requested, and on its detail page, which websites it asked to read or change.
- Whether its Chrome Web Store listing is still published or was taken down.
Reporting has to be turned on first, and Google says data can take up to 24 hours to show up. The row is an inventory of capability, not a record of behavior. An extension that can read and change data on every site can read an open Salesforce tab. The report does not say that it did. Treat the install count as your exposure and stop there.
What can the extension log not tell you?
Four things, and each one breaks a conclusion somebody will try to draw from the report.
Content. No paste text, no uploaded file, no prompt. A paste happens on the device and leaves no record in the system the data came from. Endpoint DLP (data loss prevention software on the device) is the tool built to see it. Microsoft Purview, for one, evaluates content at the moment it is pasted into a browser and can audit, warn or block by destination site. What a CASB and DLP each see sets that instrument beside a governed endpoint.
Account. The row does not say whether the person signed into the assistant with corporate SSO (single sign-on, where your identity provider issues the session) or with a personal account. The two carry 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 the report.
Coverage. The report covers enrolled browsers, managed profiles and ChromeOS devices. It does not see the mobile app, an unmanaged laptop, or the assistant's web interface used without an extension. A number taken from it is a floor, not a measurement.
Which other logs should you pull before writing the policy?
Three partial records beat one, so pull all three before the policy meeting.
Start with the OAuth grants in your identity provider. OAuth is the sign-in flow that hands an application a scoped token instead of a password. In Google Workspace, the API controls page lists the third-party apps that have accessed Google data (Google's admin help). It shows how many users each app has and which Google services it uses. In Microsoft Entra, an enterprise app's User consent tab shows the permissions granted to specific users or groups (Microsoft's guide). Those lists find assistants connected straight to mail and files, which the extension report never sees.
Next, the admin consoles of Salesforce, Notion, Zendesk and the other systems that hold the data show which apps were authorized against them.
Last, the admin console of any assistant you already pay for usually shows who is signed in to the workspace.
None of the three shows a paste. Without endpoint DLP, that is the honest state of the evidence, which is why a policy written from the extension report alone gets argued about rather than followed.
Why do people paste company data into AI assistants?
Because copy and paste is the only read path they have.
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 a policy. They are working around a missing connector, and the company data now sits in the chat history of a tool nobody approved.
That is the useful reading of the report: six assistants on most of the fleet is a request for an assistant that can see the ticket. Give it that, with permission, and the paste has no job to do.
What does a sanctioned read path look like?
One organization-wide endpoint, with read-only restrictions first.
MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps. The MCP specification describes tools as the way a model reaches external systems, such as querying a database or calling an API. Elaichi is a governed MCP control plane. Each SaaS account is connected once, and its tools are served from one address, POST /mcp. That address speaks standard MCP over Streamable HTTP and sits behind OAuth. Nobody gets a personal URL, and no token sits in a client config.
An admin adds that address once where the client allows it. Each person then connects, signing in with their own grant. On Claude Team and Enterprise, an owner registers it in Organization settings > Connectors, and members connect from Customize > Connectors (Anthropic's setup steps). In ChatGPT, full MCP support with write actions is a beta on Business, Enterprise and Edu as of October 2026 (OpenAI's help article). There, an admin or owner creates and publishes the app for the workspace, and connecting ChatGPT walks through the steps.
Two layers decide what anybody can see and do. Role-based access control (RBAC) sets what a member may do, and every member holds exactly one role. Sharing decides what they can see at all: a person sees only resources they own or that someone explicitly shared with them, and no organization-level permission quietly widens that list.
Restrictions are the third layer, and the one that matters here. A restriction sets 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. So the first restriction you write is the one that changes anything.
In what order should you set up read-only access?
Connect the accounts, write the allow rules, pilot one client, then read the audit trail.
One trap comes before the rules. In Elaichi, the allowlist stage engages on the presence of an allow rule, not its contents, so an allow rule that names nothing denies everything. No rule is stricter, and none is easier to create by accident.
Write blocks for deletes as well as allows for reads, because blocks always beat allows. A block matches either the tool's advertised name or the operation the rule was pinned to. An allow matches that operation only, so a vendor renaming a tool cannot widen what you allowed. Why the two rules match differently sets out the reasoning.
Some arguments are not the model's to choose, such as the workspace or the region. Freeze them. A frozen key is cut from the tool's schema. The frozen value overrides anything the model sends when the call runs.
Role and restriction changes in Elaichi take effect within about two minutes on every surface: MCP, the console and REST. Grant revocation, member removal and suspension land on the next call, because the grant is re-read from the organization store each time. Plan the pilot around both timings rather than assuming either one.
What does the assistant see once accounts are connected?
It sees less than people expect. In Elaichi, connected tools are never listed one by one, however few there are. The model looks a tool up with search_tools when it needs one, then calls it through execute_tool.
A restricted tool is withheld from the tool list and cannot be called. Search names it, flagged restricted, with no schema. The same rule is checked again when a call runs. Search also has a relevance floor, so a weak match returns nothing instead of a tool from the wrong app. How that floor is calculated is set out step by step.
What happens when someone on that row leaves?
Elaichi runs a preflight check before removing them, and the check refuses rather than guessing.
First, any private connection that a shared toolbox (a saved set of tools and accounts) still depends on blocks the removal until an admin transfers it to a member. A transfer goes to one member, never to a team or the organization. A private connection that nothing beyond the person depends on cannot be transferred and is deleted with them.
In Elaichi, removing or suspending a member revokes every live grant in the same transaction as the membership change. The endpoint stops serving that person on the next call. A contractor whose last day was yesterday needs a different order of operations, which offboarding when the agent holds access covers.
What does the audit trail answer that the extension log cannot?
Which account was reached, by whom, through which tool, and whether the call worked.
Elaichi keeps one entry for each connected-tool call that reaches execution (a call refused earlier writes none). The connection on each entry is the account the call actually reached, read from the execution and not from what was asked for. After a surprise change, that settles the usual first question: which of two Notion workspaces received the write. The actor_kind field is recorded, not inferred, and its value ai_assistant marks the Elaichi Agent. A call from ChatGPT or Claude is recorded under the person who signed in, with surface mcp and the OAuth client named.
Each entry holds the one path argument that names the object, as the target id, and nothing else about the arguments. A compliance reviewer reads the trail from the Auditor seat, which is read-only and free.
Does a sanctioned read path stop people pasting?
No. Governed read access removes the reason to paste, not the ability.
The six extensions stay installed until you change browser policy, and anyone who wants to paste still can. Narrow the browser as well, a job browser policy is good at. Microsoft's guidance for Edge is to manage extensions by the permissions they request and the websites they can reach (Microsoft's extension management guide). A runtime block on hosts keeps extensions from reading or changing data on the sites you name. Staff can keep a writing assistant without it running on Salesforce or Zendesk. One measure without the other either starves people of a tool they will find anyway, or leaves an unmanaged surface next to a managed one.
One more limit belongs in the internal pitch. The prompt-injection write gate lives in the Elaichi agent window and does not apply to a raw tool call. The endpoint still enforces RBAC per operation, OAuth scope limits and the forbidden classification, which no scope unlocks. It also redacts outputs and writes an audit row for each call that reaches execution.
When is the extension log all the tooling you need?
When you can name every person on that row and talk to each of them this week. At that size 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. Elaichi has two plans, Gold and Black. Gold's USD list price is $15 per user per month, and the pricing page shows the local price where one applies. Buying before you have a second client or a second team to govern means paying for an address model you are not using yet. When you don't need a gateway sets out the point where that changes.
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.
