No single system records employees pasting customer data into AI. Network logs see the destination, the helpdesk sees an ordinary read, and QA recordings catch the act one screen at a time. The defensible answer to "how much?" is a range from one team and one week, with the blind spots named. The fix that lasts is giving the approved assistant governed access to the system the data came from, so the copy step has no purpose.
It usually starts in a quality review. A COO watches one support recording: a ticket on the left and a chat assistant on the right. For forty seconds the agent copies the account history across to get a cleaner reply. Nothing in the clip is malicious. It is the fastest route to a good answer, and the question afterwards is about scale, not about that agent.
Where does the evidence of employees pasting customer data into AI actually live?
In three places on your side, and none is complete. The network edge sees traffic leaving a managed device. The source system's audit log sees the read that produced the data. Human artifacts such as QA recordings, tickets and internal chat see the act itself.
Each source covers a blind spot in the other two, and none records the paste as an event with a customer identifier attached. The network sees an encrypted request, the helpdesk sees an agent doing their job, and the recording sees one agent on one day.
A fourth source exists only when the paste went into a company workspace. OpenAI's help center says user conversations are available in its Compliance API for ChatGPT Enterprise and Edu customers. A paste into a personal account shows up in none of these. Any number you report is an estimate assembled from partial views, and saying so is more defensible than false precision.
What can a QA screen recording prove?
That the behavior exists, and why. It proves nothing about volume.
From one clip you learn which fields moved, which assistant received them, which step was slow, and what the agent was avoiding doing by hand. That tells you what to fix, because the fix is usually a missing capability rather than a missing policy.
A recording cannot scale. Coverage is whatever share of interactions QA reviews, sampled for coaching rather than measurement. It also captures the managed desktop and nothing else: if the agent picks up a personal phone, the clip shows a person looking down. Use recordings as the qualitative source, never as the denominator.
Why do network logs undercount the paste?
Network controls see devices and networks you administer, and they see destinations more readily than content. A secure web gateway logs a connection to an assistant provider and the volume of traffic. The session is encrypted with TLS, so the payload stays hidden unless the gateway decrypts it.
TLS inspection is the usual answer, and it is expensive. Microsoft's own guide warns that many mobile apps pin their certificates, which "prevents successful TLS inspection" and ends in failed handshakes. It also raises a privacy question once an employee signs into a personal account on the same network. Even where it works, a paste inside an HTTPS session is hard to tell apart from typing.
Blocking the domain has a second problem. A blocked paste is often a redirected one, to a device you do not manage, so the undercount grows as enforcement tightens. When the device was never yours, the contractor offboarding playbook is the better starting point.
Can endpoint DLP or a browser extension catch the paste?
On a managed device in a supported browser, often yes. Microsoft Purview's Endpoint DLP can audit or block a paste into a restricted site, and it evaluates the pasted content itself rather than the file it came from. Where it is deployed, endpoint DLP (data loss prevention that runs on the device) is the closest thing to a paste counter.
Its limits are coverage and shape. Purview's DLP overview lists keywords, regular expressions, validation functions and machine learning among its matching methods. A card number has a shape those methods catch well. An account history or an angry email thread has no fixed shape, so whether it trips a rule depends on how well a classifier was trained. None of it runs on a device you do not manage. What a CASB and DLP see of AI agents covers the network side in more depth.
Browser extensions that read the assistant's text box are the other common control, and they are brittle. Assistant vendors ship frontend changes often, and one renamed element breaks the script. Users also move to the desktop app, where the extension never ran. Treat both controls as partial coverage, not as a census.
Does the source system's audit log show the paste?
No. The read that fed the assistant was legitimate, and the log has no field for what happened next.
Your helpdesk or CRM records that a named user viewed or exported a record at a time, the same entry you would see with no assistant involved. Bulk exports deserve a review, because an export outside a role's normal pattern is a real signal. The paste that matters is usually small and repeated: one account at a time, dozens of times a day, shaped exactly like work. To use the source system as evidence, build per-role volume baselines and a comparison period, and expect a weak signal.
Why do employees paste customer data in the first place?
Because the approved tool cannot see what they need. Support agents work against handle-time targets, sales reps need an account summarized before a call, and an assistant reads faster than a person does. When the approved assistant cannot see the system of record, people bridge the gap by hand. The clipboard is the only bridge available, and it is the one surface nobody governs.
Training still has a place. The OWASP Top 10 for LLM applications lists sensitive information disclosure as LLM02:2025, and says users need to understand the risk of unintentionally providing sensitive data. Its mitigations include teaching people what not to enter. Education reduces the careless paste. It does not close a capability gap, and a ban leaves the gap in place while moving the traffic somewhere you cannot see.
How do you measure it in a way you can defend?
Run it on one team for one week, then report a range with the blind spots named. A bounded estimate that states its own coverage survives a board question. A single confident percentage does not.
- Pick the team with the most customer data in front of it, usually support or billing, and fix one week so every source covers the same period.
- Re-watch that week's existing QA sample and count the clips where data moves from a company system into an assistant. Note which fields moved, which assistant received them, and whether it was a company workspace or a personal account.
- Pull read and export counts for that team and week from the source system's own audit log, and compare them with the same week a quarter earlier.
- Ask each AI vendor's admin surface what it reports for your workspace, and write down what it does not report.
- Give the COO a range derived from the QA rate, plus an explicit list of the surfaces none of the sources can see.
The account each paste went into matters as much as the count, because the vendors' terms differ by plan. OpenAI's enterprise privacy page says it does not train on business data from ChatGPT Business, Enterprise or Edu by default. Anthropic's privacy center says the same of commercial products such as Claude for Work, unless someone sends feedback or otherwise opts in. A Team or Enterprise owner can stop members sending that feedback with the Rate chats setting, under Organization settings, Data and Privacy, as of October 2026. Neither commitment covers a personal account signed in on the same laptop.
How does governed access remove the reason to paste?
It gives the assistant the read the agent was doing by hand. The agent in the recording copied data because the assistant could not see the ticket. When the assistant can read the ticket through a governed call, the copy step has no purpose.
MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps. Elaichi connects each SaaS account once and serves its tools through one organization-wide MCP endpoint, POST /mcp. The endpoint sits behind OAuth, the standard sign-in that issues each person a grant instead of a shared token. An admin adds that address once where the client allows it, and each person then connects and signs in with their own grant. In ChatGPT, full MCP with write actions is a beta on Business, Enterprise and Edu as of October 2026, and an admin creates and publishes the app. The ChatGPT setup guide has the steps.
Elaichi serves 600+ connectors and authors most of them on its own infrastructure. The helpdesk the agent needs, such as the Zendesk connector, is something Elaichi maintains rather than a server your team runs.
Anthropic draws the same line between a paste and a tool read on its consumer plans. Its privacy article says the chat data it may use to improve models excludes raw content from connectors, including remote MCP servers. Data copied straight into the conversation can still be included.
Where does the credential sit while the model works?
Outside Elaichi, and outside the chat window. Connector credentials live in a separate credential service that holds per-account secrets, encrypted with AES-256-GCM at rest, and owns the refresh cycle. A failed refresh marks the connection needs_reauth rather than failing quietly.
A connect URL is a one-time session that carries no token, which is why it is safe to return over MCP. The model never receives an API key, so there is no key for anyone to paste into a prompt.
How do you limit which tools the assistant can reach?
With restrictions: rules for 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.
A rule aimed at a member can only narrow what their role allows, and never replaces or loosens a role rule. Within each layer, blocks always beat allows. Note that the allowlist stage engages on the presence of an allow rule, not its contents, so an allow rule that names nothing denies everything.
A block can match a tool's name. An allow matches only the operation recorded with the rule, because anyone editing the connector can change a displayed name. Block on the name, allow on the operation explains why. Frozen arguments go further. An admin fixes a value on a tool entry; the model cannot change it, and anything the caller sends for it is overridden. Role and restriction changes take about two minutes to take effect. Grant revocation, member removal and suspension apply on the next call.
What does the audit trail answer that a recording cannot?
Which account was reached, by whom, with what operation, and through which client. Elaichi writes 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, taken from the execution rather than the intent. That is the first thing to check when two helpdesk accounts are connected and something changed in one of them.
Each entry also carries the operation, the classification, whether the call was approved and its outcome. It records the one path argument that names the object, as the target id, and nothing else about the arguments, so the ticket body does not get copied into the log while you are trying to stop it being copied into a prompt. The actor_kind field stores who acted, and its values include ai_assistant, which marks the Elaichi Agent. A call from Claude or ChatGPT is recorded under the person who signed in, with surface mcp and the OAuth client named.
A compliance reviewer reads all of it on a free read-only Auditor seat, which cannot run tools. In Elaichi, export to your own Datadog comes with the Black plan, which is launching soon. The post on what an AI audit log must record covers the rest of each entry.
What does this not fix, and when should you wait?
A governed endpoint does not stop a person from pasting. Someone who wants to drop an account history into a personal assistant on a personal phone is outside every control described here. Data that lives in no connected system, such as a PDF attached to a customer email, still gets pasted, because no tool call would reach it. One more limit applies: The prompt-injection write gate lives in the Elaichi agent window and does not apply to a raw tool call.
If you have one small team, three people using assistants and no compliance request in front of you, this decision can wait. The case for holding off on a gateway is real, and the cheaper move is to close the capability gap the QA recording exposed. When you are ready for the governed version, the connector catalog and the twelve team playbooks show what that agent's workflow looks like under audit. More on the same problem sits in shadow AI, and the rollout order team by team is in the playbooks category.
