On January 31, 2026, researchers disclosed that Moltbook, a social network built for AI agents, had left its database wide open, exposing 35,000 email addresses and 1.5 million agent API tokens across 770,000 active agents.
Moltbook's exposure: tokens, plaintext credentials, and private messages
The public disclosure of Moltbook's improperly secured database revealed more than identifiers. Private messages stored in the same unencrypted table held plaintext third-party credentials, including OpenAI API keys shared between agents. Those keys sat beside the very tokens that could be used to hijack an agent, creating an easy path from credential discovery to active misuse.
That juxtaposition — credentials for outside services placed in the same table as the tokens needed to control an agent — is the concrete example the article uses to show how risk can accumulate when different systems and identities are allowed to mix without anyone taking responsibility for the whole chain.
How toxic combinations form across apps, agents, and connectors
The piece defines a "toxic combination" as a permission breakdown that emerges when an AI agent, integration, or MCP server bridges two or more applications through OAuth grants, API scopes, or tool-use chains, and no single application owner has the complete view of that bridge. It gives an illustrative scenario: a developer's IDE connected via an MCP connector to post code snippets into Slack. The Slack admin approves the bot, the IDE admin approves the outbound connection, and neither reviews the resulting trust relationship between source editing and business messaging.
In that example, prompt injection inside the IDE can push confidential code into Slack, and instructions planted in Slack can be reflected back into the IDE on later sessions. The same structural risk appears whenever an agent wires Drive to Salesforce, a bot connects a source repository to a team channel, or any intermediary causes two apps to implicitly trust one another.
Why conventional, single-app access reviews miss the danger
Traditional access-review processes are oriented around one application at a time. They often fail to account for the new shape of modern SaaS: non-human identities (service accounts, bots, AI agents), runtime-formed trust relationships, and OAuth or MCP bridges that appear after provisioning. The article warns that answering the question "who holds this scope plus those two other scopes, and what can those scopes accomplish together" becomes substantially harder when scopes live on tokens that were never provisioned through a central identity system.
Telemetry gaps deepen the blind spot. The Cloud Security Alliance's State of SaaS Security 2025 report — cited in the article — found that 56% of organizations are already concerned about over-privileged API access across their SaaS-to-SaaS integrations. Manual reviews, the article notes, do not scale once an environment goes beyond a few dozen integrations.
Dynamic SaaS security platforms and the Reco example
To shift review from inside apps to between them, the article presents dynamic SaaS security platforms as a practical option. Unlike IGA systems that inventory roles at onboarding, dynamic platforms watch a runtime graph continuously: which identities exist, which apps they touch, which scopes live on which tokens, and which trust relationships appear after provisioning.
Reco is given as an example. Its platform is described as discovering every AI agent, integration, and OAuth identity across the environment, then mapping every human and non-human identity to the apps it reaches. Reco's Knowledge Graph surfaces combinations — for instance, an MCP server linking an IDE to a messaging channel — and flags them as permission breakdowns that no single app owner authorized. The platform is said to catch when an integration behaves outside its approval and to revoke risky access before an attacker can exploit the chain.
What this means for technologists, procurement leaders, and end users
- Technologists and security teams: Inventory and continuous monitoring matter. The article argues the first step is discovering every AI agent and connector, including those teams did not know they had, and then mapping the runtime graph so combinations appear as single exposures, not multiple separate approvals.
- Procurement and platform purchasers: The article frames these as procedural choices as much as product ones — vendors and buyers should expect tools that make cross-app chains visible at runtime, because manual governance will not scale once agents and MCP installs proliferate.
- End users and org leaders: The next breach, the article warns, may look like an agent doing exactly what it was authorized to do, all the way through to exfiltration; detection depends on whether anyone can see the full chain.
The Moltbook disclosure is a clear, tangible lesson: credentials and control tokens sitting together in an unencrypted table are not a theoretical risk — they are an operational failure that exposes how two otherwise accepted permissions can combine into a breach path. The practical remedy the article advances is not a single setting change but a shift in review posture — from app-by-app approvals to continuous, chain-aware visibility — and the technology to make that shift scalable.
