A sales lead asks to connect Claude to the CRM, and the request lands on the security team's desk. This MCP security review checklist is the set of questions to send before approving an MCP server, or a gateway or control plane in front of several. Each comes with what a good answer looks like, and with the answer Elaichi gives.
MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps. An MCP server exposes one app's actions as tools. A gateway or control plane puts one address and one set of rules in front of several. Either way, the review asks the same thing: who can make an AI act in which system, and what record is left behind.
What belongs on an MCP security review checklist?
Ten questions, in seven areas: sign-in and tokens, consent, how narrow access can get, how fast it ends, what the record holds, where data lives, and what the product does not cover. Copy the table into your vendor review and ask for every answer in writing.
| # | Ask the vendor | A good answer |
|---|---|---|
| 1 | How does each person sign in? | OAuth per person, with PKCE, and no token in a URL |
| 2 | Where do the app credentials live? | Outside the gateway, AES-256-GCM at rest, in your region, with failed refreshes visible |
| 3 | What does consent show and pre-tick? | The client's name and redirect, and nothing destructive by default |
| 4 | Can a rule cover one tool for one role? | Yes, written against the operation, not the tool's label |
| 5 | Where is a rule enforced? | At execution, not only when tools are listed |
| 6 | How fast does access end? | Removal on the next request, and a stated figure for rule changes |
| 7 | What does one audit record hold? | The person, the client that made the call, the account reached, the outcome |
| 8 | What does the log leave out? | Argument values and third-party error text |
| 9 | Where does data live, and what survives deletion? | A named region, a stated guarantee, a named residue |
| 10 | What does the product not protect against? | A written list, with prompt injection on it |
How does each person sign in, and where do tokens sit?
Each person should sign in with their own OAuth grant, and no token should travel in a URL. OAuth is the standard for delegated sign-in that never hands the client a password. The MCP authorization specification requires authorization on every HTTP request and bans tokens from the query string. It also says a server must not accept or pass along tokens issued for anything else.
Elaichi has one address for every organization, https://api.elaichi.ai/mcp. There are no per-toolbox URLs and no embedded tokens. Clients register themselves through dynamic client registration (RFC 7591), and PKCE with S256 is required. The redirect address must match the registered one exactly (a loopback address may change port, never host), and a resource on any other origin is refused with invalid_target. That resource check runs when the token is issued.
An access token lasts one hour. A refresh token lasts 30 days and rotates on every use, and reusing an old one revokes the whole grant. Elaichi stores only a keyed hash of each token, never the raw value.
App credentials are not in Elaichi at all. A separate credential service holds them in the organization's region, with AES-256-GCM at rest, and owns refresh. Each ciphertext records the ID of the key that wrote it, so the encryption key can be rotated. A failed refresh marks the connection needs_reauth instead of failing quietly.
One gap to record: the current specification prefers client ID metadata documents and keeps dynamic registration for backward compatibility. Elaichi does not advertise metadata documents. OAuth versus long-lived keys for agents covers why a per-person grant beats a shared key.
What does the consent screen ask a person to approve?
It should name the client, show where the tokens go, and leave destructive access unticked. The MCP security best practices require a proxy's consent page to name the requesting client, list the scopes and show the registered redirect URI.
Elaichi's consent screen names the requesting app and shows the host it sends the person to, with the full address one click away. It also warns that anyone can register an app under any name and logo. The person picks one organization, then chooses from four boxes: read data, create and change data, run connected tools, and delete data and remove access.
Every scope the client requested is pre-ticked except delete, which is never pre-ticked. A client that requests no scope gets read only. Consent can narrow a request but never widen it.
When "run connected tools" is ticked, a second step asks which toolboxes the grant reaches. "All my tools" is the default and includes accounts connected later. "Only the ones I pick" allows up to 50. If you want tighter grants, tell people which option to choose.
Can access be narrowed to one tool for one role?
It should be, and the rule should run on the server, not in the model. OWASP's LLM06 Excessive Agency traces agent damage to excessive functionality, permissions and autonomy. It recommends the minimum necessary permissions, enforced in downstream systems rather than left to the model.
Elaichi keeps three layers apart. Each member holds exactly one role. A member sees only what they own or what was explicitly shared with them. Restrictions then decide which connectors and which individual tools a target may reach. In Elaichi, restriction targets are role or user only; the organization default is the absence of a rule, which means allow everything. A rule on a user replaces the role rules for that user rather than adding to them. Within the winning layer, blocks beat allows.
Rules bind the operation, not the advertised label, because whoever edits a connector's documentation can rename a tool. Enforcement runs at browse, connect, advertise and execute, plus a final check on the fully substituted outbound URL. A tool a restriction withholds is invisible, and its name never goes on the wire. A delete also needs the mcp:destructive scope.
Test one trap before go-live: the allowlist stage engages on the presence of an allow rule, not its contents, so an allow rule that names nothing denies everything. Why blocks and allows match differently explains the operation rule.
How quickly does access end when someone leaves?
Removal should land on the next request, and the vendor should give a figure for rule changes. In Elaichi, removing or suspending a member revokes every live grant in the same transaction as the membership change. The grant is re-read on every call, so the removed person's next call fails. Revoking a share or disconnecting an account also takes effect on the next request.
A role or restriction change takes about two minutes, through a 60-second cache and edge propagation. Write that figure into the control description before a tester measures it. During an incident, suspend the member or revoke the grant. Do not edit a rule and wait.
SCIM is the standard an identity provider uses to provision and deprovision users. A SCIM deprovision in Elaichi suspends the member and never removes them. Suspension still ends every live grant. Removal is a separate step, with an offboarding preflight that refuses while a toolbox entry still references the leaver's personal connection. A contractor's last day, step by step walks through that sequence.
What should one audit record hold for an AI tool call?
The person, the client that made the call, the account actually reached and the outcome, with nothing secret in it. Elaichi writes one entry per tool-call attempt, succeeded or failed. Each entry names the operation and tool, the connection, the classification, whether the call was approved, the outcome and an error code. The account recorded is the one the call reached, taken from the execution rather than the request.
Each entry also records which client made the call. Claude, ChatGPT and Cursor are marked verified. A loopback client such as Claude Code shows its self-registered name, marked unverified. Each person can see and disconnect their own clients in Settings, under Connected apps.
actor_kind is a stored field, not a guess. Its values include user, scim, api_token and ai_assistant, which marks Elaichi's own in-app agent. A call from Claude, ChatGPT or Cursor is recorded under the person who signed in, with the surface and the client named. The trail keeps argument names and counts, and never argument values. The error written to the audit trail is never derived from the third party's response, which keeps a remote error body out of your log pipeline.
The trail is append-only, newest first, and kept in one log tenant per organization. It is eventually consistent, so a row may take a moment to appear. A reviewer reads it from the Auditor role, a free read-only seat that cannot call tools. Beyond the in-app trail, export to your own Datadog comes with the Black plan, which is launching soon. The fields an agent audit log needs lists the full record.
Where does the data live, and what survives deletion?
A good answer names the region, says exactly what the region covers, and names what deletion leaves behind. Elaichi has three regions, eu, us and apac, chosen when the organization is created and fixed after. In each, the organization's own store stays in that region. That store holds members, roles, connections, restrictions and OAuth grants. Connector credentials are stored in the organization's region too, encrypted with AES-256-GCM, and every request and tool call runs in that region. The credential is read and the app is called from inside it.
Several things sit outside the region. User accounts, sign-in sessions, API tokens, SSO settings and MCP OAuth token records (as keyed hashes) are kept globally. Tool-result files go to an EU bucket for every region, us and apac included. An eu organization's audit trail stays in the EU. The eu region is available on every plan.
Deletion has a gap that belongs in your data map. Deleting an organization tears down the workspace and deletes the connector credentials. Three stores keep residue: the audit log tenant, analytics events, and the credential service's connector configuration rows. Elaichi returns that residue by name rather than hiding it. For key custody, customer-managed keys in AWS KMS come with the Black plan, which is launching soon.
Whether Elaichi holds SOC 2, ISO 27001 or HIPAA attestations is answered in the Trust Center. SOC 2 evidence for agent access maps a control plane's records to the criteria, and what a BAA reviewer asks about agents covers health data.
Which MCP security risks does a gateway or control plane leave open?
Prompt injection is the largest, and no gateway or control plane closes it. OWASP's LLM01 Prompt Injection describes the indirect kind: instructions hidden in a web page or file the model reads. OWASP adds that a fool-proof prevention may not exist. An MCP server never sees the user's prompt, so it has nothing to judge. The prompt-injection write gate lives in the Elaichi agent window and does not apply to a raw tool call.
What holds on Elaichi's side limits the damage. It enforces role-based permissions per operation, a forbidden classification that no OAuth scope can reach, output redaction, OAuth scope limits and full audit logging. OWASP recommends two defenses that match: least privilege, and human approval for high-risk actions. Approval belongs in the client, so switch it on for writes wherever the client offers it.
Two other risks sit outside any remote gateway. The MCP security best practices describe local server compromise, where a server installed on a laptop runs code with the client's privileges. A control plane never sees that server. Text pasted into a chat window never reaches it either. Both belong to endpoint controls, a CASB (cloud access security broker) and DLP (data loss prevention), as what a CASB can and cannot see explains.
How do you take AI agents on company data through a security review?
Arrive with an inventory, the rules and a record, not a promise. Reviewers approve a design they can test, and six steps produce one.
- List the AI clients people already use and the apps they have connected, including personal tokens.
- Move everyone to one address with per-person sign-in, and retire shared tokens.
- Write roles before access. Start everyone on Member and restrict destructive tools at the role level.
- Add the reviewer as an Auditor. The seat is free and read-only.
- Send the ten questions to each vendor and attach the written answers to the review.
- Pilot with one team for two weeks, then sample the audit log against the roles you wrote.
On cost, Elaichi's Gold plan is $15 per user per month at the USD list price. Auditor, Guest and Billing Admin seats are free.
When is an MCP gateway the wrong control for the risk?
When nobody has connected an AI client to a system of record yet. Assistant use that is only reading, copying and pasting is a content problem. DLP is the right instrument for it, and a gateway adds an address that answers nothing you were asked.
One team using one app may not need a second vendor either. Many apps now ship their own MCP server that runs under the app's own permission model. That holds until a second app or client arrives, and the question becomes one set of rules and one trail across them.
The case for waiting on a gateway lists the signals that say you have waited long enough. When they appear, the connector catalog runs to 500+, and the rest of the governance writing covers the rules underneath.
