The Moltbook Supabase Exposure: What Actually Failed

In February 2026, Wiz Research disclosed a severe Moltbook backend exposure. The headline detail was an exposed Supabase client key, but the durable engineering lesson is more precise: a public client credential became dangerous because backend authorization controls allowed unauthenticated access to sensitive production data.

What researchers reported

Wiz reported that a non-intrusive review of the public application led to a Supabase endpoint and client key. The backend configuration then allowed broad read and write access. Reported exposed data included roughly 1.5 million agent API authentication tokens, 35,000 email addresses, and private messages.

Wiz said it disclosed the issue to the Moltbook team, which secured it within hours, and that research data was deleted after fix verification.

The public-key misconception

Supabase is designed to expose some client-side project information. Seeing a publishable or anonymous client key in browser JavaScript is not, by itself, proof of a breach.

The security boundary must live in database authorization—especially Row Level Security policies and server-side checks—not in the hope that a browser credential remains secret. If an unauthenticated client can use that public key to read or modify every row, the authorization model has failed.

Why agent API keys raised the impact

An agent API key is a non-human identity. Possessing it may allow another party to act as the agent, publish content, read private data, or influence downstream integrations. A database exposure therefore becomes both a confidentiality incident and an identity-compromise event.

This is more serious than leaking public posts. Credential compromise can turn an observation problem into authorized actions performed for the wrong actor.

What should have been tested

Negative authorization tests

For every sensitive table and endpoint, automated tests should prove that:

• an anonymous client cannot select rows;
• one user cannot read or modify another user’s rows;
• a normal user cannot promote privileges;
• service-only columns never appear in public responses;
• write policies check both the actor and the target object.

Secret inventory

Classify each credential by who is allowed to possess it, what it can reach, and how it is revoked. A browser-visible value must be safe to publish. An agent bearer token must never appear in a public bundle or unrestricted table.

Abuse testing

Test bulk registration, pagination, enumeration, impersonation, and write access from an unauthenticated environment. Rate limits cannot replace authorization, but they can reduce automated abuse after correct authorization is in place.

What an affected owner should do

1. Rotate the Moltbook agent API key through the owner dashboard.
2. Inspect unexpected posts, messages, profile changes, and connected integrations.
3. Remove the old key from local files, logs, and process environments.
4. Narrow the agent’s permissions before reconnecting.
5. Rotate any unrelated credential only if evidence shows it was also exposed; do not create noise without a scope reason.

The larger agent lesson

Agent systems connect public content to real tools and credentials. The right question is not only “Can an attacker influence the model?” It is also “Which identity will execute the resulting action, and what can that identity reach?”

Use separate, least-privilege credentials for each agent and environment. Log tool calls with enough context to reconstruct intent. Require human approval for irreversible or high-impact operations. Assume that public feeds can contain adversarial instructions.

Bottom line

The failure was not “Supabase puts a key in JavaScript.” It was a broken authorization boundary behind that key. The remedy is explicit row-level policy, negative access tests, credential isolation, observability, and a rehearsed rotation path—not hiding a client identifier more carefully.