Is Composio secure enough for enterprise use?
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. Is Composio secure enough for enterprise use is two questions wearing one coat. One is about controls, and Composio's own pages answer most of it. The other is about architecture, and no vendor page answers that for you.
Composio's enterprise page describes permissions "set administratively, per user and per role, down to the individual action". It says every tool call is logged with the user, team, tool, action and outcome, denied calls included. It lists SSO over SAML and OIDC, and self-hosting at the Enterprise tier (composio.dev/enterprise, checked September 2026). SSO means sign-in through your identity provider rather than a second password. MCP is MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps, and an endpoint is the one address a client connects to.
That is a real control list. What follows is the set of mechanics underneath such a list, and what each one looks like from the client, using Elaichi as the worked example.
What does a SOC 2 report actually tell you?
A SOC 2 Type II report tells you an auditor tested a described set of controls over a stated period. It does not tell 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. Ask Composio for its current report through its own trust center 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 a small set of meta-tools. OAuth links are approved in the browser (docs.composio.dev, checked September 2026). OAuth is delegated sign-in: the app receives a scoped token instead of a password.
Elaichi authors, maintains and serves its connectors from its own infrastructure, 450+ of them. Companies do not run MCP servers to use it, and Elaichi does not wrap a registry of servers other people run. In a review that collapses one question into one answer: who ships the code that dials Salesforce, and how does a change to it reach us.
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 Elaichi, connector credentials are not in Elaichi. A separate credential service holds per-account secrets, AES-256-GCM at rest, and owns refresh. 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 endpoint-shaped is unrepresentable. It is gated on connector management rather than connection management, so everyone who can delete a connection does not quietly gain the power to repoint the org's OAuth app. Customer-managed keys are available as per-org envelope encryption with a key in AWS KMS. Composio's pricing page lists customer-managed keys at the Enterprise tier (composio.dev/pricing, checked September 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. Claude, ChatGPT and Cursor each get pointed at that one address through their own admin console.
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 says each team gets its own MCP endpoint, SSO authenticated (composio.dev/mcp-gateway, checked September 2026). The question to put to any per-team address model is operational rather than moral. At forty teams, how many addresses does IT publish, 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 September 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 about 38 action strings grouped into personas, with exactly one role per member, enforced by a unique index. Sharing is one primitive: 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. No org-level permission silently widens that listing, owners and admins included. Restrictions decide which connectors and which individual tools a target may reach.
Restrictions target a role or a user. There is no organization target, because the org default is the absence of any rule, which means allow-all. Precedence is fixed: A rule on a user replaces the role rules for that user rather than adding to them. A user rule replaces role rules rather than layering on them. Within the winning layer, blocks always beat allows. An allow rule naming nothing therefore denies everything, which is the strictest rule you can express and a real trap in a first rollout.
One mechanic is worth quoting into a review. A block matches the tool's advertised name or its pinned operation; an allow matches the pinned 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 at four points against the same resolver, browse, connect, advertise and execute, plus a final check on the fully substituted outbound URL. The tool:execute permission gates the whole endpoint ahead of every scope, so without it tools/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. Grant revocation, member removal and suspension are effective on the next call. The revocation flag is re-read on every single call, and revocation happens in the same transaction as the membership change.
What does the model actually see?
Less than the full catalog, by default. Past a threshold of 30 tools the connected tools collapse behind two meta-tools, search_tools and execute_tool. The threshold counts control-plane operations and connected tools together, and the control plane alone is dozens of operations, so one connected app is normally enough to trip it. Tools withheld by a restriction are excluded from the count, because they were handed to nobody. 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. Frozen keys are stripped from the advertised schema, so the model never sees them, and frozen values are merged over caller arguments at execution, so passing the key cannot un-freeze it. How the search side ranks what is left, and why it refuses to answer 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. A single query answers what happened instead of correlating two systems by eye. Here actor_kind is a recorded field rather than an inference, and its values include ai_assistant. Whether an AI took the action is written at the point of action, not guessed later from a user agent.
There is one entry per tool-call attempt, succeeded or failed, and both name the account actually 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. Argument names and counts are logged; argument values never are.
Two structural details matter to a reviewer. Each organization gets its own log tenant, enforced in the type system, because a dropped filter leaks while a wrong tenant 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 record 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 forwarded to whatever destination you configure, so a remote error body reaching one would be third-party payload leaving through the log pipe. Forwarding to Datadog is implemented; Splunk HEC and Microsoft Sentinel are accepted but not yet delivering. A free read-only Auditor seat means a compliance reviewer costs no license.
What happens when somebody leaves?
Removal runs a preflight. Personal connections referenced by a toolbox entry must be resolved first, transferred to the org, a team or another member, or deleted, or the removal is refused. Unreferenced personal connections are cleaned up. A private connection is not transferable at all, because a credential only its owner could use does not become someone else's when that owner leaves. 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, every live grant is revoked in the same transaction as the membership change, so access ends on the next call. The case for people who were never employees is covered in what to do about contractor access today.
What does Elaichi not claim?
Three things, stated plainly, because a review will find them anyway. The prompt-injection write gate in the agent window does not apply to POST /mcp and cannot, since an MCP server never sees a user prompt. What does hold on the endpoint is role checks per operation, the forbidden classification that no OAuth scope can reach, output redaction, scope limits and full audit logging.
The eu and us regions are hard residency, a jurisdiction pinned for compute and storage. The apac region is a placement hint (best-effort). Only eu and us are hard-residency. Organization deletion tears down the workspace but has no path to purge the organization's log tenant, and the product returns that residue by name rather than claiming 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 September 2026). Its docs describe an SDK with per-user sessions and managed auth. 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, or start from the team use cases if the rollout is one department at a time. Gold is $15 per user per month 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. See pricing for the detail.
