What a customer's AI questionnaire is really asking
The questionnaire arrives as a spreadsheet tab with a dozen rows and a Friday deadline. A customer's security team wants to know which AI tools touch their data. They also want to know who approved those tools, and what record exists of what the tools did. Most AI tool usage questionnaire answers are not in one place. Some sit in your identity provider, some in a chat vendor's admin console, and some nowhere at all. This post sorts the rows into three piles, and says plainly which pile each one lands in.
The rows that cause trouble are never "do you use AI". They are the four that follow it. Which systems can the assistant reach. Whose permissions does it act with. What was read or changed, and when. How does that access end when someone leaves. The first is an inventory question. The other three are call-path questions. A call-path question can only be answered by something that sat in the call path at the time.
Which AI tool usage questionnaire answers can you prove today?
The inventory and identity rows, from systems you already run. Your identity provider evidences who holds a Claude, ChatGPT or Cursor subscription, and SCIM evidences when that was taken away. Your chat vendor's admin console evidences which connectors an admin approved for the organization. Those are real answers, and they need no new vendor.
The client vendors also publish their own compliance exports. Anthropic's Compliance API Activity Feed starts recording when it is first enabled and does not backfill earlier activity. Recorded activity is kept for six years (platform.claude.com, checked October 2026). OpenAI's Compliance Logs Platform retains data for 30 days (help.openai.com, checked October 2026). Cursor's Enterprise audit logs include mcp_server_config events when a user or team MCP server is configured. They also include mcp_authentication events when a member authenticates to one (cursor.com, checked October 2026).
What those exports are not is a tool-level record of work done in your own systems. Compliance API transcripts of local sessions are rebuilt from requests the client sends to the Claude API. Tool definitions and MCP server configuration are not part of the transcript (platform.claude.com, checked October 2026). Nor is there an admin inventory of servers configured in members' local config files. None of the client admin pages read in October 2026 documents one (code.claude.com, checked October 2026). Counting those by hand is its own exercise, covered in the post on finding installed MCP servers.
Which rows need something sitting in the call path?
Every row about a specific action in a specific app. "On 3 March, which account updated this record, from which assistant, and did anyone approve it" has no answer unless a system saw the call go past. Network-layer controls answer a different question, as the CASB and DLP comparison sets out.
Those calls travel over MCP. MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps. Elaichi serves MCP at one address that Claude, ChatGPT and Cursor all sign into. Behind each client sits an OAuth grant per person. Every call runs through Elaichi, so each one that reaches execution is written to the organization's audit log, whichever connector it hit. One organization, one log across the whole connector catalog (650+ connectors), read back through one screen.
The access-removal row answers from the same place. Removing or suspending a member revokes their MCP client grants in that organization, and their clients fail on the next call. A restriction is a rule saying which connectors and tools a role or person may reach. A change to a role or a restriction takes effect within about two minutes. Offboarding when an agent holds the access walks the rest of that sequence.
What does one Elaichi audit row actually hold?
For a connected-tool call, the row holds the acting person, the toolbox the call went through, and the tool's advertised and catalog names. It also holds the connector, the connection the call actually reached, and the tool's classification. Then come the approval facts: whether approval was required and how it was given. It records whether a person edited the arguments, the surface, and the MCP client's id when the surface is MCP. Last come the outcome, what it touched, and a result count for list and search calls.
"What it touched" is recorded as a target: resource type, an id, a title and the object's own link. Titles are never kept for a person's record or a message. An email address is never recorded as an id or a title. For a list or search call the row keeps only the resource type and how many items came back.
Two details matter when a reviewer reads the client name. Elaichi can verify exactly seven clients by their registered redirect addresses: Claude, ChatGPT, Cursor, Grok, Perplexity, Mistral and Devin. Anything else shows the name the client registered for itself, which the console flags as self-reported. A client that registers only loopback addresses is never verified. Treat a self-reported name as a claim, not as evidence. What an AI agent audit log must capture goes field by field.
What Elaichi cannot evidence either
Say this part out loud in the questionnaire, because a reviewer will find it anyway.
Argument values are not recorded, apart from the one URL path argument that names the object. A row will not tell you what text was sent into a Notion page. Refusals are thinner than people assume. A call blocked at the MCP scope check writes no audit entry, because that refusal happens before any executor runs. A tool a restriction withheld from a person is simply absent from what the client was offered. "Every blocked attempt is logged" is not a sentence to put in the sheet.
Two more traps. Connected-tool calls sit in the audit log's assistant category, because their action name begins with assistant. The mcp category holds grant events such as a client connecting. Filtering the log to MCP therefore does not show MCP tool calls. And the console's CSV export stops at 10,000 entries, telling you to narrow the range rather than saving a partial file.
Finally, scope. Calls a client makes directly to a vendor's own MCP server never pass through Elaichi, so nothing about them lands in this log. Bringing that server in as a remote MCP connector is how those calls come under the same rules, as the vendor MCP server post explains.
Can the reviewer read the log themselves?
Yes, and on a free seat. The Auditor role holds 12 permissions, every one a view permission, including audit:view, restriction:view and api_token:view. It is a free seat, marked "Free" in the roles list, so adding a compliance reviewer does not add a billable member. It holds no create, share, manage, override or tool:execute permission. The reviewer therefore cannot change anything and cannot run tools.
Two honest caveats. connection:view and template:view are reserved and grant nothing, so an Auditor does not see other members' connections, templates or toolboxes. The role also lacks tool:execute, so an Auditor's own AI client gets an empty tool list. They read the log in the console instead.
Every other member can read the audit log too, at their own scope: their own events, plus events on connections they own or can edit. Only audit:view widens that to the whole organization. Proving AI actions in access review evidence covers what a reviewer does with it.
Retention, residency and the certificate rows
Elaichi keeps 90 days of audit history. If the questionnaire asks for a longer window, export to your own Datadog comes with the Black plan, which is launching soon. Say the 90 days plainly rather than implying an unlimited archive.
Residency is per leg, not per product. An organization picks its region when it is created. An EU or US organization's own data store is pinned to that jurisdiction. APAC uses best-effort placement, which is not a residency guarantee. The audit trail is a separate leg. Elaichi's privacy policy states that every organization's audit records sit in one EU log instance serving all regions. Stored tool files go to an EU bucket whatever the organization's region. Read it in the privacy policy, and leg by leg in EU data residency for AI agents.
For the rows asking for a SOC 2 Type II or ISO 27001 report, point the reviewer at the Trust Center at trust.elaichi.ai. The reports and certificates live there, and the claim belongs to the Trust Center rather than to your sheet. If the questionnaire asks about protected health information, note that a Business Associate Agreement is not offered by default. PHI is allowed only where an Order Form permits it and a BAA has been executed. Four questions for your BAA is the version to hand your counsel.
When the vendor's own compliance export is enough
If your people use one AI workspace with no connectors switched on, and nothing reaches a company system, you do not need a control plane to answer this questionnaire. The identity provider answers who has the tool. The vendor's compliance export answers what was typed. The honest answer to "which systems does it reach" is none. Write that and move on. When you don't need an MCP gateway yet makes the same case at more length.
The moment one connector is approved, the sheet changes shape. Someone now has to say whose permissions the assistant acted with and what it touched. That is a question about the call path.
Filling the sheet in one afternoon
Pull the inventory first, then the evidence, then hand the reviewer a seat. The order matters because each step narrows the next.
- List the AI clients that can reach company data from the grant events in the audit log.
oauth_grant.createdrecords the client, the scopes and the toolbox reach. Each person also sees their own connections under Settings, then Connected apps. Nobody sees another member's there, so the log is the organization-wide view. - List the apps those grants can reach, from the connections and toolboxes in scope, and mark which role each is restricted to.
- Pull the period's tool calls from the audit log, filtering by category
assistant, notmcp, and export the CSV with the filters applied. - Add the customer's reviewer, or your own, as an Auditor, which costs no billable seat.
- Fill the retention, residency and certificate rows from the 90-day figure, the organization's region, and the Trust Center.
What the questionnaire is testing is whether anybody can answer at the level of one call. The governance side of that, roles and restrictions rather than logs, is in MCP governance. The pattern as a product capability is on the governance use case page.
