In May 2026, an attacker accessed internal Composio systems and compromised customer credentials. We disclosed the incident, contacted affected customers, and brought in IntrusionOps for independent incident response. We then changed how credentials are stored, accessed, and used during execution.
This is the standalone account of that rebuild. It brings together the remediation documented in our September 16 incident update and our credential security architecture. The independent review results below reflect our August 2026 security whitepaper, as reported in that September update. Publishing this article does not represent a new assessment.
The six changes are envelope encryption, hashed API keys, Proxy Execute, customer-managed KMS, IP allowlisting, and AppSecure verification.
What happened, and what this article covers
The May disclosure describes an attacker moving through internal tooling and registering malicious tool definitions to escalate privileges. It also describes compromised employee Gmail OAuth tokens being used to access auxiliary systems through magic-link sign-ins. The original disclosure and timeline remain available, including the affected-connection list, indicators of compromise, and revocation guidance.
The disclosure reported leaked connections representing about 0.3% of active connections, including 5,001 GitHub connections. It separately identified 5,241 Composio API keys as potentially exposed. Those are different categories of exposure, not a single count of confirmed stolen customer credentials.
We retired and rebuilt the tool-building service with a third-party security audit. Internal hardening replaced shared static secrets with OIDC authentication, tightened infrastructure permissions, and centralized security logging and alerts. The infrastructure remediation account documents that work. The sections below explain the credential controls that followed.
Envelope encryption
We replaced single-key encryption with envelope encryption. OAuth access and refresh tokens are encrypted at rest using AES-256-GCM. A key-encryption key in AWS KMS wraps a per-organization key, and the key-encryption key rotates independently.
This separates stored credential data from the key material needed to decrypt it. It removes the previous reliance on a single encryption key. Encryption at rest still has an execution boundary. In the default Composio Cloud deployment, the execution runtime decrypts a credential for a call, attaches it to the provider request, and retains no credential afterward. The application and language model do not receive the token.
The architecture walkthrough explains storage, execution-time access, and privileged-access controls. Customer-managed keys change who controls decryption, as described below.
Hashed API keys
Composio API keys and session keys are stored only as hashes, with no recoverable copy. A key is shown once at creation. Composio cannot reconstruct it from the stored value.
These are the keys used to authenticate to Composio. They are distinct from the connected-account credentials Composio must use to authenticate requests to third-party providers. Those credentials need encryption because execution requires their plaintext value. Hashing Composio API keys removes a recoverable stored copy, but a leaked key can still authorize requests until it is revoked or its permissions prevent the action.
Use scoped project API keys rather than granting every workload full access.
Proxy Execute
Connected-account APIs no longer return access tokens, refresh tokens, or request tokens. Custom OAuth client secrets are also withheld. This removes the token-read path developers previously used to retrieve a credential and call a provider themselves.
Proxy Execute provides the alternative. Your application supplies the endpoint and request. Composio attaches the connected account's authentication server-side and returns the provider response, without returning the token. Developers can reach endpoints that do not have a predefined Composio tool without taking custody of the credential.
Proxy access needs its own permission. Use a scoped project API key with Proxy execute enabled. Session proxy calls obey toolkit allow and deny lists and reject cross-domain requests, but hint filters and per-tool rules do not apply to arbitrary HTTP endpoints. A readOnlyHint filter is not a read-only policy for proxy calls. Disable proxy execution where your application should expose only the selected predefined tools. The Proxy Execute restrictions document this boundary.
The June 4 changelog records connected-account token redaction and the initial rollout of scoped keys for Proxy Execute.
Customer-managed KMS
Teams that need to control credential decryption can deploy a stateless credential proxy in their own cloud. Credentials are encrypted under keys in the customer's KMS, and that proxy is the component that handles plaintext. Composio retains the control plane but does not hold the key material needed to decrypt those credentials.
The supported key services are AWS KMS, Google Cloud KMS, and HashiCorp Vault Transit. This is an available, optional deployment that requires setup with our team. It is not the default Composio Cloud configuration or a self-service toggle.
The customer-managed deployment description explains the architecture. Contact security@composio.dev to review the deployment and setup requirements.
IP allowlisting
IP allowlisting restricts where a Composio API key can be used. A request from outside the configured allowlist is rejected even if the key is valid. It adds a network restriction alongside key permissions, rather than relying on possession of the key alone.
Configure allowed addresses in the dashboard's IP allowlist settings. Use your application's actual outbound addresses and account for VPNs, changed egress IPs, and deployment networking. A valid key can produce a 403 when its source address is not allowed. The incident FAQ describes this operational consequence.
The June 4 changelog documents availability. Customers still need to configure restrictions for their workloads. IP allowlisting does not revoke a provider token that has already leaked outside Composio.
AppSecure verification
AppSecure Security assessed the web application, developer APIs, and both SDKs against the OWASP Top 10 for web, API, and LLM applications. All critical and high findings in that assessment were remediated and re-verified.
That is a scoped verification result. It does not mean every possible vulnerability has been eliminated, or that every finding from every assessor is closed. As reported in the September incident update, Latacora's AWS and GitHub review had independently confirmed closed findings and remaining items in progress. IntrusionOps separately supported the incident investigation, scope validation, containment, and remediation.
The dated independent-review account separates those roles and results. Request AppSecure's executive summary and the latest remediation status from security@composio.dev. Our SOC 2 Type II report is available through the Trust Center resources. SOC 2 and a penetration test answer different questions. Neither is a guarantee against another incident.
How to use this in a security comparison
A comparison should include both the May breach and the controls documented afterward. Link to this article for the rebuild, preserve the incident record for historical scope, and request current evidence before making a procurement decision.
Ask each provider the same concrete questions:
- Can an API return connected-account credentials, or must requests go through an execution service?
- Which credentials are recoverable, who controls their decryption keys, and where does plaintext exist during a call?
- Which controls are defaults, which need customer configuration, and which need a separate deployment?
- Do tool permissions also constrain raw HTTP proxy calls?
- What did the independent assessor review, when, and which findings remain open?
Credential isolation does not prevent an agent from misusing permissions it legitimately has. Restrict sessions and provider scopes to the work they need, and require approval for sensitive actions. If a credential may have leaked, deleting a Composio connection alone does not guarantee provider-side revocation. Request revocation where supported, or revoke and rotate it directly with the provider.
For a reporting update or a security review, share this page alongside the dated source documents. For evidence beyond the public record, contact security@composio.dev.
Get started
