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. The same ten questions are the CISO's approval checklist for an MCP server or control plane, and the evidence table below turns them into go or no-go items.
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, 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 contents 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 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 aimed at a member can only narrow what their role allows, and never replaces or loosens a role rule. Within each 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 every place a member can reach a connector or tool, including listing, connecting, advertising, executing, the final outbound-request check and opening a stored tool file. A restricted tool is withheld from the tool list and cannot be called. Search names it, flagged restricted, with no schema. 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 for each connected-tool call that reaches execution (a call refused earlier writes none). 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 the one path argument that names the object, as the target id, and nothing else about the arguments. 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 apart for each 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. For an EU or US organization, the data store is pinned to that jurisdiction, and so is the execution of its org-scoped requests and tool calls. That store holds members, roles, connections, restrictions and OAuth grants. APAC uses best-effort placement and is not a residency guarantee.
Connector credentials are encrypted with AES-256-GCM. Connections created since 2026-10-05 have their credentials placed in the organization's region: inside the EU or US jurisdiction for those regions, and by best-effort placement for APAC. Older connections stay where they were until reconnected, which copies them into the region.
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. Requests that do not act inside an organization, such as sign-in and sign-up, run at the edge wherever the request lands. Tool-result files go to one private EU bucket for every organization, whatever its region. Every organization's audit trail is stored in one log instance in the EU, as the privacy policy states. 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 history, analytics events, and the credential service's connector configuration rows. Elaichi returns that residue by name rather than hiding it. Deletion does not purge the audit history. Each record ages out under the log server's 90-day retention, counted from when it was written. 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 an audit row for each call that reaches execution. 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.
What evidence does a CISO need before approving an MCP server?
Screenshots and log rows from a trial organization, not vendor assurances. These areas cover the decision, and each one has a pass condition a reviewer can mark go or no-go.
| Check | Evidence to collect | Pass condition |
|---|---|---|
| Sign-in | The client's configuration file and a recording of the sign-in | No token is pasted into a config file, and each person holds their own grant |
| Consent | A screenshot of the consent screen with every box visible | Delete is not pre-ticked |
| Narrowing | A rule that reaches one tool for one role, written against the role, plus the tool list from a test account | The restricted tool appears in search_tools results only by name, flagged restricted and with no schema, while the role's other tools are found normally |
| Revocation timing | A timed member removal and a timed rule edit | The removed member's next call fails. A role or restriction change applies within about two minutes. |
| Audit | One entry per tool call that reaches execution, run or failed | The entry names the account reached, and carries no argument value except the target id |
| Data location | The organization's region setting | The region is named, and the vendor states what runs and is stored there |
| Deletion | The response to an organization deletion | The residue is named: the audit history, analytics events, and the credential service's connector configuration rows |
| Connector authorship | A written statement of who writes and maintains each connector | A named maintainer, and a stated route for an app that is missing |
| Stated limit | The vendor's written list of what the product does not cover | Prompt injection is on the list, because the endpoint never sees the prompt |
How do you test it in an afternoon?
Create two test members in a trial organization and run five tests. Each one checks a claim from the evidence table rather than a feature description.
- Sign in from one MCP client with the first test member, and confirm the consent screen names the client and leaves delete unticked.
- Call a tool the role should reach, then open the audit entry and check it names the account the call reached.
- Restrict one tool for that role, then confirm a
search_toolsquery returns it only by name, flagged restricted and with no schema, while the same query still finds the tools the role keeps. - Remove or suspend the second test member, then confirm their next call fails.
- Change the first member's role, then confirm the new rule applies within about two minutes.
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 600+, and the rest of the governance writing covers the rules underneath.
