# Is Composio secure enough for enterprise use?

> Is Composio secure enough for enterprise use is two questions: one about controls, which its own pages answer, and one about architecture, which no vendor page answers for you.

**TL;DR** Composio's own pages describe per-user and per-role permissions, per-call logging, SSO and self-hosting at the Enterprise tier, so the control list is rarely what fails a security review. What a review still has to settle is architecture: who authors the connectors, where credentials sit, how many addresses your clients point at, and what the audit record ties an action to. Elaichi answers those by authoring its own connectors and serving them through one organization-wide MCP endpoint behind OAuth, with role and user restrictions, an append-only audit trail, and hard EU or US residency.

## 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](https://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](/security/), 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](https://docs.composio.dev/docs/composio-connect), 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](https://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](https://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](https://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](/blog/block-matches-name-allow-matches-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](/blog/search-tools-ranking-floor-idf/).

## 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](/blog/shadow-ai-contractor-offboarding/).

## 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](https://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](/blog/when-you-dont-need-an-mcp-gateway/).

If you are running the two vendors side by side, the feature-level view sits in [Elaichi vs Composio for company-wide MCP access](/blog/elaichi-vs-composio/). To check which of your systems already have a native connector, browse the [connector catalog](/connectors/), or start from the [team use cases](/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](/pricing/) for the detail.

## FAQ

### Does Composio support SSO, role-based permissions and audit logging?

Yes. Composio's enterprise page describes permissions set administratively per user and per role down to the individual action, every tool call logged with the user, team, tool, action and outcome including denied calls, SSO over SAML and OIDC, and self-hosting at the Enterprise tier (composio.dev/enterprise, checked September 2026). Certification reports such as SOC 2 should be requested from Composio directly, because a certification claim belongs to the vendor that holds it and needs its scope and period read.

### What should a security review read in a SOC 2 Type II report?

Read the period end date, the exceptions the auditor noted, the systems named in scope, and the carve-outs for subservice organizations such as cloud and logging vendors. A SOC 2 Type II report says an auditor tested described controls over a stated period. It does not confirm that the product you are buying was inside that scope, so scope and exceptions matter more than the badge.

### Where does Elaichi store connector credentials?

Not in Elaichi. A separate credential service holds per-account secrets encrypted with AES-256-GCM at rest and owns token refresh, and a failed refresh marks the connection needs_reauth rather than failing silently. An organization can add per-org envelope encryption with a customer-managed key in AWS KMS, and can supply its own OAuth app per connector using only a client ID, client secret and scopes.

### How quickly does a permission change take effect in Elaichi?

A role change or a restriction change takes effect within about two minutes, because both resolve through a 60 second cache plus edge propagation on every surface. Grant revocation, member removal and suspension are effective on the next call, since the revocation flag is re-read from the org store on every call and revocation happens in the same transaction as the membership change.

### What is the smallest scope an Elaichi restriction can target?

No. Restrictions target a role or an individual user only. The organization default is the absence of any rule, which means allow-all, so an org-wide clamp is expressed as a rule on every role. Within the winning layer blocks always beat allows, and an allow rule that names nothing denies everything, which is the strictest rule the system can express.

## Read next

- [How to narrow to least privilege MCP tool calls](/blog/least-privilege-tool-calls-without-breaking-automation/) — Narrow to least privilege MCP tool calls using the audit rows your pilot already produced, then plan the two-minute wait and the verification call that proves the rule landed.
- [SOC 2 evidence for AI agents: CC6 and CC7](/blog/soc2-evidence-ai-agents-cc-controls/) — SOC 2 evidence for AI agents maps onto CC6.1, CC6.2, CC6.3 and CC7.2. Here is the artifact for each, plus the criteria a governed MCP endpoint does not touch.
- [MCP tool name vs pinned operation restriction](/blog/block-matches-name-allow-matches-operation/) — MCP tool name vs pinned operation restriction: a block rule matches a tool's label or its operation, and an allow rule matches only the operation. Here is why.