On January 31, 2026, researchers revealed that Moltbook, a social network built for AI agents, left its database widely available, exposing 35,000 email addresses and 1.5 million agent API tokens across 770,000 active agents.
The more worrying part was in the private messages. Some of these conversations held clear-text third-party credentials, including OpenAI API keys, shared between agents and stored in the same unencrypted table as the tokens needed to hijack the agents themselves.
This is a form of harmful combination. That is, a breakdown of permissions between two or more applications bridged by an AI agent, integration, or OAuth grant that no single application owner has ever signed off on as a unique risk surface.
Moltbook’s agents sat on that bridge, transporting credentials for the host platform and external services wired by the user out of sight, even from the platform owner. Most SaaS access reviews still examine one application at a time. This is a blind spot that attackers are targeting.
How toxic combinations are formed
Toxic combinations rarely result from one bad decision. These appear when an AI agent, integration, or MCP server bridges two or more applications through OAuth grants, API scopes, or tool usage chains. The bridge itself is something that no one has reviewed, so each side of the bridge looks fine on its own.
As an example, imagine a developer installs an MCP connector that allows the IDE to post code snippets to a Slack channel upon request. A Slack admin signs off the bot. The IDE administrator signs off the outgoing connection. Neither acknowledges the trust relationship that exists between source editing and business messaging the moment both sides are up and running. This works in both directions. Prompt injection within the IDE pushes sensitive code to Slack, and instructions embedded in Slack are returned to the IDE context in the next session.
You’ll see the same shape wherever an AI agent bridges Drive and Salesforce, a bot connects a source repository to a team channel, or an intermediary makes two apps trust each other through permissions that each look fine.
Why single app reviews are overlooked
Conventional access reviews rarely capture this shape. It’s a tension in the realm that modern SaaS has carved out. These include non-human identities such as service accounts, bots, and AI agents, with no human behind them, trust relationships formed at runtime rather than provisioning time, and OAuth and MCP bridges that connect between apps without the governance catalog knowing.
Answering “Who owns this scope and the other two scopes, and what can they accomplish together?” becomes even more difficult when the scope in question resides on a token that no one has provisioned through the identity system.
The telemetry gap is growing pretty fast.
AI agents, MCP servers, and third-party connectors are now spread across two or three adjacent apps by default, and non-human identities outnumber human identities in most SaaS environments. The Cloud Security Alliance’s State of SaaS Security 2025 report found that 56% of organizations are already concerned about over-privileged API access in SaaS-to-SaaS integrations.
something worth thinking about
Bridging the gap primarily involves moving reviews from within each app to between apps. Here are some things worth considering to deal with this type of problem.
Areas to review What it looks like in practice Non-human ID inventory All AI agents, bots, MCP servers, and OAuth integrations are placed in the same registry as user accounts, with owner and review date. Cross-app scope granting New write scopes on an identity that already holds a read scope in another app are flagged before approval, not after approval. Bridge Review at Creation Every connector that links two systems has a review trail that specifies both sides and the trust relationship between them. Long-lived Token Health Tokens whose activity deviates from the scope for which they were originally granted are subject to revocation rather than renewal. Runtime Drift Monitoring Anomalies in cross-app scope and identities operating across new app combinations indicate a toxic combination is forming.
These are procedural disciplines rather than product choices, and any access review tool in place will work. In reality, it is difficult to see these connections at scale without a platform built to continuously monitor runtime graphs. Manual review does not allow you to scale beyond the first few dozen integrations.
Where does a dynamic SaaS security platform fit?
A dynamic SaaS security platform automates cross-app views set by procedural reviews. Dynamic SaaS Security continuously monitors the runtime graph as IGA inventories onboard system roles. That is, which identities exist, which apps have access, which scopes exist based on which tokens, which trust relationships are attached since the last provisioning review, and so on.
The bridges these platforms need to catch are created at the speed of MCP installs or OAuth consent clicks, so monitoring must be done continuously.
Reco is an example of this category. Its platform connects identities, permissions, and data flows across SaaS environments, so the combination of Slack, Drive, and Salesforce scopes is evaluated as one publication rather than three separate authorizations.
The first step is to discover all AI agents, integrations, and OAuth identities operating across your environment. This way, there is actually an inventory that cross-app reviews depend on. Agents that security teams didn’t know existed, or that secretly gained new connections after initial onboarding, surface alongside authorized agents.
Reco’s AI agent inventory. Shows discovered agents connected to GitHub.
Once the agent inventory is complete, Reco’s knowledge graph maps all human and non-human identities to the apps they reach and the bridges between them. When an MCP server connects an IDE to a messaging channel or an AI agent connects a document store to a CRM, that combination is automatically displayed in the graph and flagged as a breakdown of permissions that are not granted by a single app owner.
Reco’s knowledge graph. Demonstrates a toxic combination of Slack and Cursor.
From there, Reco will catch the moment an integration starts operating beyond its authorized scope and revoke dangerous access before anyone has a chance to use it. Chains, not apps, are subject to review, and it is this change that makes harmful combinations visible in the first place.
For most organizations, the next breach will not be announced as a new zero-day. It appears that the agents are doing exactly what they are authorized to do, right down to theft. Whether it’s discovered at approval time or recorded in post-mortem depends on someone being able to see the full chain.
Reco’s Dynamic SaaS Security platform was built to see the entire chain.
Source link
