Is Composio secure enough for enterprise use?
Composio's own pages answer most of the controls half of that question. They describe permissions per user and per role, down to the individual action, and logging of every tool call, denied ones included. They also list SSO over SAML and OIDC, and self-hosting at the Enterprise tier (composio.dev/enterprise, checked October 2026). The other half is architecture: who authors the connectors, where credentials sit, how many addresses your AI clients point at, and what the audit record ties an action to. No vendor page settles that half for you, and it is where a security review should spend its time.
The question usually arrives as a questionnaire. An engineer has already built something on Composio, and security has to sign it off before an agent touches production data.
SSO means sign-in through your identity provider rather than a second password. MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps (MCP specification), and an endpoint is the one address a client connects to. The rest of this post walks the mechanics underneath a control list, using Elaichi as the worked example.
What does a SOC 2 report actually tell you?
That an auditor examined the vendor's own description of its system and the controls in it. AICPA's guide frames a SOC 2 engagement as an examination of a service organization's description of its system and its controls relevant to security, availability, processing integrity, confidentiality or privacy (AICPA SOC 2 guide). A Type II report adds testing over a stated period. Neither tells you the scope covered the product you are about to buy.
Read four things: the period end date, the exceptions, the systems named in scope, and the carve-outs for subservice organizations, meaning the cloud and logging vendors underneath.
A certification belongs to the vendor that holds it. Composio's MCP Gateway page states SOC 2 Type II and ISO 27001 certification (composio.dev/mcp-gateway, checked October 2026). That is Composio's claim to substantiate, so ask for the current report and read it under NDA. Do not take a certification claim from a blog post, including this one. Elaichi's own certification status is published on its Trust Center, linked from the security page, and that page is the authority rather than this paragraph.
What a report cannot settle is whether the shape of the system matches your org chart. Five mechanics decide that: who authors the connectors, where credentials live, how many addresses your clients point at, what the audit record ties an action to, and what happens when a person leaves.
Who authors the connectors you are trusting?
This is the first mechanic, and it moves the others. Composio Connect is an MCP server at connect.composio.dev/mcp that gives an agent access to 1000+ apps through 7 meta-tools (Composio Connect docs, checked October 2026). The first time an agent needs an app, Composio generates an OAuth link to approve in the browser. OAuth is delegated sign-in: the app receives a scoped token instead of a password.
Elaichi serves 600+ connectors and authors, maintains and runs most of them on its own infrastructure. The rest are native MCP connectors, where the app's vendor builds and runs the MCP server and Elaichi governs every call to it. Companies do not run MCP servers to use either kind. In a review, that turns one question into one answer: who ships the code that dials Salesforce, and how a change to it reaches you.
Custom connectors are authored from JSON config and can be forked from a public connector. Pulling upstream changes goes through a review surface that separates new tools, safe updates, config diffs, conflicts and upstream removals. Conflicts and destructive removals stay unchecked by default. The permission to create a connector is flagged high trust, because a custom connector can be pointed at any destination.
Where do credentials live, and how are they encrypted?
In a separate credential service, not in Elaichi itself. That service holds per-account secrets, AES-256-GCM at rest, and owns refresh. Connections created since 2026-10-05 have their credentials placed in the organization's region, by best-effort placement for APAC. Older connections stay where they were until reconnected, which copies them into the region. A failed refresh marks the connection needs_reauth rather than failing quietly at 3am.
Two details security teams tend to probe. A connect URL is not a credential: it is a one-time session carrying no token, which is why it is safe to return over MCP. Read-back of an account's configuration returns public values plus secret_paths, the list of dot-paths that were encrypted, carrying none of their values. Editing one is refused, and the refusal text is identical whichever side produced it, so a caller cannot work out which side said no.
An organization can supply its own OAuth app per connector. The accepted body is client_id, client_secret and scopes, so anything shaped like an endpoint cannot be expressed. It is gated on connector management rather than connection management, so the right to delete a connection never quietly includes repointing the org's OAuth app. In Elaichi, customer-managed keys in AWS KMS come with the Black plan, which is launching soon. Composio's pricing page lists customer-managed keys at the Enterprise tier (composio.dev/pricing, checked October 2026); for key rotation detail, put the question to Composio in writing.
How many addresses do your clients point at?
One, in the Elaichi model. Every connected account is served through a single organization-wide endpoint, POST /mcp: standard MCP over Streamable HTTP, JSON-RPC 2.0, stateless, behind OAuth. There are no per-toolbox URLs and no embedded tokens.
An admin adds that address once wherever the client allows it, and each member then connects and signs in with their own grant. On Claude Team and Enterprise, an owner adds it under Organization settings > Connectors and members connect it themselves (Anthropic's connector guide). Cursor's admin MCP allowlist is Enterprise only and does not push a server to anyone's machine (Cursor's enterprise docs). ChatGPT's full MCP support, write actions included, is a beta on Business, Enterprise and Edu (OpenAI's help article, as of October 2026). On those plans an admin creates and publishes the app. Pro users get read and fetch only, in developer mode. The steps are in connecting Elaichi to ChatGPT.
What varies per person is the grant, meaning the authorization a member holds after signing in, not the URL they were handed. Nothing sensitive is pasted into a client config, so nothing sensitive can be forwarded to a contractor in Slack.
Composio's MCP Gateway page describes one managed MCP endpoint for all your tools and agents (composio.dev/mcp-gateway, checked October 2026). The same page says each team gets its own MCP endpoint, carrying only the tools it is permitted to use. The question to put to any per-team address model is operational rather than moral. Ask how many addresses IT publishes at forty teams, who rotates them, and what happens to a team's address when two teams merge.
How does sign-in line up with your directory?
Through the identity provider you already run, in both products. Elaichi builds SAML and OIDC SSO in house, with no third-party auth vendor, plus SCIM v2 for users and groups and group-to-role mapping. Sign-in also supports Google, GitHub and Microsoft, email codes, TOTP MFA with single-use recovery codes, and passkeys.
Onboarding has four paths: emailed single-use invite links with roles and teams pre-assigned, verified-domain auto-join with a configurable default role, SCIM provisioning, and just-in-time SSO. Domains are verified by DNS TXT record. Composio's pricing page lists SSO and SCIM at the Enterprise tier (composio.dev/pricing, checked October 2026), so directory sync is a tier question there rather than a missing one.
Which governance mechanics hold up under questioning?
Three layers, kept separate on purpose. Roles are 58 action strings grouped into personas, with exactly one role per member, enforced by a unique index. Sharing is one building block: a grant of view, use or edit on a resource to a user, a team or the whole org. A member sees only what they own or what was shared with them, and no org-level permission silently widens that listing, owners and admins included. Restrictions 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 always beat allows. First rollouts often hit one trap. Note that the allowlist stage engages on the presence of an allow rule, not its contents, so an allow rule that names nothing denies everything.
One mechanic belongs in the review file word for word. A block matches the tool's advertised name or the operation recorded when the rule was written; an allow matches that operation only. A tool name can be edited by whoever maintains the connector's documentation, so governance binds the operation and never the label. The reasoning is set out in why a block matches the name and an allow matches the operation. Enforcement runs against the same resolver 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. The tool:execute permission gates the whole endpoint ahead of every scope, so without it the tool list is empty. Guest, Auditor and Billing Admin lack it.
Freshness is the fact most reviews get wrong. A role change or a restriction change takes effect within about two minutes, through a 60-second cache plus edge propagation, on every surface. Member removal and suspension hold from the next call, because the grant is re-read on every single call. In Elaichi, removing or suspending a member revokes every live grant in the same transaction as the membership change.
What does the model actually see?
Less than the full catalog, by default. In Elaichi, connected tools are never listed one by one, however few there are. The model reaches them through two meta-tools: search_tools looks a tool up, and execute_tool calls it. A restricted tool is left out of the tool list and cannot be called. Search names it, flagged restricted, with no schema. And execute_tool is only a naming indirection: it unwraps to the same name and arguments and falls through the identical gates.
Frozen parameters narrow the surface further. A frozen key is dropped from the schema the model is offered. Its value overrides whatever the caller passes at execution, so supplying the key anyway changes nothing. How the search side ranks what is left, and why it returns nothing for a query it cannot match, is worked through in the relevance floor behind search_tools.
What does the audit trail tie an action to?
An account, an operation and an actor kind. Elaichi writes one record shape for audit events and application logs both, so a single query answers what happened instead of two systems being correlated by eye. The actor_kind field is recorded rather than inferred, and its values include ai_assistant, which marks only the Elaichi Agent. A call from Claude or ChatGPT is recorded under the person who signed in, with surface mcp and the OAuth client named.
Elaichi writes one entry for each connected-tool call that reaches execution (a call refused earlier writes none). Each entry records the account the call reached, taken from the execution rather than from the intent. Which of two Notion workspaces the agent wrote to is the first question after an unexpected change. For arguments, the record holds the one path argument that names the object, as the target id, and nothing else about the arguments.
Two structural details matter to a reviewer. Each organization's audit history is kept apart from every other organization's, enforced in the type system, because a dropped filter leaks while a wrong scope returns nothing. And two error strings exist per failed call. The one returned to the caller is derived from the third party's response body. The one in the audit trail carries an error code and text never derived from the request or the response. Audit records are org-visible, readable by the in-product assistant and can be forwarded outside Elaichi. A remote error body reaching one would be third-party payload leaving through the log pipe.
The trail inside Elaichi is on Gold. Beyond the in-app trail, export to your own Datadog comes with the Black plan, which is launching soon. Elaichi accepts Splunk HEC and Microsoft Sentinel as destinations but delivers events only to Datadog. A free read-only Auditor seat means a compliance reviewer costs no license.
What happens when somebody leaves?
Removal runs a preflight, and the person's access ends on the next call. The preflight lists every connection the departing member owns. A private connection that a shared toolbox relies on blocks the removal until an admin transfers it to one other active member, never to the admin running the removal, or deletes it. A private connection that nothing beyond the member depends on cannot be transferred and is deleted with them. A shared connection a team still depends on is deleted only if the admin explicitly asks, so the usual move is transferring it to a member who is staying, which leaves every grant on it as it was. Delegated toolbox entries surface as a non-blocking warning, and re-pinning is the fix rather than a credential decision.
Once the removal goes through, access ends in every client at once. In Elaichi, removing or suspending a member revokes every live grant in the same transaction as the membership change. The case for people who were never employees is covered in what to do about contractor access today.
What does Elaichi not claim?
Two things, stated plainly, because a review will find them anyway.
The first is a prompt-injection gate on tool calls. The prompt-injection write gate lives in the Elaichi agent window and does not apply to a raw tool call. An MCP server never sees a user prompt, so no gate of that kind can sit on the endpoint. What does hold there is role checks per operation, the forbidden classification that no OAuth scope can reach, output redaction, scope limits and an audit row for each call that reaches execution.
The second is total erasure. Deleting an organization deletes its connector credentials but leaves three stores: the audit history, analytics events, and the credential service's organization, environment and installed-connector configuration rows. Elaichi reports that residue by name. It never claims everything is gone.
Where is Composio the better fit, and where do you need neither?
Composio's homepage names end users who want an AI assistant to act in their apps, and developers building agents (composio.dev, checked October 2026). Its docs describe SDK sessions created for each of your users, tying together that user's toolkits, auth and connected accounts (Composio's sessions docs, checked October 2026). If you are shipping an agent product and each of your customers' users needs their own auth session, that is the reader those docs were written for. A control plane built around your employees is the wrong tool for that job.
There is also the case where the answer is neither. Eight people, one connected app, one AI client and a named owner do not need a governance layer yet. That case is argued in full in when a gateway is premature.
If you are running the two vendors side by side, the feature-level view sits in Elaichi vs Composio for company-wide MCP access. To check which of your systems already have a native connector, browse the connector catalog. If the rollout is one department at a time, start from the team use cases. Gold lists at $15 per user per month in USD, or $120 per user per year, with a 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. Pricing shows the local price where one applies.
