On August 13, Cyera Research published an examination of the AI integration layer across hundreds of customer organizations. The researchers found thousands of exposed credentials across that layer, and reported hundreds of publicly accessible files holding dozens of API keys for Composio, Arcade, Nango, Tavily, Exa, LlamaIndex, Firecrawl and other platforms that connect AI models to enterprise systems. The owners Cyera lists include startup founders, CTOs, AI company executives and enterprise software vendors across North America, Europe, Africa and APAC — in one case, a VP of Engineering at a North American technology company who had committed a Composio API key to a public repository.

The AI integration layer is the set of platforms — integration brokers, unified API layers, MCP servers, retrieval services — that hold credentials and execute actions on behalf of AI agents. It is where an organization's agent credentials actually live, and Cyera's finding is that most security teams have not mapped it.

The scale numbers are specific. MCP servers were the largest category Cyera observed: hundreds of tenants and thousands of deployments, including Microsoft 365, Atlassian and Notion integrations. More than 10% of the applications observed were both unsanctioned and externally facing. Cyera found dozens of organizations running authentication brokers like Arcade and Composio, including 17 unsanctioned deployments, and counts 1,344 AI integration apps across comparable organizations.

The sharpest demonstration came from Cyera's own lab. The researchers created a Composio test key on their own tenant, deliberately granted it full access — the platform's default for a new key is "No access" — and connected Gmail, GitHub and CircleCI to a test account. Then they simulated an attacker who had found the key. A single read-only GET request returned the Gmail access_token and refresh_token, the GitHub bearer token, and the CircleCI API key. The scopes were wide: full mailbox on Gmail, repo plus workflow on GitHub, and pipeline environment variables on CircleCI. This was a controlled demonstration of what a leaked key *could* unlock, not evidence that any real organization's key was exploited — the research names no victim, no CVE and no confirmed compromise. Cyera also sells AI security tooling, so the framing serves its commercial interests; the lab mechanics, though, are documented step by step.

Why doesn't rotating the leaked key end the incident?

Cyera's most consequential observation is one sentence: rotating the Composio key doesn't end the incident. Once the raw downstream tokens are in an attacker's hands, they work directly against Google, GitHub and CircleCI — the broker is no longer in the loop. The refresh tokens keep working until each downstream grant is individually revoked.

This is the structural point that outlives the specific platform. An integration broker's API key and the OAuth grants it manages are two different classes of credential. The key authenticates you to the broker; the grants authenticate the broker to everything downstream. Rotating the first does nothing to the second. The incident boundary is the grant, not the key.

The platform side of the ecosystem has said the same thing in its own words. Composio's bulletin for its own, separate security incident in May 2026 — in which 5,001 GitHub OAuth connections were leaked, the bulk of the roughly 0.3% of active connections affected — told customers plainly: deleting a connection in Composio doesn't guarantee the token is dead at the provider. "Rotate, don't just delete." Composio also disclosed that some connections could not be revoked from its side at all — under 5%, including certain Google Workspace tokens that refuse programmatic revocation — and had to be unwound by end users directly with each provider. Two unrelated events, three months apart, one lesson: when a credential broker is compromised or its key leaks, cleanup is a per-provider, per-grant operation, and the platform can only do part of it for you.

Why can't an asset inventory tell you the blast radius?

The second finding is about visibility. An MCP server connected to a public knowledge base and one connected to production cloud environments appear identical in an asset inventory — one line that says "MCP server." Knowing the server exists tells you nothing about what data it can reach, what actions it can perform, or what an attacker gains by compromising it. Cyera's framing is that the blast radius of a leaked credential is the union of the scopes connected behind it, and that union is exactly what inventories don't record.

This compounds the custody problem. The platforms that concentrate the most credentials are also the ones onboarded fastest: Cyera's walkthrough shows a non-expert wiring an agent to read email and push code in minutes. Speed of integration is the product — and Cyera's point is that the organization's own inventory captures little of what each new connection makes reachable, which is how 17 authentication-broker deployments in its data end up unsanctioned. The pattern rhymes with what we found examining MCP server authentication earlier this year: the integration layer optimizes for connection, and governance is left as an exercise for the buyer.

What should security teams check now?

Start with the keys themselves. Scan your repositories — public and private — plus CI logs and container images for integration platform credentials: Composio, Arcade, Nango, Merge, Tavily, Exa, Firecrawl key formats, alongside the cloud credentials your scanners already catch. Cyera found the real-world exposures in publicly accessible files and repositories; the leak path it sketches — a key committed to a repo, then baked into a container image or printed in a CI log — is exactly the class your secret scanners exist for.

Then build the map the inventory doesn't give you. For each MCP server and integration broker, record which downstream systems it is connected to, under which accounts, with which scopes. If you cannot answer "what does this key unlock" for a credential your agents depend on, that is the gap.

Check key permissions against need. Composio's default is "No access"; a full-access key is a choice. Downgrade brokers' keys to the narrowest tier that works.

Write the revocation runbook before you need it. For every downstream provider behind a broker, know where the grant is revoked — the provider's console, not the broker's — and who owns doing it. The May incident's hardest tail was the under-5% of grants nobody could revoke centrally.

Finally, treat broker keys as tier-0 secrets: IP allowlists where the platform supports them, short rotation cycles, and never in an agent's local config file. As the AISI incident report showed for network scope, a boundary that exists only as an assumption is not a boundary.

How Waxell handles this

The findings reduce to two questions: where do your agents' downstream credentials live, and can you enumerate and unwind what a compromised identity could reach? The Waxell MCP Gateway is built around specific answers to both.

On custody: agents connect to one governed MCP endpoint per tenant, with no API key in the agent's config file — authentication happens via OAuth at first connection. For upstreams using its on-behalf-of OAuth mode, the gateway brokers the OAuth flow and stores the user's refresh token KMS-encrypted in its credential broker; the token is never returned to the agent client. A leaked laptop config exposes a URL, not a credential.

On enumeration: because upstreams are configured through the gateway, the connected set is a known list rather than an archaeology project, and every tool call the gateway brokered is logged with the resolved user identity, the decision applied and the rules that fired — durable for years, exportable to CSV, with no payload bodies stored. "Which upstreams can this identity reach, and what did it actually call" is a query, not an investigation.

On unwinding: when an employee leaves or an identity is compromised, deactivating their account revokes every per-upstream OAuth grant they held through the gateway in one transaction, and the audit log records the revocation event with the list of upstreams unwound. That is precisely the operation the Cyera and Composio write-ups show being done by hand, per provider, under incident pressure.

The honest scope note: the gateway governs calls that traverse it. A platform key held directly by an agent, or an integration wired around the gateway, is outside its custody — which is exactly why the inventory work in the previous section comes first.

FAQ

What did Cyera actually find?

Cyera Research examined the AI integration layer across hundreds of customer organizations and found thousands of exposed credentials, including hundreds of publicly accessible files that held dozens of API keys for Composio, Arcade, Nango, Tavily, Exa, LlamaIndex, Firecrawl and other AI integration platforms. It also found that MCP servers were the largest category of AI integration infrastructure, and that more than 10% of observed applications were both unsanctioned and externally facing.

Was this a breach?

No. Cyera's research documents exposed credentials and a lab demonstration on Cyera's own test tenant. There is no named victim organization, no CVE and no confirmed compromise. Composio's May 2026 security incident, cited here for its revocation guidance, was a separate, unrelated event that Composio disclosed and remediated itself.

Why is rotating a leaked integration platform key not enough?

Because the key and the downstream grants are different credentials. Cyera's lab showed that a key with sufficient permissions can retrieve the underlying OAuth access and refresh tokens for connected services. Once those are exfiltrated, they work directly against the downstream providers until each grant is individually revoked — rotating the platform key does not invalidate them.

What is the blast radius of a leaked broker credential?

It is the union of the scopes of every downstream connection behind that credential. In Cyera's demonstration, one key reached a full Gmail mailbox, GitHub repositories with workflow control, and CircleCI pipeline environment variables.

How does the Waxell MCP Gateway reduce this exposure?

It changes where credentials live and how they are unwound. Agent configs carry a URL rather than an API key, and for OAuth-brokered upstreams the user's refresh token is stored KMS-encrypted in the gateway's credential broker, never returned to the agent client. Deactivating a user revokes every upstream OAuth grant they held through the gateway in one transaction. Calls that don't traverse the gateway are outside its scope.

Sources

• Cyera Research (Assaf Morag), The Hidden Attack Surface of Agentic AI: Securing AI Agent Integration Platforms — August 13, 2026

• Composio, Composio May 2026 Security Incident — bulletin, May 21–27, 2026

The blast radius of a leaked broker key is the union of the grants behind it. The Waxell MCP Gateway keeps upstream tokens in governed custody — never in an agent config — logs every call it brokers, and unwinds a departing identity's grants in one transaction. Start free with the Waxell MCP Gateway — one governed MCP upstream on the Free tier, with 14-day retention.