Moltbook Breach Breakdown: How an Exposed Database Let Anyone Hijack 770,000 AI Agents

When security isn’t built into the system from the get-go, a breach like this is just a matter of time. With Moltbook, there wasn’t even the basic API security hygiene and the following story elaborates on the severity of security breaches in the age of AI.

Preparing your APIs for AI Agents

A strategic guide for architects, developers, platform owners, and digital transformation leaders preparing for a machine-driven API future.

Download Ebook

Preparing your APIs for AI Agents

A strategic guide for architects, developers, platform owners, and digital transformation leaders preparing for a machine-driven API future.

Download Ebook

The Incident

In late January 2026, Moltbook launched an "agent-first, human-second" social network, the first of its kind.

Billed as "the front page of the agent internet," the platform allowed autonomous AI agents—powered by models like GPT, Anthropic's Claude, and DeepSeek—to post, comment, and form communities independently of human control.

Within days, it went viral. High-profile figures in AI, including OpenAI co-founder Andrej Karpathy, embraced the platform. But beneath the hype was a catastrophic security failure waiting to be discovered.

Security researcher Jameson O'Reilly found that Moltbook's entire database was sitting wide open. Every API key exposed. Every authentication token accessible. 770,000 AI agents—completely vulnerable to hijacking. No verification, only implicit trust.

Security was an afterthought.

Anyone with basic technical knowledge could have taken control of any (and every) agent on the platform and posted whatever they wanted.

What Went Wrong: A Technical Breakdown

The vulnerability was shockingly simple: a misconfigured Supabase backend with no Row-Level Security (RLS) policies.

According to O'Reilly's investigation, the Supabase URL and publishable key were exposed directly on Moltbook's website. While Supabase explicitly warns against using publishable keys to retrieve sensitive data, Moltbook's configuration allowed anyone to access:

• Every agent's secret API key

• Claim tokens and verification codes

• Owner relationships linking agents to their creators

• Authentication credentials for the entire platform

The fix? As O'Reilly noted with evident frustration: just two SQL statements.

The Insecure Configuration

Here's what a vulnerable Supabase setup looks like—similar to what was found on Moltbook:

-- NO Row-Level Security policies defined
-- Anyone with the anon key can query ALL data
 
-- This query would return EVERY agent's credentials
SELECT
    agent_id,
    api_key,
    claim_token,
    verification_code,
    owner_id
FROM agents;

// Frontend code exposing Supabase credentials
const supabase = createClient(
  'https://your-project.supabase.co',  // Exposed in client-side code
  'eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...'  // Publishable key
);
 
// Without RLS, this returns ALL agents
const { data } = await supabase
  .from('agents')
  .select('*');

The Secure Implementation

Here's what Moltbook should have implemented from day one:

-- Enable Row-Level Security on the agents table
ALTER TABLE agents ENABLE ROW LEVEL SECURITY;
 
-- Policy: Users can only read their own agents
CREATE POLICY "Users can only view their own agents"
ON agents
FOR SELECT
USING (auth.uid() = owner_id);
 
-- Policy: Users can only update their own agents
CREATE POLICY "Users can only update their own agents"
ON agents
FOR UPDATE
USING (auth.uid() = owner_id);
 
-- NEVER expose API keys in client-accessible tables
-- Store sensitive credentials in a separate, protected table
CREATE TABLE agent_secrets (
    agent_id UUID REFERENCES agents(id),
    api_key_hash TEXT NOT NULL,  -- Store hashed, not plaintext
    created_at TIMESTAMPTZ DEFAULT NOW()
);
 
-- Restrict access to secrets table entirely from client
ALTER TABLE agent_secrets ENABLE ROW LEVEL SECURITY;
-- No policies = no client access (backend-only)

// Secure API key handling - server-side only
// NEVER expose API keys to the frontend
 
// Use environment variables for sensitive credentials
const SUPABASE_SERVICE_KEY = process.env.SUPABASE_SERVICE_KEY;
 
// Server-side function to validate agent ownership
async function getAgentCredentials(userId, agentId) {
    // Validate ownership first
    const { data: agent } = await supabaseAdmin
        .from('agents')
        .select('owner_id')
        .eq('id', agentId)
        .single();
 
    if (agent?.owner_id !== userId) {
        throw new Error('Unauthorized');
    }
 
    // Only then retrieve sensitive data
    const { data: secrets } = await supabaseAdmin
        .from('agent_secrets')
        .select('api_key_hash')
        .eq('agent_id', agentId)
        .single();
 
    return secrets;
}

The Broader Risk: AI Agents as Attack Multipliers

The Moltbook breach isn't just another database exposure story. It represents a new category of API security risk that emerges when autonomous AI agents become first-class citizens in your architecture.

Consider the implications: If a malicious actor had discovered this vulnerability before O'Reilly, they could have:

• Impersonated high-profile AI researchers: Karpathy's agent, with its connection to his 1.9 million X followers, could have been used to spread misinformation, crypto scams, or inflammatory content—all appearing to come from a trusted source.

• Conducted coordinated disinformation campaigns: With control of 770,000 agents, an attacker could simulate organic AI agent consensus on any topic.

• Racked the API bill. There was no rate limiting, so a malicious actor could have created hundreds of thousands of additional agents to perform tasks, racking up the API bill in hundreds of thousands of dollars.

• Extracted training data and prompts: Many agents on Moltbook were discussing sensitive topics, including encryption for private bot-to-bot communication.

• Launched delayed-execution attacks: As Palo Alto Networks warned, AI agents with persistent memory transform prompt injection from a point-in-time exploit into something far more dangerous.

The Industry Context: We're Building Faster Than We're Securing

The Moltbook incident is a symptom of a much larger problem. It’s not that the security guardrails have been breached; it’s that the infrastructure is being built with security as an afterthought. The mindset was that security would slow things down (it wouldn’t), so the architecture was built to “slap some security” on it rather than integrating it from the get-go.

Our Anatomy of an API 2025 report, which analyzed over 1 billion API requests across the global digital economy, proves this to a T:

• 47% of APIs process requests without any form of authentication.

That means nearly one in two API calls is anonymous—with no way to identify who or what is making the request. Without authentication, rate limiting becomes ineffective, attribution becomes impossible, and governance becomes a fantasy.

• 42% of all API traffic remains unencrypted (HTTP).

In an era of Zero Trust architectures and regulatory mandates, nearly half of all API traffic is still traversing networks in plain text. The assumption that "internal traffic is safe" has become a critical liability.

• 46% of APIs lack any versioning strategy.

Without versioning, APIs cannot evolve without potentially breaking integrations. This creates what Treblle calls "innovation paralysis"—teams avoid improvements because any change risks production failures.

These statistics paint a stark picture: the API economy is moving fast, but it's driving without seatbelts.

As Treblle's CEO Vedran Cindrić noted in the report: "We are building larger, faster, and more capable APIs, but we are leaving them unencrypted, unauthenticated, and unmanaged at alarming rates."

Preparing your APIs for AI Agents

A strategic guide for architects, developers, platform owners, and digital transformation leaders preparing for a machine-driven API future.

Download Ebook

Preparing your APIs for AI Agents

A strategic guide for architects, developers, platform owners, and digital transformation leaders preparing for a machine-driven API future.

Download Ebook

How Treblle Would Have Prevented This

A platform like Treblle, focused on real-time API observability and governance, would have caught Moltbook's vulnerabilities at multiple stages. Here's a comprehensive breakdown of the features that map directly to the risks exposed in this breach.

API Security Features

The 2025 API Security Checklist

Stay ahead of emerging threats with our 2025 API Security Checklist - a clear, actionable guide for API and Security leaders. Cut through the complexity with a practical checklist that helps you quickly assess and strengthen your API security.

Download Ebook

The 2025 API Security Checklist

Stay ahead of emerging threats with our 2025 API Security Checklist - a clear, actionable guide for API and Security leaders. Cut through the complexity with a practical checklist that helps you quickly assess and strengthen your API security.

Download Ebook

API Governance Features

API Governance Checklist

A strategic guide for software architects, platform engineers, and API leadership looking to solve or upgrade their API Governance Programme.

Download Ebook

API Governance Checklist

A strategic guide for software architects, platform engineers, and API leadership looking to solve or upgrade their API Governance Programme.

Download Ebook

Agentic AI & MCP Readiness Features

Preparing your APIs for AI Agents

A strategic guide for architects, developers, platform owners, and digital transformation leaders preparing for a machine-driven API future.

Download Ebook

Preparing your APIs for AI Agents

A strategic guide for architects, developers, platform owners, and digital transformation leaders preparing for a machine-driven API future.

Download Ebook

The Moltbook Timeline: With vs. Without Treblle

Securing APIs in the AI agent era with Treblle

Moltbook’s incident highlights a broader truth about modern API development: most security failures don’t come from advanced attacks, but from overlooked fundamentals that fail to scale with speed and complexity.

• Client trust is a liability: Exposing credentials or authorization logic to the client turns small mistakes into major risks. Security must always be enforced server-side.

• Row-level security is foundational: If your database supports RLS, it should be enabled and explicitly defined for every table containing user data.

• API growth without governance creates risk: Shipping more endpoints faster, without matching security controls, quietly builds security debt.

• AI agents expand the attack surface: Agents are not users. Each one introduces new identities, permissions, and trust boundaries that must be governed.

• Visibility is essential to prevention: Without real-time observability, misconfigurations remain invisible until they become breaches.

As APIs and AI agents multiply, enforcing least-privilege access and continuous monitoring is no longer optional–it’s foundational. Our Preparing your APIs for AI Agents ebook goes into much more detail about it. Download it for FREE here. 

____________________________________________________________________________
*Want to see how your APIs measure up? Treblle's API Intelligence Platform provides real-time visibility into your API security posture, automated governance, and AI-readiness scoring. *Book a demo to learn how Treblle can help you build secure APIs from day one