Composio Incident Shows AI Connectors Are Token Vaults

Composio's May 2026 security bulletin says unauthorized access to internal systems led to compromised connected-account credentials, dominated by 5,001 GitHub connections and a smaller set of Gmail, Slack, Jira, Notion, HubSpot, Linear, Google Calendar, and other connectors. The company also said an auxiliary cache service likely accessible during the breach window held 5,241 API keys, and it deleted API keys created before 11:00 PM PST on May 22 as a precaution.

The incident is important beyond one vendor because AI connector platforms concentrate delegated access. A coding agent, sales assistant, support bot, or security workflow does not only call a model. It may hold OAuth refresh tokens, GitHub permissions, email access, calendar access, cloud API keys, and customer-provided credentials. Once that hub is touched, response depends on provider-side revocation, customer-side rotation, app audit logs, and whether the platform can prove tokens were killed rather than merely deleted from its own database.

Composio published its incident bulletin on May 21, 2026 and continued updating it through at least May 27. The company says it identified unauthorized access to certain internal systems, engaged external incident response experts, and continued investigating scope. It also says the attacker initially gained a foothold in an internal agentic tool used to monitor infrastructure and connector failures, then abused remediation systems and tool definitions until arbitrary code execution was possible inside the tool-execution sandbox.

The affected connector table is the core security fact for customers. Composio listed about 0.3% of active connections as leaked, with GitHub by far the largest category at 5,001 connections. The table also includes small numbers of Gmail, Strava, Jira, HubSpot, Linear, Notion, Slack, Google Calendar, and many mostly internal test connections. The company says it revoked every affected connection it could and contacted affected users.

The API-key side is less clean. Composio says an auxiliary cache service likely had 5,241 API keys during the breach window. It did not say every key was proven stolen. It did say those keys had a higher potential for compromise, deleted API keys created before a stated cutoff, and told customers to rotate keys and recreate them where needed.

A connector platform is attractive because it turns many app-specific authorization flows into one developer experience. That same abstraction can hide the security cost. A single hub may store access for GitHub repositories, issue trackers, mailboxes, calendars, chat workspaces, customer support systems, cloud deployment tools, analytics platforms, document stores, and internal automation.

The risk is not simply that a third party can read a token. It is what each token can do. A GitHub token may read private repositories, open pull requests, change workflow files, create issues, or access package metadata depending on scope. A Gmail token may expose messages or allow account actions. A Slack token may read or post workspace content. API keys may not have the same standardized revocation behavior as OAuth tokens, and some are long-lived by default.

This is why incident response has to be downstream. If a connector token was exposed, the owning organization should review what the token could reach at the provider, whether the provider confirms revocation, what actions were taken during the exposure window, and whether any secondary secrets were reachable through the connected account.

Composio's own FAQ makes an important distinction: deleting an integration does not necessarily mean the provider-side token is invalidated. That is a common connector-platform trap. A vendor can remove a local record from its database while the upstream provider still considers the OAuth grant, refresh token, or API key valid until expiration or explicit revocation.

Composio now points customers to a connected-account revoke endpoint that attempts upstream provider revocation. The docs describe it as best-effort and note that providers or toolkits may return errors when revocation is unsupported or impossible. That phrasing is not a weakness in documentation. It is the real world of fragmented provider APIs, custom auth schemes, long-lived keys, and administrative grants.

Customers should build their own revocation ledger. For each connected app, record whether Composio revoked it, whether the upstream provider shows the OAuth app as removed, whether the user or admin rotated API keys, and whether logs show suspicious activity between the exposure window and revocation. Without that ledger, teams can end up assuming a local platform action killed a credential that remains live elsewhere.

GitHub dominated Composio's affected connector counts, so engineering teams should treat repository and workflow review as a priority even if they do not see obvious code changes. The right first step is to review authorized OAuth apps and personal access tokens for affected users, then revoke grants that are no longer needed. GitHub's account settings expose authorized OAuth apps, and token expiration or revocation can remove access when a token is no longer trusted.

The second step is repository telemetry. Review pushes, pull requests, branch protection changes, deploy key changes, GitHub Actions workflow edits, environment secret changes, package publishing, OAuth app authorizations, and unusual repository reads during the incident window Composio gave customers. Pay special attention to repositories connected to release automation or production deployments.

The third step is scope reduction. Connector tokens used by AI tools should not have broad write access by default. For many use cases, read-only repository metadata, issue access, or narrowly scoped pull request permissions are enough. High-risk operations such as changing workflows, reading secrets, publishing packages, or administering repositories should require separate approval paths and short-lived credentials.

Composio also published a notice about the threat vector it found internally. The company said the attacker compromised Gmail OAuth tokens for certain employees and used that to abuse magic-link sign-ins for auxiliary systems from staging. It recommended that security and forensics teams verify whether similar abuse occurred during the breach window and consider disabling magic-link sign-ins for auxiliary systems.

That detail matters because it connects consumer-friendly login UX with enterprise incident response. Magic links are convenient, but they can turn mailbox or OAuth-token compromise into application access if the application treats email possession as enough. When the mailbox is connected to an agent or connector ecosystem, the path from token theft to internal tool access can become shorter than teams expect.

For high-trust internal systems, magic links should not be the only control. Require phishing-resistant MFA where possible, bind admin access to managed devices or network context, monitor OAuth grants to employee mailboxes, and keep staging or auxiliary tools out of privileged production paths. Convenience features need different rules when the system can repair connectors, access credentials, or change automation.

The useful market lesson is not that teams should avoid every connector platform. Modern AI and automation workflows need delegated access to be useful. The lesson is that connector platforms now sit close to identity, secrets management, and incident response. Procurement and security reviews should treat them accordingly.

Ask whether tokens are encrypted with customer-specific keys, whether customers can bring or control key material, whether tokens are readable after creation, whether access tokens are redacted from APIs, whether refresh tokens are minimized, whether app scopes can be narrowed per workflow, whether IP allowlisting is supported, and whether every supported connector has a documented revoke path. The absence of a revoke path should be treated as residual risk, not a footnote.

Also ask for incident mechanics. A credible platform should know how to enumerate affected connected accounts quickly, revoke what it can upstream, tell customers what it cannot revoke, publish indicators of compromise, preserve logs, separate internal test accounts from customer accounts, and communicate which provider-side actions remain the customer's responsibility.

Composio says its investigation is ongoing and that it is not characterizing specific content exposure at this time. That leaves important unknowns for customers: whether individual repositories, messages, calendars, cloud resources, or downstream systems were read or changed; whether any provider-side logs are complete enough to prove non-use; and whether leaked credentials were copied before revocation.

The right posture is measured caution. Treat confirmed and potentially exposed tokens as dead, rotate API keys at the provider where Composio cannot revoke them, review logs around the stated May 21 window, and ask end users to remove stale connected apps. The bigger architectural lesson should survive this specific incident: an AI connector that can act across many services is a token vault, and token vaults need hard security boundaries before the next incident.