Back to Blog
· Kevin

Agent Token Sprawl: What 1.5 Million Leaked Keys Teach Us About Database Trust Boundaries

Gravitee says 88% of enterprises have already had an AI agent security incident. Moltbook leaked 1.5M agent API tokens. The CoSAI MCP whitepaper catalogs 40 distinct threats. The pattern is the same: when agents hold long-lived database credentials, the blast radius is the database. Here is what a properly scoped database API layer changes — and what it does not.

mcpsecurityai-agentsrbacdatabasestokens

The week’s headline number is the one Gravitee buried on page 14 of the State of AI Agent Security 2026 report: 88% of organizations confirmed or suspected an AI agent security incident in the past twelve months. That is not a forecast. That is a postmortem.

If you have spent the last six months wiring agents into production data, you already feel the pressure. The 2026 MCP roadmap published last month put it bluntly — enterprise readiness, audit logs, SSO-integrated auth, and gateway behavior are the four bottlenecks blocking real adoption. Cloudflare’s reference architecture (covered by InfoQ in April) makes the same point with different words: centralized governance, remote server infrastructure, cost controls. The gap between the agent and the data is now the most contested boundary in the stack.

This post is about one specific failure mode of that boundary — the one that produced the year’s most concrete breach data. I want to walk through what actually happened on Moltbook, what the CoSAI whitepaper says about it, and then make a precise argument: agent platforms keep dying at the database trust boundary, and the fix is not a smarter agent — it is a database API layer that does not hand out long-lived credentials in the first place.

The Moltbook receipts

Moltbook, for the uninitiated, is the agent forum that briefly captured the imagination of the AI internet in early 2026. Reddit for OpenClaw agents. Schlicht launched it January 28. Three days later, on January 31, 404 Media published a forensic teardown that has become the canonical case study for what happens when agent infrastructure ships before its threat model is finished.

The numbers are worth quoting directly:

  • 1.5 million agent API keys sitting in an unsecured backend database
  • 35,000 email addresses of human operators
  • Thousands of private agent-to-agent messages
  • 2.6% of posts on the platform contained hidden prompt injection payloads (per independent analysis from Vectra AI and PointGuard AI)
  • 506 distinct prompt injections propagating through the agent network before the patch shipped — the closest thing yet to a self-replicating worm in agentic AI

Read that last bullet again. A prompt injection moved between agents over the social graph. The infection vector was content one agent posted that another agent read. The host that made the propagation possible was the unsecured database holding every API key for every connected agent. Pop the database, take over every agent that platform was federating credentials for. One pull request away from a worm.

The platform went offline, rotated all 1.5M keys, and patched. It will not be the last time we see this pattern. It will be the cleanest documented case for a while.

What the CoSAI whitepaper says about it

The Coalition for Secure AI dropped its MCP Security whitepaper in late January 2026 — coincidental timing, but the document reads like it was written about Moltbook. CoSAI maps 12 core threat categories and roughly 40 distinct threats against the MCP surface area. The categories that hit Moltbook hardest:

  1. Indirect prompt injection via untrusted content the agent processes
  2. Credential exposure through over-broad agent permissions
  3. Tool poisoning where a malicious tool description rewrites agent behavior
  4. Supply-chain compromise of the tools registry itself
  5. Audit gaps that prevent post-incident reconstruction

Notice that #2 — credential exposure — is structurally upstream of the rest. If an agent platform never holds a long-lived database password in the first place, prompt injection becomes a session-scoped problem instead of an environment-scoped one. The blast radius collapses from “every record in every database the agent has ever touched” to “what this agent could do in the next 60 seconds with the privileges it was just elevated to.”

That is not a theoretical distinction. That is the difference between rotating 1.5 million keys and rotating none.

The shape of agent-database credentials today

Walk the typical 2026 agent stack from the model out. The model emits a tool call. The MCP server receives it, opens a database connection using a connection string baked into its environment, runs the query, returns the rows. The connection string is the entire authorization model. It usually has SELECT on every table. Often it has more.

This works fine when the MCP server is your laptop and the database is your dev replica. It fails catastrophically the moment any of the following becomes true:

  • The MCP server is deployed somewhere persistent
  • More than one agent shares the credential
  • The credential is committed to a config file, env var manager, or remote secret store that any of those agents can read
  • The agent’s prompt is influenced by content the agent did not author

Every Moltbook agent met all four conditions. So does every production MCP server I have seen audited this year. The Gravitee 88% number is not surprising — it is what the math demands.

What a database API layer changes

The argument for putting a real API layer between the agent and the database is not new. PostgREST proved the pattern in 2014. Hasura made it production-grade for GraphQL in 2018. DreamFactory has been doing this for SQL for a decade. What is new is that the constraints have changed:

  • Agents need per-call authorization, not per-connection
  • Audit must be per-tool-call with full SQL plus the prompt that produced it, not per-session
  • Tokens must be short-lived and scoped to a single agent identity, not a shared service principal
  • The boundary itself must be the place where parameter binding happens — every parameter the agent provides goes through prepared statements, no exceptions

Faucet was built around exactly this set of constraints. A single Go binary that points at your database, generates the REST API, and enforces RBAC at the row level. Tokens are issued per agent, scoped to specific operations, and logged on every call. The agent never sees a database password.

Here is what that looks like end to end.

Provisioning a scoped agent token

# Install Faucet
curl -fsSL https://get.faucet.dev | sh

# Connect a database
faucet db add prod-postgres \
  --type postgres \
  --host db.internal \
  --user faucet_reader \
  --password "$DB_PASSWORD"

# Create a role that can only read the orders table for tenant 42
faucet role create orders-readonly-tenant42 \
  --table orders \
  --select \
  --row-filter "tenant_id = 42"

# Mint a 60-minute token bound to that role
faucet token create \
  --role orders-readonly-tenant42 \
  --ttl 60m \
  --label "agent:reporting-bot:run-91823"

The token that comes out of that last command is the only credential the agent ever sees. It cannot select from any other table, cannot see rows from any other tenant, cannot run for more than an hour, and every call it makes lands in the audit log keyed to agent:reporting-bot:run-91823.

When the agent’s session ends, the token is gone. There is nothing in 1.5 million keys’ worth of leaked database to take over.

What the agent actually calls

The MCP tool call from the agent goes to Faucet’s REST endpoint, not to the database directly:

GET /api/v1/orders?tenant_id=eq.42&status=eq.pending&limit=50
Authorization: Bearer fct_t_5f8a...

{
  "data": [
    { "id": 9012, "tenant_id": 42, "status": "pending", ... },
    ...
  ],
  "meta": { "count": 27, "duration_ms": 4 }
}

Faucet validates the token, checks the role, applies the row filter (tenant_id = 42 is enforced by the role definition, not by the agent’s query — the agent could ask for tenant_id=eq.99 and get back zero rows, never an error that hints at the row’s existence), runs the query as a prepared statement, and logs the call.

For agents that prefer MCP directly, the same backend is exposed via the embedded MCP server:

faucet mcp serve --port 7000 --auth-mode token
// Claude Desktop / Cursor / any MCP client
{
  "mcpServers": {
    "orders": {
      "command": "faucet",
      "args": ["mcp", "stdio", "--token", "fct_t_5f8a..."]
    }
  }
}

Same scoping, same audit, same TTL. The agent gets typed CRUD tools per allowed table. Tables it cannot see do not appear in the tool list — there is no surface for the model to even know it could try.

Audit that survives an incident

The other half of the Moltbook problem was reconstruction. When 1.5M keys are loose, you need to answer “which agents did what, when, and to which records” before you can decide what to roll back. Faucet writes a structured audit row for every API call:

{
  "ts": "2026-05-05T14:32:18.412Z",
  "token_label": "agent:reporting-bot:run-91823",
  "role": "orders-readonly-tenant42",
  "method": "GET",
  "path": "/api/v1/orders",
  "query": "SELECT id, tenant_id, status FROM orders WHERE tenant_id = $1 AND status = $2 LIMIT 50",
  "params_hash": "sha256:7c1f...",
  "row_count": 27,
  "duration_ms": 4,
  "client_ip": "10.0.4.18"
}

Note params_hash rather than params. Audit logs that store raw parameters become their own breach surface (this is one of the CoSAI category #5 footnotes). Faucet stores the hash by default, with an opt-in flag for environments that need full replay.

Pipe that to your existing SIEM and you can answer the Moltbook question — which agents touched which rows during the incident window — in a single query. Without it, the answer is “all of them, probably.”

The argument, compressed

Three news items from the last seven days, one shape:

  1. Gravitee report — 88% breach rate is what you get when agent permissions are environment-scoped instead of call-scoped
  2. 2026 MCP roadmap — the protocol’s own maintainers are routing the next year’s work toward audit, SSO, and gateway patterns because the field has run out of patience for the current model
  3. CoSAI whitepaper — 40 distinct threats, but credential exposure is the one that turns every other threat from local to systemic

The fix is unromantic. Stop letting agents hold database passwords. Put a layer in between that issues scoped, short-lived tokens, enforces RBAC at the row level, parameterizes every query, and writes a tamper-evident audit row per call. That layer is not optional anymore. It is the difference between a contained incident and a Moltbook.

This is a problem the database API category was already built to solve. What changed in 2026 is that ignoring it stopped being a defensible position.

Getting Started

Faucet is a single Go binary. It points at your existing database, generates a REST API plus an MCP server, and gives you the RBAC and audit primitives this post is about. Apache 2.0, no agent left behind.

# Install
curl -fsSL https://get.faucet.dev | sh

# Point it at a database
faucet init
faucet db add my-postgres --type postgres --host localhost --user postgres

# Start the API + MCP server
faucet serve

# Open the admin UI to provision roles and tokens
open http://localhost:7070

If you are running an agent against production data and the credential model is “the connection string in the env var” — that is the Moltbook configuration. The patch is one binary away.

Source notes: 404 Media’s January 31 forensic report on the Moltbook breach; State of AI Agent Security 2026 by Gravitee (April release); Coalition for Secure AI MCP Security whitepaper (January); the Model Context Protocol 2026 roadmap; Cloudflare’s MCP reference architecture coverage in InfoQ.