# Vendor Security Questionnaire AI Access: 20 Answers

> Twenty vendor security questionnaire ai access questions, answered with the mechanism: which key, which role, which log row.

**TL;DR** A vendor security questionnaire ai access review asks about encryption, key management, identity, tokens, logging and deletion. This post answers twenty of those questions for Elaichi with the mechanism behind each answer, and writes no where the answer is no. Four answers are negative: customer-managed keys, Splunk and Sentinel forwarding, session revocation by admins, and a Business Associate Agreement by default.

## What does a vendor security questionnaire ai access review ask for?

It asks for mechanism, not a yes. A reviewer sends a spreadsheet with three columns: question, yes or no, comment. The yes column is worth almost nothing, because every vendor ticks it. What a reviewer can actually use is the mechanism: which key, which header, which role, which log row. That is what gets a tool approved in one pass instead of three.

This is the answer sheet for a vendor security questionnaire ai access review of Elaichi, a governed MCP control plane. MCP is the Model Context Protocol, the standard Claude, ChatGPT and Cursor use to call tools. Elaichi serves it at one address, POST https://api.elaichi.ai/mcp. The OAuth grant behind each token decides which organization, which person and which tools a client reaches. Twenty questions follow. Four of them get a no, and the no is written as no.

## How are connector credentials encrypted at rest?

Stored connector secrets are encrypted with AES-256-GCM. Each ciphertext records the id of the key that wrote it, so the encryption key can be rotated without re-encrypting old rows.

The credentials themselves do not live in Elaichi's main data. A separate credential service holds every connected account's secret values (OAuth tokens, API keys, client secrets) in encrypted form, apart from its plaintext context. Elaichi's own row carries ownership and lifecycle, nothing more. The worker fetches decrypted secrets into memory only for the call that needs them. Composio describes a comparable split on its Enterprise page: credentials stored AES-256 encrypted and decrypted inside its own execution layer, so a customer's developers do not handle raw credentials ([composio.dev](https://composio.dev/enterprise), checked October 2026).

Elaichi does store some secrets itself, also encrypted with an AES-256-GCM key. The list is single sign-on secrets, logging-destination credentials, and model provider keys for the in-app Agent. A reviewer who asks whether any secrets are held by the application tier should get that list, not a flat denial.

## Can we bring our own encryption key in AWS KMS?

No, not today. Customer-managed keys are a Black-plan entry, and customer-managed keys in AWS KMS come with the Black plan, which is launching soon. Black is marked "Launching soon" on /pricing/ and is not on sale. No plan a reader can buy turns this on.

The underlying mechanism exists in the credential service as per-organization envelope encryption under a customer-managed AWS KMS key. What does not exist is any route or console control that switches it on. Write that distinction into the questionnaire. A reviewer who sees "BYOK available" on a marketing page and then cannot find the setting will treat the whole sheet as unreliable.

## Is SSO built in-house or resold from an identity vendor?

In-house. Elaichi's enterprise SSO supports two protocols, SAML and OIDC. Each is wired end to end, with its own login-initiation and callback routes, service classes, and a protocol field on every connection.

The SAML stack uses WebCrypto, node-forge and generic XML libraries; the OIDC stack uses the generic JOSE library. No package or import in the SSO path names a third-party identity vendor. Reviewers who care about the subprocessor list ask this one specifically. An auth vendor in the path is another company holding authentication material.

SSO is a Gold feature, so it is included on both plans a customer can be on.

## Can we force SSO for our domain?

Yes, anchored to a verified domain. An organization proves it owns a domain by publishing a DNS TXT record whose value is `elaichi-domain-verification=<token>`. When a verified domain's SSO connection is enforced, Elaichi refuses any other sign-in for an address on that domain. The refusal is 403 `sso_required`, carrying a login URL to the identity provider.

The check runs on social sign-in, email-code sign-in, signup and invite acceptance. Passkey sign-in for an enforced domain is refused separately with "Passkey sign-in is disabled. Use SSO." Enforcement only applies to an active connection, so deactivating a connection does not leave its enforcement standing.

Removing the verified domain switches enforcement off for addresses on it. That is why removing a domain requires the same step-up confirmation as verifying one.

## Does SCIM deprovisioning remove a member?

No. SCIM deprovisioning suspends a member; it never deletes the member row. `DELETE /Users/{id}` and `active:false` on `PUT` or `PATCH` all resolve to the same suspension call. An Org Owner cannot be deprovisioned this way at all.

Suspension is not cosmetic. It revokes that member's API tokens, MCP OAuth grants and SCIM tokens. Their AI client stops working on its next call, rather than after a cache window. Sending `active:true` later reactivates the membership but does not restore the revoked grants; the person re-consents.

Elaichi's own public SCIM guide says deactivation "removes organization membership." The code suspends. Follow the code.

For where provisioning stops and grants begin, see [SCIM and AI agents](/blog/identity-provider-scim-vs-mcp-grants/).

## How are API tokens stored and displayed?

Stored only as a keyed hash (HMAC-SHA256), in both the token store and the database row. The raw token is never stored.

The value is shown exactly once, in the response that creates it. Afterwards the API returns only metadata: name, owner, last use, dates. The console says "Copy and store this API token now. You can't view it again."

An organization API token has the form `elch_<organization id>_<64 hex characters>` and is bound to the organization it was minted in. It authenticates as the member who minted it, carrying that member's permissions as they stand at each request rather than a snapshot. It stops working when that member leaves, is suspended or is deactivated.

## Can an API token do everything a person can?

No, deliberately less. Routes that require an interactive sign-in session refuse an organization API token. Those routes cover API-token and SCIM-token management, passkeys, two-factor authentication and step-up confirmations. They also cover approving an MCP client's consent request, managing connected-app grants, resolving access requests, and deleting the organization.

Minting a token needs a fresh step-up confirmation every time, bound to the organization the token is for. The 10-minute window that lets some admin actions skip the prompt never applies to it. An API token cannot mint another token.

## Does any Elaichi staff member sign in as our users?

Only where the organization allows it, and always attributed. Staff impersonation is controlled by one per-organization setting, shown in the console as "Elaichi support access" under Settings, Security. Its help text reads: "Lets our team sign in as a member when you ask for help. Visits last 30 minutes and are logged."

New organizations allow it: the default is on, and an organization has to turn it off. Say that to a reviewer rather than implying it is off by default. Seeing it enabled is the unmodified default, not a choice anyone made.

When it is turned off, requests are refused with 403 `staff_impersonation_blocked`, and the check covers reads as well as writes.

## Where does an impersonation session appear in our logs?

In the organization's own audit log, not only on Elaichi's side. Starting and ending a staff impersonation session are each written to the audit log of every one of the target's organizations that allows impersonation. They appear as `staff.user.impersonation_started` and `staff.user.impersonation_ended`, attributed to the staff member's own id rather than to the member whose identity the session wore.

Actions taken during the session carry `actor_kind` staff with the staff user's id in the record. The console renders them as "Elaichi support team," naming neither the staff member nor the member. A staff member impersonating someone is also refused the member's own sign-in security. Two-factor, recovery codes, passkeys and SSO changes answer 403 "This action is unavailable while impersonating."

## What does one tool-call record contain?

Who ran it, which tool, which account, and what it touched. For each connected-tool call that reaches execution, Elaichi writes a record holding the acting user, the toolbox the call went through, and the tool's advertised and catalog names. The same record carries the connector, the connection the call reached, and the tool's classification. It also records whether approval was required and how it was given, whether a person edited the arguments, the surface, the MCP client's id where the surface is MCP, the outcome, and what the call touched.

What it does not hold: argument names, an argument count, or argument values, with one exception. The value of the single URL path argument that names the object is recorded as the target id. A reviewer asking "do you log prompt contents" gets a no; one asking "do you ever log a value" gets that exception.

[What an AI agent audit log must capture](/blog/what-an-ai-audit-log-must-capture/) goes through the field list in detail.

## How long is audit history kept?

Ninety days. The period is set on the log server rather than in configuration a customer changes. An organization that needs longer forwards its events to its own log service. Retention windows differ across this category: Composio's MCP Gateway page says its audit records hold metadata rather than payloads, with a window configurable from 7 days to 1 year ([composio.dev](https://composio.dev/mcp-gateway), checked October 2026).

## Can we forward the audit log to Splunk or Microsoft Sentinel?

No. Three destination types are accepted (Datadog, Splunk HEC, Microsoft Sentinel), but only Datadog delivers. The Splunk HEC and Sentinel forwarders answer 501 "forwarding is not implemented yet" without retrying, and the console labels both "(coming soon)."

Datadog forwarding itself is a Black feature, and export to your own Datadog comes with the Black plan, which is launching soon. A Gold organization reads its audit log in the product and exports a filtered view as CSV, capped at 10,000 entries per file. A reviewer comparing vendors on this will find [the shapes an audit record can take](/blog/audit-log-comparison-mcp-tools/) useful alongside the field list.

## Can admins revoke another person's sessions?

No. A person can sign out of their own current session. Ending all of a person's sessions is an Elaichi staff action. It signs them out of every browser and device, leaves API tokens alone, and also happens when staff deactivate the account. Customers and organization admins have no session list and no sign-out-everywhere control.

What an admin can do instead reaches further than a session. Removing or suspending a member revokes their MCP grants, API tokens and SCIM tokens, so their AI clients fail on the next call.

## What stops a compromised admin account deleting everything?

Org Admin holds every permission except `billing:manage` and `org:delete`. The omission is deliberate. Elaichi's own code says owners hand Org Admin out freely, and keeping deletion with the owner means an attacker who lands an admin account "cannot delete the evidence along with the workspace."

Deleting an organization also requires typing the organization's slug, which the server re-checks, plus a step-up confirmation. For 30 days afterwards anyone holding `org:manage` can restore it, and that restore needs an active subscription.

## Does deleting an organization erase all of our data?

No, and the completed deletion says so. Three stores remain. The organization's audit history stays, because there is no tenant-scoped delete on the log store. Its usage-analytics rows stay, because that store has no delete API. Some credential-service configuration records stay as well. Connection credentials themselves are deleted, at once when the deletion is scheduled and again at the final purge.

Elaichi also keeps its own record of the deletion on purpose: who asked, and the organization's slug, name, region, plan and stated reason.

## Where does our data live?

There are three regions, EU, US and APAC, chosen when the organization is created and not changeable afterwards. For EU and US organizations, the per-organization data store is pinned to that jurisdiction, and org-scoped requests execute there. APAC uses best-effort placement, which is not a residency guarantee.

Some stores are not placed by region. Every organization's audit trail, whatever its region, is stored in one log instance in the EU. The privacy policy, the DPA and the GDPR page all state it. Files stored from tool results go to one private bucket in the EU for every organization. Residency answers vary by vendor: Zapier's MCP security page says customer data is stored in AWS US-East 1 and that region-specific data residency is not available unless otherwise agreed ([docs.zapier.com](https://docs.zapier.com/mcp/manage/security), checked October 2026). [EU data residency for AI agents](/blog/eu-data-residency-ai-agents/) walks each leg of the request path.

## Do you have SOC 2, ISO 27001 or HIPAA?

Elaichi's footer shows SOC 2 Type II, ISO 27001, GDPR and HIPAA badges. Each links to the Trust Center at https://trust.elaichi.ai, beside a link reading "Reports and certificates in the Trust Center." Attribute each one to the Trust Center and send the reviewer there for the report itself. Nothing in the product establishes a certification.

## Is a Business Associate Agreement included?

No, not by default. Elaichi states it is HIPAA compliant, as the Trust Center does, but a Business Associate Agreement is not offered by default. Protected health information is allowed only where an Order Form expressly permits it and a BAA has been executed. [AI agents and PHI](/blog/hipaa-ai-agents-baa-reviewer-questions/) sets out the questions to put to a reviewer before anyone connects a clinical system.

## Does an AI client's token reach everything a person can?

No, only what the grant covers, re-checked every call. Each grant covers one organization and acts as the person who approved it. Consent splits into four checkboxes: read your organization's data, create and change data, run your connected tools, delete data and remove access. Delete is never pre-ticked, even when the client asks for it.

A grant also chooses toolbox reach, either everything the person can run or one to 50 named toolboxes. Every MCP request re-reads the grant from the organization's data store, so disconnecting a client fails its very next request with a 401.

Access tokens are bearer tokens, not bound to a device, valid for one hour from issue or until the grant is revoked. Refresh tokens last 30 days and are single-use; presenting a used one within 30 days revokes the whole grant.

The client adds a layer of its own. Anthropic documents Claude's connector tool permissions as Always allow, Needs approval or Blocked, set on a whole connector, a category of its tools or a single tool ([support.claude.com](https://support.claude.com/en/articles/11176164-use-connectors-to-extend-claude-s-capabilities), checked October 2026). Because no tool in Elaichi's MCP list names a connected app, such a setting acts on execute_tool as a whole. Per-app and per-tool control is set in Elaichi, as restrictions.

## How quickly does a permission change take effect?

It depends which change, and a reviewer will catch a vendor that blurs the two.

Grant revocation, member removal, member suspension, revoking a share and disconnecting an account are effective on the next call. The grant and the toolbox resolution are re-read per request.

Role changes, team-membership changes, restriction edits and access-grant approvals take about two minutes. Member context and resolved restrictions are cached for 60 seconds under keys that include a per-organization epoch. The worst case at a remote point of presence is about two minutes: up to 60 seconds for the write to propagate, plus up to 60 seconds of edge caching on the epoch read. That is a worst case, not the typical delay. [How the restriction resolver decides](/blog/restriction-resolver-decision-tree/) sets out what is evaluated before a call leaves.

If a questionnaire needs a single sentence: credential-shaped changes take effect on the next call, policy-shaped changes within about two minutes.

## When you do not need this sheet

If three people use AI with one app each, on their own accounts, a questionnaire about a control plane is premature. The honest answer is to connect the app's own MCP server and let the app's permission model do the work. Revisit when a second app, a second team or an auditor arrives. [When you don't need an MCP gateway yet](/blog/when-you-dont-need-an-mcp-gateway/) makes that case properly.

The sheet earns its keep when the answers have to hold across apps from different vendors. They also have to survive people joining and leaving, with evidence an auditor will read. For the control side of that, see [MCP governance](/blog/mcp-governance/); for the evidence side, [SOC 2 evidence for AI agents](/blog/soc2-evidence-ai-agents-cc-controls/). The catalog itself is at /connectors/.

## FAQ

### What encryption does Elaichi use for stored connector credentials?

Connector secrets are encrypted at rest with AES-256-GCM. Each ciphertext records the id of the key that wrote it, so the encryption key can be rotated without re-encrypting older rows. The secrets live in a separate credential service rather than in Elaichi's main data, and are fetched decrypted into memory only for the call that needs them. Elaichi also stores single sign-on secrets, logging-destination credentials and assistant model provider keys itself, encrypted with an AES-256-GCM key.

### Can a customer use their own AWS KMS key with Elaichi?

No. Customer-managed keys in AWS KMS come with the Black plan, which is launching soon, and Elaichi has no route or console control that turns the feature on. The credential service has the underlying mechanism, per-organization envelope encryption under a customer-managed key, but there is nothing a customer can switch on today, and Black is not on sale.

### Are Elaichi API tokens recoverable after creation?

No. An API token's value is shown exactly once, in the response that creates it. Elaichi stores only a keyed hash (HMAC-SHA256) of the token, in both its token store and its database row, so the raw value cannot be returned later. Afterwards the API returns only metadata such as name, owner, last use and dates. A lost token is replaced by minting a new one, which requires a fresh step-up confirmation.

### Does Elaichi support SSO and SCIM, and on which plan?

Yes. Elaichi supports SAML and OIDC single sign-on and SCIM 2.0 provisioning, both included on the Gold plan and on Black, which contains Gold. The SAML and OIDC stacks are implemented in-house using WebCrypto, node-forge, generic XML libraries and the JOSE library; no third-party identity vendor sits in the SSO path. SCIM deprovisioning suspends a member rather than removing them, and suspension revokes that member's API tokens, MCP grants and SCIM tokens.

### Where do Elaichi staff impersonation sessions get recorded?

In the customer organization's own audit log as well as Elaichi's internal staff-audit table. Starting and ending a session are written as staff.user.impersonation_started and staff.user.impersonation_ended, attributed to the staff member's own id. Actions taken during the session carry an actor kind of staff, and the console shows them as "Elaichi support team." An organization can turn staff access off in Settings, Security, after which such requests are refused with 403 staff_impersonation_blocked; the setting is on by default.

### How long does a role or restriction change take to apply in Elaichi?

Role changes, team-membership changes, restriction edits and access-grant approvals take effect within about two minutes. Member context and resolved restrictions are cached for 60 seconds under a per-organization epoch, and the worst case adds write propagation plus edge caching on top. Grant revocation, member removal, member suspension, revoking a share and disconnecting an account are different: they are effective on the next call, because the grant and toolbox resolution are re-read on every request.

## Read next

- [MCP audit log comparison: what each shape records](/blog/audit-log-comparison-mcp-tools/) — An MCP audit log comparison across four shapes: what each one records about intent, the account reached, arguments, and whether AI actorship is a field.
- [GDPR Article 30 AI agent entry, field by field](/blog/gdpr-article-30-ai-agent-processing/) — A GDPR Article 30 AI agent entry needs recipients, transfers and retention. Elaichi's audit row fills part of it; your role design fills the rest.
- [FedRAMP MCP AI agent access: when to buy and when to wait](/blog/fedramp-adjacent-posture-us-federal/) — How to evaluate fedramp mcp ai agent access when the vendor has no authorization, and when the right call is to wait.