When you don't need an MCP gateway yet
Per-user AI client connectors plus an SSO policy are enough for three kinds of company. Here is when you don't need an MCP gateway, and the two signals that end it.
Roopendra Talekar
10 min read
When you don't need an MCP gateway: three company shapes
Most writing in this category exists to sell a control plane, so start from the other end. The question of when you don't need an MCP gateway is worth asking first, and the answer doesn't depend on company size. It depends on whether you can currently answer three questions: who is connected, what can they reach, and can you revoke it in one action. Call this the enumeration test. There are companies where per-user connectors in Claude, ChatGPT or Cursor, plus an SSO policy on the SaaS underneath, pass that test today. Adding a governed MCP endpoint to one of them buys a migration, a bill and a second place to look, in exchange for controls that nothing in the business is currently asking for. The three shapes below are the honest cases for waiting, and each one maps to a specific way the enumeration test currently holds.
One AI client and a roster you can recite
If you can name, from memory, every person who has connected an AI assistant to a company system, you have an inventory. It is in your head, and it is accurate, and it costs nothing to query. The whole value of a control plane at the small end is that it turns an unanswerable enumeration problem into a list. When the list is six people and one client, buying the list is buying something you already have.
The thing to watch is not headcount. It is whether the roster survives a week where you are not paying attention. Roster knowledge decays the moment someone can connect an account without telling you, which is usually the moment a second AI client shows up, because a mental roster is per-person, not per-system, and a second client doubles the number of places a connection can happen without you noticing.
Read-only work against a single system of record
A sales team running research questions over one CRM, with no write path, is a narrow blast radius. The assistant acts as the person, so the person's existing CRM permissions bound it. If a rep cannot see enterprise pipeline in the CRM, the assistant cannot either. You did the access design once, in the CRM, and the AI inherits it. No separate policy layer is needed, because there's nothing for a separate layer to add.
This stops being true the moment writes are in scope, because a write is where the difference between what a person would do and what a model will do starts to matter, and because the question after an unexpected change is which account made it. Read-only against one system has no such question. Two systems and a write path do. The second system is where "the CRM already bounds this" stops being sufficient, because the CRM's permission model has no opinion about what the other system allows.
Every reachable account owned by your identity provider
If every SaaS account an assistant can touch is federated, provisioned through SCIM and deprovisioned by the same action that closes the laptop, your IdP is already the control plane for the parts that matter. Central sign-in, MFA, session revocation and group membership are real controls, and they are controls you are already paying for.
The qualifier is the word every. The shared vendor portal with its own login, the personal Notion workspace someone uses for meeting notes, the API key pasted into a script: none of those are owned by the IdP, and each one is a grant that outlives the account closure. In practice, "every" is the condition that breaks first. Most companies discover the exception during an offboarding, not during an audit.
What per-user connectors and an SSO policy genuinely cover
Be precise about what the cheap setup does well, because vendors in this category tend to be vague about it. The honest split is: authentication yes, authorization partially, inventory no.
Authentication is covered. Sign-in goes through one identity, with MFA enforced centrally and sessions revocable centrally.
Scope is partly covered. An OAuth consent binds a connector to what it asked for, and a connector that only requested read cannot write. This is real, but it's a per-connection scope, not a policy you set once and apply to a team.
Blast radius is covered by inheritance. An assistant acting as a person is bounded by that person's permissions in the target system. This is why the read-only, single-system case above works without extra tooling.
What none of it covers is the register, a distinct thing from both the roster (who's connected, held in someone's memory) and the permission (what one person can do in one system). The register is the missing artifact: a single place listing which grants exist, who made them, and which account each one reached. Each seat holds a fragment of that answer and no seat holds the whole. That is not a flaw in SSO. SSO was never built to be the inventory. It's the reason both forcing-function signals below are, at bottom, enumeration problems rather than authentication or permission problems.
| Question you will be asked | Per-user connectors plus SSO | Governed MCP control plane |
|---|---|---|
| Who signed in, and with what factor | Covered by the IdP | Covered, plus SSO, SCIM and group-to-role mapping in Elaichi itself |
| What can this person reach in the target system | Inherited from that system's own permissions | Inherited, plus restrictions per role or user at every resolver point (see body) |
| Which grants exist across the company | Not answerable without polling each seat | Listed centrally |
| Which account did the agent actually write to | Not recorded in one place | one entry per tool-call attempt, succeeded or failed |
| Does removing a person kill the AI's access | Only for accounts the IdP federates | removing or suspending a member revokes every live grant in the same transaction as the membership change |
A per-user MCP URL, where the credential is the address rather than a sign-in, is a separate shape with its own failure mode (a leaked URL is a leaked credential with no rotation path short of reissuing it), and it is covered in the piece on moving off per-user endpoints.
Signal one: a person leaves and their AI still holds access
Someone connected a shared billing portal and a personal project workspace to their assistant in March. In October they resign. You disable the IdP account within the hour and the SSO logins die with it.
Now answer two questions. Which grants did that person hold, and which of them were bound to an account your IdP never federated? If the answer to the first is an email to their manager, and the answer to the second is a shrug, the cheap setup has run out. The grant you cannot enumerate is the grant you cannot revoke, and the token refresh keeps working on its own schedule regardless of what your directory thinks. An OAuth refresh token doesn't check with your IdP before renewing itself.
This is what a control plane is actually for. In Elaichi, removing or suspending a member revokes every live grant in the same transaction as the membership change That describes what happens on removal and suspension as implemented, not as a stated intention. It is worth verifying against the current security page rather than taking on faith, since this is exactly the kind of claim that should change with the product and not silently drift out of date.
Offboarding also has a preflight, not just a single action. A personal connection referenced by a toolbox entry must be resolved before removal is allowed: transferred to the org, to a team, or to another member, or deleted outright. Unreferenced personal connections are cleaned up automatically. A private connection is not transferable at all. The reasoning is that a credential only its owner could ever use does not become somebody else's because the owner left. Delegated toolbox entries surface as a non-blocking warning instead of a hard stop, because re-pinning a reference is a configuration fix, not a credential decision, and shouldn't block the rest of an offboarding.
Signal two: answering what Sales can reach without polling each seat
The second forcing function is a question from outside IT. Compliance, a customer security review, or your own auditor asks what the sales team's assistants can reach. With per-seat configuration, the answer is a survey: you ask fourteen people, you get eleven replies, and three of them are wrong because nobody remembers what they authorized in March. A control that cannot be read on demand is not a control you can defend in a review.
How this resolves in a rule-based system (using Elaichi's model as a concrete example, not a universal spec): restrictions are written against a target, and restriction targets are role or user only; the organization default is the absence of a rule, which means allow everything. Precedence runs user override, then role rule, then that default, and a user-targeted rule replaces the role rules entirely rather than layering on top of them. Within whichever layer wins, allows union together, blocks union together, and blocks always beat allows.
Two details are worth knowing before writing a first rule, because both are easy to get backwards:
- An allow rule engages the allowlist stage by its presence, not its contents, so an allow rule naming nothing denies everything. That is the strictest rule the system can express, and people write it by accident when they mean to write a narrow allow.
- A block matches on the tool name or the pinned operation, while an allow matches on the pinned operation only. This asymmetry exists because a tool's advertised name is a label that whoever edits the connector's documentation controls, and governance should bind to the operation, not to a mutable label.
The resolver runs on every request, at every stage: browse, connect, advertise and execute, plus a final check on the fully substituted outbound URL. That final check catches cases where the operation looked fine at the earlier stages but resolves to a disallowed target once parameters are filled in.
Changes here are not instant. A role or restriction change resolves through about two minutes, and that lag applies across the MCP endpoint, the console and the REST surface alike, so a permission change made in a hurry (e.g., during an incident) should be verified rather than assumed to be live at once.
The read side answers the auditor's second question directly. one entry per tool-call attempt, succeeded or failed actor_kind is a recorded field rather than an inference, and ai_assistant is one of its possible values, so whether an AI took the action is written at the point of action instead of guessed later from a user agent string, a meaningfully different (and more defensible) design than reconstructing actor identity from request metadata after the fact. Argument names and counts are logged; argument values are not, which is a deliberate tradeoff between audit usefulness and data exposure, not an oversight. The reviewer who reads all this sits on a free Auditor seat, so the compliance function does not require an additional license per reviewer. More of this category of writeup lives under governance writeups.
Where this fits in the broader MCP tooling landscape
This isn't the only kind of approach to the problem. At least three distinct shapes exist in the market, and they aren't interchangeable:
- Per-user connectors + SSO: what this piece has been describing as the baseline; no separate infrastructure, inherits target-system permissions, no central register.
- Self-hosted MCP proxies: you run your own gateway process (open-source options exist for basic request routing and logging) and own the operational burden of uptime, patching and audit-log storage in exchange for not depending on a vendor.
- Commercial MCP gateways and AI-tool control planes (Elaichi is one; others in this general space include AI gateway products like Portkey and agent-tooling platforms like Composio): hosted, governed, with a central register, at the cost of a subscription and a new dependency.
None of these is universally correct. The three-shape test above is meant to tell you which column you're currently in, independent of which vendor (or no vendor) you end up choosing.
What the control plane costs you
A fair comparison names the bill and the friction, not just the capability.
It is a paid product. Gold is $15 per user per month or $120 per user per year, and there is no unpaid tier. 14-day trial, no credit card to start. Checkout does collect a card, and it sets the paid trial to the remaining days rather than granting a fresh 14, so it is one continuous trial rather than two If a trial ends without checkout, the workspace pauses rather than deleting anything, and plan-gated routes return a structured error until you subscribe. The pricing page has the current numbers. Check it rather than treating the figures above as fixed, since pricing is one of the fastest-moving facts on any vendor's site.
It changes how tools reach the model. Past a threshold of 30 tools, connected tools collapse behind search_tools and execute_tool instead of being listed individually. The threshold counts catalog operations and connected tools together, and the control-plane catalog alone is dozens of operations, so connecting even one app is normally enough to trip it. Collapse is the normal case here, not an edge case, and it is a materially different interaction model from a short, hand-picked list of native connectors. Worth knowing before you assume the model will see a flat tool list.
It does not solve prompt injection at the endpoint. The write-confirmation gate that exists in the interactive agent window does not apply to POST /mcp, and structurally cannot, because an MCP server never sees the user's original prompt. It sees only the tool call the client's model decided to make. What does hold at that layer instead: RBAC per operation, a forbidden-operation classification, output redaction, OAuth scope limits, and full audit logging. That's a different, narrower kind of protection than prompt-injection defense, and conflating the two is the most common mistake in evaluating this category.
Residency has real limits. eu and us are Cloudflare Durable Object jurisdictions covering compute and storage, and those are hard guarantees. apac is a placement hint. Best effort only; it is not a residency guarantee, and that distinction matters for anyone with an actual regulatory requirement rather than a preference. Organization deletion tears down the workspace but has no path to purge the organization's log tenant; the deletion response returns the tenant identifier by name rather than hiding it, which is at least honest about the gap. The security page is the place to check all of this against your own requirements, and it's worth re-checking periodically rather than once, since these are the kinds of details vendors update without much fanfare.
A rough rule for deciding
Stay with per-user connectors and SSO while three things are true: you can name everyone who has connected an assistant, every account they reached is federated, and nobody outside IT has asked what a team can reach. Move when either signal fires. A departure leaves a grant you cannot enumerate, or somebody needs a per-team answer and polling seats is the only way to get one. Both signals are really the same failure: an enumeration question with no register to query.
If you are past that line, the shape worth comparing against is one organization-wide endpoint that Claude, ChatGPT, Cursor, any MCP client, or the Elaichi Agent points at, with 450+ connectors served natively rather than proxied from servers you run. Start with the connector catalog to check your systems are covered, and the team pages for the order in which a single team is usually set up.
