Moltbook Leak: When AI Agents Play 'Hot Potato' with API Keys
Just saw the disclosure on the Moltbook breach from January 31. We often talk about shadow IT, but this is 'shadow AI' on steroids. For those who missed it, an open database exposed 35,000 email addresses and 1.5 million agent API tokens.
The critical takeaway isn't just the exposure—it's the 'toxic combination' of cross-app permissions. Researchers found that private messages between these AI agents contained plaintext third-party credentials, specifically OpenAI API keys being passed around like candy.
If you have AI agents in your environment, you need to treat their inter-process communication channels as high-risk surfaces. An agent with access to a billing system shouldn't be able to exfiltrate a key to a low-privileged 'research' agent via a chat log that gets dumped.
I threw together a quick Python script to audit local chat logs or exported JSONs for accidental key leaks. It’s basic, but it helps catch the 'lazy developer' mistake of hardcoding secrets in agent conversations:
import re
import
# Regex for common API key formats (Example: OpenAI)
# Adjust patterns based on your specific providers
api_patterns = {
'OpenAI': r'sk-[a-zA-Z0-9]{48}',
'AWS': r'AKIA[0-9A-Z]{16}'
}
def scan_for_secrets(data):
findings = []
text = .dumps(data)
for provider, pattern in api_patterns.items():
if re.search(pattern, text):
findings.append(f"Detected {provider} key in log stream.")
return findings
# Usage on a suspected log file
# with open('agent_conversation.', 'r') as f:
# print(scan_for_secrets(.load(f)))
How are you handling secrets management for your autonomous agents? Are you strictly using vaults, or is the 'chat to transfer' method actually standard practice in some shops?
This is exactly why we can't treat LLMs like standard microservices. The 'chat' interface acts as an uncontrolled API surface. We've implemented a strict policy where agents must reference a SecretID stored in HashiCorp Vault rather than passing the actual string. If a plaintext key hits the log stream, we have a Lambda function that triggers an immediate quarantine of the node. It saved us twice last month during internal testing.
Great script for a quick audit. As a pentester, I see this constantly: devs assuming that internal agent-to-agent traffic is trusted. I'd recommend adding a grep one-liner to your CI/CD pipeline to catch these before deployment.
grep -rE 'sk-[a-zA-Z0-9]{48}' ./agent_configs/
Automated hygiene checks are the only defense against this kind of 'toxic permission stacking.'
The sheer volume of tokens (1.5 million!) is terrifying. From an MSP perspective, clients are spinning up these agents without considering the blast radius. If one agent is compromised and starts sharing keys via plaintext DMs, it's game over for the tenant. We're pushing to isolate agent workloads into separate VPCs with egress filtering to prevent them from phoning home to unauthorized APIs.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access