# Employees pasting customer data into AI > Employees pasting customer data into AI leaves partial traces in three places, none of them complete. What each source sees, and what a governed MCP endpoint changes. **TL;DR** Employees pasting customer data into AI leaves partial traces in three places: network and endpoint telemetry, the source system's own audit log, and QA screen recordings. None of the three records the paste itself, so the defensible answer to a COO is a range with the blind spot named. Elaichi removes most of the reason to paste by serving governed tool access through one organization-wide MCP endpoint, where every attempt is recorded with the account actually reached. ## The question a COO asks after a QA review A COO sits in on a support quality review and watches one screen recording. The agent has a customer ticket open on the left and a chat assistant on the right. For forty seconds the agent selects the account history, copies it, and pastes it into the assistant to get a cleaner reply. Nothing in the clip is malicious. It is the fastest route to a good answer. The question afterwards is not about that agent. It is about scale. Employees pasting customer data into AI is easy to see once and very hard to count. Before anyone promises the board a figure, work out which systems can see the behavior at all. ## Where does the evidence of employees pasting customer data into AI actually live? Three places, and none of them 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. None of them observes the paste as a single event with a customer identifier attached to it. The network sees an encrypted request body. The CRM sees a support agent doing their job. The recording sees one agent on one day. Any number you report is an estimate assembled from three partial views, and saying that out loud is more defensible than false precision. ## What a screen recording proves, and what it cannot A recording proves the behavior exists and shows you why. It proves nothing about volume. QA sampling is the only source that carries intent and shape. From one clip you learn which fields moved, which assistant received them, which step of the workflow was slow, and what the agent was trying to avoid doing by hand. That is the part that tells you what to fix, because the fix is usually a missing capability rather than a missing policy. What a recording cannot do is scale. Coverage is whatever share of interactions QA reviews, and that sample was chosen for coaching reasons, not for measurement. Recordings also capture 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 use them as the denominator. ## Why network telemetry undercounts the paste Network controls see devices and networks you administer, and they see destinations rather 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. TLS inspection is the usual answer, and it is expensive. It breaks certificate pinning in modern applications, and it raises a privacy question the moment an employee signs into a personal account on the same network. Even where inspection works, a paste inside an HTTPS session is not reliably distinguishable from typing. Blocking the domain has a second problem. A blocked paste is often a redirected one, to the device that is not managed. The undercount therefore grows as enforcement gets stricter, which is the wrong direction for a measurement you want to trust. When the device was never yours in the first place, the [contractor offboarding playbook](/blog/shadow-ai-contractor-offboarding/) is the more useful starting point. ## Where endpoint DLP and browser extensions go quiet Endpoint DLP (data loss prevention software that scans outgoing text for sensitive patterns) catches structured identifiers. It rarely catches customer context. A card number or a national ID has a shape. A stack trace, an angry email thread or a proprietary configuration file does not. The agent inspects the text, finds no marker, and lets it through. Writing a custom rule for every shape of customer data is not a project that finishes. Managed browser extensions that read the assistant's text area are the other common control. They are brittle by construction. Assistant vendors ship frontend changes often, and one renamed element breaks the script. Users also move to the desktop app, where the extension was never running. Treat both as partial coverage, not as a counter. ## Why the source system's audit log reads like a normal day 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. That is the same entry you would see with no assistant in the picture. Bulk export events are worth reviewing, 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. If you want the source system to serve as evidence, build per-role volume baselines and a comparison period. Accept in advance that the signal will be weak. ## Why the clipboard wins when the tool does not The behavior is a capability gap, not a discipline problem. Support agents work against handle-time targets. Sales reps need an account history summarized before a call. The assistant reads faster than a person does. When the approved assistant cannot see the system of record, the user bridges the gap by hand. The clipboard is the only bridge available to them, and it is the one surface nobody governs. A ban leaves the gap in place and moves the traffic somewhere you cannot see. Changing the incentive is the part that works. ## How to run a measurement you can defend Run it on one team for one week, then report a range with the blind spot named. A bounded estimate that states its own coverage survives a board question. A single confident percentage does not. 1. Pick the team with the most customer data in front of it, usually support or billing, and fix a single week so every source covers the same period. 2. 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 and which assistant. 3. 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. 4. Check what each AI vendor's admin console reports for your workspace, and write down what it does not report. 5. Give the COO a range derived from the QA rate, plus an explicit list of the surfaces none of the three sources can see. ## What a governed MCP endpoint changes about the incentive It removes most of the reason to paste. 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 the tools those accounts expose through one organization-wide MCP endpoint, `POST /mcp`, behind OAuth (the standard sign-in flow that issues a per-user grant instead of a shared token). Claude, ChatGPT, Cursor and the Elaichi Agent point at that single address and sign in. There are no per-user URLs and no tokens embedded in a client config. Elaichi authors and serves 450+ from its own infrastructure, so the ticketing tool the agent needs, such as the [Asana connector](/connectors/asana/), is something Elaichi maintains rather than a server your team runs. ## Where the credential sits 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. Reading back an account's configuration returns public values plus `secret_paths`, the list of dot-paths that were encrypted, carrying none of their values. The model never receives an API key, so there is no key for anyone to paste into a prompt. ## Which tools the model may reach A restriction (a rule for which connectors and which individual tools a target may reach) is written against a role or a specific user. restriction targets are role or user only; the organization default is the absence of a rule, which means allow everything. The org default is the absence of a rule, which allows everything. A rule on a user replaces the role rules for that user rather than adding to them Within the winning layer, allow rules union, block rules union, and blocks always beat allows. the allowlist stage engages on the presence of an allow rule, not its contents, so an allow rule that names nothing denies everything rather than its contents, so an allow rule naming nothing denies everything. That is the strictest rule you can express, and it catches people out. A rule is written against a connector and a tool, and the canonical operation is pinned against the catalog at write time. Block matches on the tool name or the pinned operation; [allow matches on the pinned operation only](/blog/block-matches-name-allow-matches-operation/), because a displayed name is a label the governed party can edit. Frozen parameters pin an argument, strip the key from the advertised schema so the model never sees it, and merge the pinned value over whatever the caller sends. Role and restriction changes take effect within about two minutes. Grant revocation, member removal and suspension apply on the next call. ## What the audit trail answers that a recording cannot It answers which account was reached, by whom, with what operation, and whether an AI took the action. Elaichi writes one entry per tool-call attempt, succeeded or failed, and both name the account actually reached, taken from the execution rather than from the intent. That detail is what the first question after an unexpected change needs: which of two connected Notion workspaces did the assistant write to. Each record carries the operation and tool, the connection, the classification, whether the call was approved, the outcome, and an error code. Argument names and counts are recorded. Argument values never are, so the ticket body does not get copied into the log while you are trying to stop it being copied into a prompt. `actor_kind` is a stored field rather than an inference, and its values include `ai_assistant`. Whether an AI did something is written down at the point of action, not reconstructed later from a user agent string. Audit events and application logs share one record shape, so a single query answers what happened. A compliance reviewer reads all of it on a free read-only Auditor seat, which is excluded from the billable count and lacks the permission to execute any tool. The trail is append-only and eventually consistent, so a row can take a moment to appear, and it can be forwarded to Datadog today. ## What this does not fix, and when to 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 does not live in a connected system, such as a PDF attached to a customer email, still gets pasted, because there is no tool call that would reach it. One more limit is worth stating plainly. The prompt-injection write gate lives in the Elaichi agent window and does not apply to a raw tool call. What does hold on the endpoint is per-operation permission checks, the `forbidden` classification that no OAuth scope can reach, output redaction, scope limits and full audit logging. 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](/blog/when-you-dont-need-an-mcp-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](/connectors/) and the [twelve team playbooks](/use-cases/) show what that agent's workflow looks like under audit. More on the same problem sits in [shadow AI](/blog/category/shadow-ai/), and the team-by-team rollout order is in the [playbooks category](/blog/category/team-playbooks/). ## FAQ ### Can you measure how much customer data employees paste into AI assistants? Not exactly. The behavior leaves partial traces in three places: network or endpoint telemetry on managed devices, the read and export entries in the source system's own audit log, and human artifacts such as QA screen recordings. None of the three records the paste itself as an event with a customer identifier attached. The defensible output is a range derived from a QA sample for one team and one week, reported alongside an explicit list of surfaces none of the sources can see, such as personal phones and photographed screens. ### Can network logs detect when an employee pastes customer data into an AI prompt? No. Traffic to an assistant provider is encrypted with TLS, so a secure web gateway records the destination and the volume, not the content. TLS inspection can be deployed, but it breaks certificate pinning in modern applications and raises privacy questions when employees use personal accounts on the same network. Even with inspection, a paste inside an HTTPS session is not reliably distinguishable from typing. ### Does blocking pastes into ChatGPT solve the problem? It reduces the traffic you can see and can push the rest onto devices you cannot see. A managed browser on a managed laptop can observe and block a paste into a known assistant domain. A personal laptop, a phone on cellular or a screenshot taken with a camera leaves no record. A block is therefore not always a prevented disclosure, and the measurement undercount grows as enforcement tightens. Removing the reason to copy, by giving the assistant governed read access to the system of record, changes the incentive rather than the route. ### What does Elaichi record when an AI assistant reads a customer record? Elaichi writes one entry per tool-call attempt, succeeded or failed, and both name the account actually reached, taken from the execution rather than the intent. Each record carries the operation and tool, the connection, the classification, whether the call was approved, the outcome and an error code. Argument names and counts are recorded; argument values never are. The field actor_kind stores who acted, with values including user, scim, api_token and ai_assistant, so AI action is recorded at the point of action rather than guessed afterwards. ### How quickly does a restriction change take effect in Elaichi? Within about two minutes. Role membership and restrictions resolve through a short cache plus edge propagation, on the MCP endpoint, the console and the REST API alike. Three changes are faster and apply on the next call: OAuth grant revocation, member removal and suspension, because the revocation flag is re-read from the organization store on every single call. ### Does a compliance reviewer need a paid seat to read the audit trail? No. Elaichi has a free read-only Auditor role, and Auditor seats are excluded from the billable count along with Guest and Billing Admin. The role can view the audit trail but lacks the tool:execute permission, so it cannot run any tool through the MCP endpoint. Billable seats are active memberships in the other roles, with a minimum of one, and suspended members are not counted. ## Read next - [Engineers using ChatGPT at work: block or scope it](/blog/shadow-ai-cto-engineers-already-have-chatgpt/) — Engineers using ChatGPT at work paste stack traces into it, and a block only moves the paste out of sight, while scoped MCP access removes the reason to paste. - [Contractor offboarding AI access: what to do today](/blog/shadow-ai-contractor-offboarding/) — Contractor offboarding AI access runs at two speeds. Removing a member takes effect on the next call. Role and restriction changes take effect within about two minutes. - [Proving AI actions in access review evidence](/blog/shadow-ai-security-lead-access-review-evidence/) — A row in the access review with no owner is usually an agent. AI actions in access review evidence need actor_kind recorded at the point of action, not guessed afterwards.