A deletion request arrives, and the record is in Salesforce
A consumer emails your privacy inbox. They ask what you hold about them, or ask you to delete it. The record is a Salesforce contact. For the past month, three people have been reaching Salesforce from Claude and ChatGPT. Legal now wants two things: the record handled, and a list of who or what touched it.
This is the CCPA data subject request MCP problem in one line. The consumer record sits in Salesforce. The record of who reached it sits somewhere else. Elaichi is that somewhere else. It serves MCP at one address for every organization, https://api.elaichi.ai/mcp. MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps. Salesforce is one of 650+ connectors in the catalog behind that address.
Nothing below is legal advice about who is a business and who is a service provider. That is a contract question. Elaichi's data processing addendum and its CCPA notice answer it, not a blog post. What follows is what each system holds, and what can be proved from it.
Which system holds the consumer record, and which holds the access record?
Salesforce holds the consumer record. Elaichi holds the access record. The erasure itself happens in Salesforce, by someone with permission to do it there. That holds whether they use the Salesforce UI or run a Salesforce tool through Elaichi.
For a connector Elaichi authors and runs, Elaichi is itself the MCP server the AI client calls. Every call from Claude, ChatGPT or Cursor passes through it. Each one is checked against the caller's own access and written to the audit log, the organization's own append-only record of who did what. The Salesforce credential is not kept in Elaichi's main data. A separate credential service holds every connected account's secrets, encrypted at rest with AES-256-GCM. Elaichi fetches them into memory only for the call that needs them.
What Elaichi writes down about a Salesforce call is the audit row, not the record's contents. Argument values are not recorded, apart from the one URL path argument that names the object. Files are the other exception on results. When a connected tool returns a PDF or a spreadsheet, Elaichi stores the file and hands back a link. That file expires 7 days after it is created.
What does a CCPA data subject request MCP trail prove about one record?
It proves a named write. Each connected-tool call that reaches execution writes one row. That row records the acting person and the toolbox the call went through. It also records the tool's advertised and catalog names, the connector, and the connection the call actually reached. Then the tool's classification, whether approval was required and how it was given, the surface it came from, and the MCP client's id when the surface is MCP. Last, the outcome and what the call touched.
What it touched is a small target: the resource type, an id, sometimes a title, and sometimes the object's own link. The link keeps no query string. The id is the value of the one URL path argument that names the object, or else the returned record's id. Two limits matter for a privacy request. A target never keeps a title for a person's record, so a contact or lead is identified by id and not by name. An email address is never recorded as an id or a title. For a list or search call, the row records only the resource type and how many items came back.
So the honest answer to "who read this consumer's record" is bounded. You can show that a named person, through a named client, updated Salesforce object 003xxxxxxxxxxxx on a date through a named connection. You cannot show from a search row alone that the search returned that one consumer. Treat a search row as evidence that someone queried Salesforce, not as evidence of which record came back.
One more caution about naming the client. Elaichi marks a client's name as verified only for seven known clients. Their registered redirect addresses must all map to the same one. Anything else shows the name the client registered for itself, flagged as self-reported. For what a log has to carry before an auditor will accept it, see what an agent's log needs to hold.
How to pull every agent call that touched the record
Start from the Salesforce record id, not from the consumer's name. The audit log's free-text search matches each word of the query against the action, resource type, resource id, acting user id and the event's metadata. The object id is the one string that reliably finds the rows.
Reading the whole organization's log needs the audit:view permission. Among the built-in roles, Org Owner, Org Admin and Auditor hold it. Auditor is a free seat and read-only, so a privacy reviewer can be added without taking a billable seat. An Auditor's AI client cannot read the log over MCP: the role lacks tool:execute, so its MCP tool list is empty. Every other member can read the log too, at their own scope. That scope is their own events, plus events on connections they own or can edit.
Two things catch people out when they filter. Connected-tool calls sit in the audit log's assistant category, because their action name begins with assistant. The mcp category holds client grants and other MCP actions, not tool calls. And a CSV export stops with an error past 10,000 entries rather than saving a partial file, so narrow the date range first.
The 90-day bound on your evidence
Elaichi keeps an organization's audit log for 90 days, as the privacy policy states. That is the real limit on what you can produce. A query that gives no start time covers the last 400 days. The console's "All time" range sends no start time, so neither is a complete history.
The AI clients keep their own records, on their own clocks. Anthropic says the Compliance API's Activity Feed starts recording when the API is first enabled and does not backfill earlier activity (Compliance Activity Feed, checked October 2026). Recorded activity is kept for 6 years, and the Compliance API is available to Claude Enterprise organizations and eligible standalone Console organizations (Compliance API access, checked October 2026). Cursor's audit logs, an Enterprise-plan feature, record mcp_server_config and mcp_authentication events (compliance and monitoring, checked October 2026). OpenAI says source permissions still apply however an app authorizes access (admin controls for plugins and apps, checked October 2026). Those records answer client-side questions: which server was configured, who authenticated, which session ran. Elaichi's row answers a different one: which person, through which client, reached which Salesforce object, through which connection.
If your retention schedule for access records is longer than 90 days, the log has to leave Elaichi: export to your own Datadog comes with the Black plan, which is launching soon. Plan for that before a request arrives, not after. Where the access record itself lives is a separate question. Elaichi's privacy policy says its audit-log store is one instance in the EU serving every region. Where the organization's own data store sits is a different matter. The leg-by-leg version is in the post on residency for agent traffic.
If you need to stop an AI client reaching Salesforce while you work the request, disconnect its grant under Settings then Connected apps. Every MCP request re-reads the grant, so the client fails on its next call. Revoking a share on the connection takes effect on the next call too.
Where erasure stops: what deleting leaves behind
Deleting the Salesforce record is Salesforce's job. Elaichi does not do it as a side effect of anything. Deleting the Elaichi connection deletes Elaichi's stored credential for it. Elaichi makes no call to Salesforce to revoke the token. That token stays valid at Salesforce until it expires or someone revokes it there.
Deleting the whole Elaichi organization is where the gap has to be stated plainly. The delete schedules a 30-day grace period. During it the organization is read-only, and an owner or admin can restore it. Connections are not restored and have to be re-authorized. On day 30 the purge removes connections and their vault credentials, custom connectors, API tokens, SCIM tokens and MCP grants. It also removes the organization's data store, its stored files and its database rows.
Three stores are left in place, and a completed deletion names them in its residue list. They are the organization's audit history in the log store, its usage-analytics rows, and some connector configuration records at the credential service. The connection credentials themselves are deleted. Elaichi also keeps its own staff record of the deletion. The organization's slot in the log store is never handed to another organization. So this is not full erasure of everything connected to the account, and a post that said otherwise would be wrong. For a consumer request the useful consequence is narrower than it sounds: the audit history holds ids, actor ids and metadata, not the Salesforce record's contents.
When the app's own log is enough
If one person uses one AI client, signed in with their own Salesforce account, and shares nothing with anybody, you do not need any of this. Salesforce's own audit trail already shows that user's actions. Adding a second vendor to the path adds a second log to reconcile. The case for a control plane starts when several people reach several apps from several clients. It starts when nobody can answer "which account did that call run as" from the app's log alone.
Test that threshold honestly before buying anything: when you do not need a gateway yet walks through it. If you are past it, the access model that produces these rows is set out in who may do what, in which app. The per-person Salesforce pattern is in each rep's own Salesforce access. The catalog itself, Salesforce included, is at /connectors/.
