# Is Elaichi Secure? A Reviewer's Walkthrough

> Is Elaichi secure: how sign-in, per-person grants, restrictions, the audit log and regions work, and where the MCP endpoint stops.

**TL;DR** Elaichi serves one MCP endpoint that Claude, ChatGPT, Cursor and Microsoft Copilot all sign into with OAuth, and every call runs as the person who approved that grant. Roles and restrictions decide which connectors and tools that person can reach, and every call that reaches execution is written to the audit log. The honest limit: Elaichi's MCP endpoint has no prompt-injection defense of its own, and certifications belong to the Trust Center rather than to a claim in a blog post.

## Is Elaichi secure? What a reviewer is actually approving

**Disclosure:** this is vendor documentation. Elaichi wrote it to give security reviewers the specific facts a review of Elaichi actually turns on. It is not a third-party audit and not a neutral comparison. Treat every Elaichi-specific claim below as a vendor claim, to verify against the linked primary sources: RFCs, the Trust Center's underlying reports, and Elaichi's own policy pages. Treat every protocol claim (OAuth, PKCE, MCP) as independently checkable against its spec, linked where it first appears.

Somebody in your company has asked for Elaichi, and the request reads like a small one: add one URL to Claude or ChatGPT. Your job is to work out what that URL reaches, who it acts as, and what record is left behind. "Is Elaichi secure" is the wrong shape of question to answer with a yes. So this post answers the parts a review actually turns on: sign-in, grants, roles and restrictions, approvals, the audit log, regions, and the limits.

MCP is the [Model Context Protocol](https://modelcontextprotocol.io/), an open spec for how an AI client discovers a server's tools and calls them. This part is protocol fact, true of any MCP implementation, not specific to Elaichi. Elaichi serves it at one address, `https://api.elaichi.ai/mcp`, the same string for every organization, and this part is Elaichi-specific. Which organization and which person a client reaches comes from the OAuth grant behind its token, not from the URL. OAuth here means the sign-in flow that ends with the client holding a token issued to one named person.

Two things follow from that design. There is no per-user, per-team or per-client MCP address to issue, rotate or leak. And there is no shared service account behind the endpoint: every call acts as somebody, by construction, because the token is bound to the person who completed consent.

## How does sign-in and consent work?

A person connects their own AI client once, signs in to Elaichi in a browser, and approves a consent screen. That approval creates a grant, and the grant is what the client's token carries.

MCP clients register themselves through [OAuth dynamic client registration (RFC 7591)](https://datatracker.ietf.org/doc/html/rfc7591) at `POST https://api.elaichi.ai/oauth/register`. The registration mechanism is the RFC's; the endpoint is Elaichi's. Registration is open and needs no Elaichi credential, so nobody is pasting a client ID or secret into a chat app. PKCE with S256 is mandatory; a request with a missing `code_challenge_method` is refused rather than assumed. A registered redirect address must match exactly. The one exception is a loopback address, which may use a different port, as [RFC 8252 section 7.3](https://datatracker.ietf.org/doc/html/rfc8252#section-7.3) describes for native apps.

| Credential | Lifetime | What happens at expiry/reuse |
|---|---|---|
| Authorization code | 60 seconds | Expires unused; single use |
| Access token | 1 hour | Client must refresh |
| Refresh token | 30 days | Reuse of an already-used token, or use from a different client, revokes the whole grant |

The consent screen draws a checkbox per scope the client asked for:

| Scope (checkbox label) | What it unlocks |
|---|---|
| See your organization (`mcp:read`) | Elaichi's own read and sensitive-read operations |
| Make changes (`mcp:write`) | Elaichi's own write operations |
| Use your connected apps (`mcp:tools`) | Running connected tools, every tier, deletes in the connected app included |
| Delete things (`mcp:destructive`) | Elaichi's own destructive operations |

Read the first, second and fourth rows as Elaichi's own operations, not as tiers of access to a connected app. Connected tools run on `mcp:tools` alone, whatever they do.

Delete is never pre-ticked, even when the client requests it. The person can untick anything, and the server refuses any scope the client did not request. So consent narrows a request but never widens it. A grant's scopes never change after consent. Each grant covers exactly one organization, picked on that screen and not changeable later without connecting again.

The screen states the risk plainly: anyone can register an app under any name and logo, because dynamic client registration (RFC 7591) has no identity vetting step. Elaichi shows a bundled logo only for seven clients whose registered redirect addresses all match that client. Everything else shows the name the client gave itself, flagged as self-reported. A reviewer should read "self-reported name" as equivalent to "unverified". Do not treat the displayed name as proof of the calling application's identity.

If a verified domain's SSO connection is enforced, signing in any other way for an address on that domain is refused with the error code `sso_required`. That refusal does not run on passkey sign-in; it covers social sign-in, the emailed code, signup and invite acceptance. SSO means SAML or OIDC single sign-on. Elaichi implements both protocols itself rather than wrapping a third-party identity vendor. An organization can also require two-factor authentication of its members. A member with no second factor is told to set one up before their AI client works again; they do not have to reconnect once they have one configured.

## Per-person grants, roles and restrictions

Every call made with a grant's tokens acts as the person who approved it, in the organization they picked. Their permissions are looked up on each request rather than frozen into the token at consent time. That lookup-on-each-call design is why a permission change propagates without the person reconnecting, as the timing note below sets out.

Three layers decide what a person reaches, and a review goes wrong when they are mixed up:

| Layer | Question it answers | Granularity | Who sets it |
|---|---|---|---|
| **Permissions** | Can this role perform this action at all? | One role per member: 8 system roles, or a custom role an admin authors | Admin, via role assignment |
| **Sharing** | May this person use this specific connection, toolbox or template? | Per object, at view / use / edit | Whoever owns the object |
| **Restrictions** | Which connectors/tools may this role or this specific member reach? | Per role or per individual member, never per team, never org-wide | Admin, via allow/block rules |

`tool:execute` is the permission that matters most for an MCP review. A role without it gets an empty tool list and every call refused, regardless of what the grant's scopes say. Guest, Billing Admin and Auditor lack it by default. The full three-layer model, including the complete role list, is in [roles, restrictions and ACLs](/blog/roles-restrictions-acls-three-mechanics/).

On sharing: no organization-level permission widens a listing. An Org Owner sees only what they own or what was explicitly shared with them. Ownership of the org is not the same as visibility into every connection in it.

On restrictions: a rule targets a role or a single member, never a team and never the whole organization. A member is governed by their role's rules and their own personal rules at once. A personal rule can only narrow what the role allows; it cannot grant back something the role denies. An allow rule turns on an allowlist for its layer just by existing: **an allow rule that names nothing blocks everything for its target.** Test this in a pilot before it locks somebody out; [the allow rule that blocks all tools](/blog/empty-allow-rule-denies-everything/) covers the trap in detail.

Restrictions bind the operation a tool performs, not the label it is shown under. Allow rules match a pinned operation, and block rules match by name or operation, so renaming a tool cannot slip it past a block. A block on a connector also catches every fork that declares descent from it. See the scoping caveat in the next section: forking from the same API, rather than the same connector, does escape it.

Enforcement is not one checkpoint. It runs wherever a member can reach a connector or tool. That covers listing connectors, connecting an account, saving a toolbox entry, advertising tools to a client, and executing a call. A final check compares the resolved outbound URL, and every redirect hop, against the tool-level blocks. [Where restriction enforcement sits](/blog/restriction-resolver-four-enforcement-points/) walks each point.

For a team that should share one setup, a toolbox is a named list of tool entries, each pinned to one connection. An entry can carry frozen parameters, argument values a caller cannot override on calls that run through that entry. A frozen value is locked, not hidden: the AI client can see that it is set, and often what it is set to, but cannot change it.

**Put this timing in your runbook, because it determines how fast an access change actually takes effect:**

- A role, team, restriction or access-grant change takes effect about two minutes, not instantly.
- Revocation is handled separately: removing or suspending a member revokes every live grant in the same transaction as the membership change.
- In Elaichi, revoking a share or disconnecting an account takes effect on the caller's next call.

## Governing two kinds of connector under one set of rules

Elaichi's catalog runs to 650+ connectors, in two kinds:

1. **Elaichi-authored connectors.** Elaichi builds and runs the server; this is most of the catalog.
2. **Native MCP connectors.** The vendor builds and runs its own MCP server; Elaichi sits in front of it for sign-in, access control and audit.

A team on the Gold plan can also bring its own remote MCP server in as a connector. That requires the `connector:create` permission and an Org Owner or Org Admin role.

The review point: the rules do not change by origin. For a native MCP connector, restrictions and OAuth scopes are checked before a call leaves Elaichi. Only a tool on that connection's own active list can run. Every call that reaches execution is written to the audit log, naming the person, the connector, the connection and the MCP client. By default, a tool the vendor's server does not explicitly mark read-only or non-destructive is treated as destructive. That is a fail-closed default, not an assumption that most tools are safe.

Credentials do not sit in Elaichi's main application data store. A separate credential service holds every connected account's secrets encrypted with AES-256-GCM. Each ciphertext records which encryption key wrote it, so keys can be rotated without re-encrypting old rows. Elaichi fetches a credential into memory only for the single call that needs it. The AI client itself only ever holds an Elaichi-issued token, never the underlying credential, and Elaichi never forwards its own MCP access token to a remote MCP server.

Scope a block carefully. This is the one place the "forks are caught" rule above has a real limit. A connector's identity for restrictions is its own slug plus its declared fork lineage, not the host it calls. A connector built from scratch against the same underlying API as a blocked one is **not** caught by that block, because it declares no lineage to the blocked connector. That gap is the specific reason `connector:create` is the one permission Elaichi flags as high trust: anyone who can register a new connector can route around an existing block.

## Data residency and the audit log

Elaichi runs three regions, EU, US and APAC, chosen when an organization is created and not changeable afterward.

| Data category | EU / US orgs | APAC orgs | Notes |
|---|---|---|---|
| Per-org data store, execution of org-scoped requests (incl. `POST /mcp` and connected-tool calls) | Pinned to the chosen jurisdiction | Best-effort placement, not a residency guarantee | Review APAC as a weaker commitment, not equivalent residency |
| Sessions, tokens, short-lived caches | Not pinned to any region | Not pinned to any region | Applies to all orgs regardless of region |
| Files stored from tool results | One EU bucket, all orgs | Same EU bucket | Expire after 7 days |
| Audit trail | One EU log instance, all orgs | Same EU log instance | Stated identically in Elaichi's privacy policy, DPA, and [GDPR page](/gdpr/) |

If regional placement is a hard requirement for your assessment rather than a nice-to-have, read the exceptions row by row before signing. [EU data residency for AI agents](/blog/eu-data-residency-ai-agents/) walks through each one.

The audit log is append-only, with its own tenant per organization. Elaichi's log client can insert and query; the API exposes a single read route and nothing that edits or deletes an entry. In Elaichi, one entry for each connected-tool call that reaches execution (a call refused earlier writes none). Argument values are not recorded in the log, with one exception. The single path argument that names the target object is kept as a target id, so you can trace which record a call acted on without the log capturing full payloads. If you want to see what that trail looks like in practice, [reading the audit log across Claude, ChatGPT and Cursor](/blog/which-tools-ai-agents-call/) walks through the fields a real call leaves behind.

Be precise about coverage when you write this into a control description, because the obvious phrasing is wrong. A call refused *before* execution, because a restriction withheld it or it was missing a scope, writes no audit row. The refusal happens before any executor runs. So "every call that runs is logged" is an accurate claim. "Full audit logging of the endpoint, including denials" is not, and a reviewer who writes the second version into a compliance doc is overstating coverage.

Retention is 90 days. For longer retention, forward events to your own log service: logging destinations come with the Black plan, and Datadog is the destination currently supported. [What an AI agent audit log must capture](/blog/what-an-ai-audit-log-must-capture/) is a vendor-neutral checklist of the fields any MCP gateway's audit log should have, useful for comparing Elaichi against alternatives rather than taking this claim alone.

## Approvals: what Elaichi asks, and what it does not

Over MCP, the approval moment is the consent screen described above. There is no per-call approval step on the MCP path itself. The scopes a person granted a named client there are the standing approval for every one of that client's subsequent calls. A confirmation dialog a person sees mid-chat is their AI client's own UI, not anything Elaichi enforces.

That distinction matters for how you design controls:

- `mcp:tools` as a scope covers every tier of connected tool, writes and deletes included. The "Delete things" consent checkbox only covers Elaichi's *own* deletes (for example, disconnecting an account), not a connected app's delete operations.
- To hold a client to read-only access, you have two real options: pick toolboxes composed only of read tools at consent time, or block the write/delete tools with a restriction.
- Do not rely on a client-side "read-only" toggle in the AI app itself as your control. `execute_tool` runs whatever arguments it is handed, and is annotated destructive for exactly that reason. The client-side toggle is advisory to the model, not enforced by Elaichi.

Per-call approval cards, remembered choices, and a second-model write gate exist in the Elaichi Agent product, which ships with the Black plan. These are not part of the MCP path and should not be assumed present when reviewing MCP-only usage.

Eight Elaichi operations, among them inviting a member, changing a member's role, and deleting a role or team, are refused on every AI surface, in the Elaichi Agent and over MCP alike, because the console's equivalent demands a fresh interactive identity check. Six of them are never listed over MCP at all. No scope or role combination grants an AI client the ability to perform them.

## Credentials, tokens and sensitive actions

An organization API token is bound to the organization it was minted in and authenticates as the member who minted it. It carries that member's permissions as they stand *at each request*, not as they stood at mint time. It stops working the moment that member leaves, is suspended, or is deactivated. Elaichi stores only a keyed hash of the token; the raw value is shown once, at creation, and cannot be retrieved again. Tokens do not expire on their own, so a leaked token must be actively revoked and replaced; it is not a self-limiting risk.

An API token reaches strictly less than the person's own interactive session. Routes that require interactive sign-in and refuse a bare API token include: token and SCIM-token management, passkey management, two-factor settings, approving an MCP client's consent request, managing connected-app grants, resolving access requests, and deleting the organization.

Elaichi requires step-up confirmation before 31 sensitive actions, split into two classes:

| Class | Example actions | Re-confirmation window |
|---|---|---|
| Credential and account actions | Minting an API token, adding a passkey | Every time, no window |
| Governance actions | Removing a member, changing a role | Covered by a confirmation made in the last 10 minutes |

Some actions remove or weaken a sign-in protection. For a person who already has a passkey or an authenticator app, those actions never accept an emailed one-time code as the step-up factor. A weaker factor cannot downgrade a stronger one that is already set up.

## Trust Center, and the two limits a review should record

Certifications are not something to take on a vendor's prose; verify them against the underlying report. SOC 2 Type II, ISO 27001, GDPR and HIPAA are stated at Elaichi's Trust Center, https://trust.elaichi.ai, which links the reports and certificates. A reviewer should request the report directly and check the auditor's name, the audit period, and the scope of systems covered. A Trust Center badge by itself is a claim, not evidence; the report behind it is the evidence.

On HIPAA specifically, read the claim narrowly. Elaichi states it is HIPAA compliant, matching the Trust Center, but a Business Associate Agreement is **not** offered by default on all plans. Protected health information is permitted only where an Order Form expressly permits it and a BAA has been executed for that organization. If PHI is in scope for your use case, do not proceed on the general compliance statement. Start with [four questions for your BAA](/blog/hipaa-ai-agents-baa-reviewer-questions/).

Two limits belong in the same paragraph as the strengths, not buried after them:

**First: Elaichi's MCP endpoint has no prompt-injection defense of its own.** Nothing on the `POST /mcp` path scans tool results for injected instructions or second-guesses a call before executing it. This is architectural, not a gap to be patched. The endpoint receives a tool name and arguments from a `tools/call` message, never the person's original prompt, so it has no prompt text to evaluate a call against. The heuristic injection scan and the second-model write gate that Elaichi does offer live in the Elaichi Agent product (Black plan), which does see the person's typed request. On the bare MCP path, injection defense is the client's job, or a gateway's.

If you already run your own MCP servers and want an existing API gateway in front of them, that is a different layer of the stack. [AI gateway vs MCP gateway](/blog/ai-gateway-vs-mcp-gateway/) distinguishes which job each layer does.

**Second: secret scrubbing is a backstop, not a boundary.** Elaichi replaces secret-named keys and a handful of known value shapes in tool results before they leave the system. Elaichi's own product documentation describes this as defense in depth sitting behind the credential vault, not as a guarantee. Other secret formats, and anything not matching a known shape or key name, pass through unscrubbed.

**Third, a scope boundary rather than a limit:** deleting an organization does not remove everything. The purge removes connections and their credentials, custom connectors, conversations, tokens and grants, the data store and its rows. The audit history, usage analytics rows, and some connector configuration records are retained. A completed deletion report names exactly which records survive.

## When the answer is that you do not need this

If nobody at your company has connected an AI client to a work app yet, and your assistants are used for drafting rather than acting, a control plane is premature. The control you need first is a decision about which assistants are allowed and what may be pasted into them. That is a policy problem, not an infrastructure problem. [When you don't need an MCP gateway yet](/blog/when-you-dont-need-an-mcp-gateway/) makes that case in full.

Suppose one team uses one app through that vendor's own MCP server, and the vendor's admin console already gives you per-person sign-in and an audit log you trust. You are not obviously better off adding a layer in front of it. The argument for a single gateway address gets stronger as the number of apps, clients and teams multiplies. That is the point at which per-client configuration becomes something nobody can inventory by hand.

If you are mid-review and want the question list rather than a vendor's answers to it: [how to evaluate an MCP gateway](/blog/mcp-security-review-checklist/) is a vendor-neutral checklist, and [20 answers to a vendor security questionnaire](/blog/vendor-security-questionnaire-ai-agent-access/) covers the questionnaire format directly. For Elaichi specifics: the connector catalog is at [/connectors/](/connectors/), and plan boundaries, including which features require Gold or Black, are on [/pricing/](/pricing/).

## FAQ

### Does Elaichi use a shared service account to reach company apps?

No. Every call through Elaichi's MCP endpoint acts as the person who approved that OAuth grant, in the organization they picked at consent. Each person connects their own AI client once and approves their own grant, and the person's permissions are looked up on each request rather than stored in the token. Where a tool should act as the individual in the connected app, it must run on that person's own connection; a connection shared with a team runs every caller's call as the connection's owner instead.

### What happens to an AI client's access when someone leaves the company?

Removing or suspending a member in Elaichi revokes every live MCP OAuth grant they hold in that organization, inside the same operation that changes the membership. Because grants are re-read on every request, their AI clients fail on the next call rather than when the token expires. Reactivating the member does not restore the grants; they have to go through consent again. A SCIM deprovision suspends rather than removes, with the same effect on grants.

### Does Elaichi protect against prompt injection?

Not on the MCP endpoint. Nothing on Elaichi's POST /mcp path scans tool results for injected instructions or re-checks a proposed call, because the endpoint only receives a tool name and arguments and never sees the person's own prompt. Elaichi's heuristic prompt-injection scan and its second-model write gate run in the Elaichi Agent, which comes with the Black plan and does have the person's typed request to judge against. On the MCP path, that defense belongs to the client.

### Which certifications does Elaichi hold, and is a BAA included?

SOC 2 Type II, ISO 27001, GDPR and HIPAA are stated at Elaichi's Trust Center, https://trust.elaichi.ai, which holds the reports and certificates. 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.

### Where is an organization's data stored, and can the region be changed?

An organization picks EU, US or APAC when it is created, and the region cannot be changed afterwards. For EU and US organizations, the per-organization data store and the execution of org-scoped requests, including MCP calls and connected-tool calls, are pinned to that jurisdiction; APAC uses best-effort placement and is not a residency guarantee. Some stores are not regional: files from tool results go to one EU bucket for every organization, and every organization's audit trail is stored in one EU log instance, as Elaichi's privacy policy and DPA state.

### How quickly does a restriction change take effect?

A role, team, restriction or access-grant change in Elaichi takes effect about two minutes, because the resolved permissions are cached briefly at each location. Revocation works differently: removing or suspending a member revokes every live grant in the same transaction as the membership change. In Elaichi, revoking a share or disconnecting an account takes effect on the caller's next call.

## Read next

- [How to evaluate an MCP gateway: security checklist](/blog/mcp-security-review-checklist/) — How to evaluate an MCP gateway before you approve it: ten questions for every vendor, what a good answer looks like, and Elaichi's own answers.
- [Vendor Security Questionnaire AI Access: 20 Answers](/blog/vendor-security-questionnaire-ai-agent-access/) — Twenty vendor security questionnaire ai access questions, answered with the mechanism: which key, which role, which log row.
- [Which tools AI agents call: read the audit log](/blog/which-tools-ai-agents-call/) — One audit log across Claude, ChatGPT and Cursor records which tools AI agents call, naming the person, the client, the connector, the tool and the outcome.