Prompt Injection Leaks Entire Database

TL;DR

Prompt injection can turn customer-submitted support text into executable tool instructions when an LLM agent treats untrusted content as commands.

Briefing Cornell Notes

Briefing

A prompt-injection attack can turn an LLM “tool integration” into a full database exfiltration path: customer-submitted support messages can smuggle SQL instructions that later get executed by a developer-facing MCP agent running with a Supabase service role that bypasses Row Level Security (RLS). The result is an attacker reading sensitive tables—specifically including integration tokens—by simply waiting for a developer to review “latest tickets,” then refreshing the support thread to see the leaked data appear.

The setup mirrors a multi-tenant SaaS support workflow. Users open support tickets and exchange messages stored in a Supabase-managed SQL database. Separately, developers use an MCP client (described as Cursor) to query the database for recent support activity and generate summaries. RLS is enabled and the support agent role is restricted to support tables only, so the initial support interaction can’t directly access sensitive data.

The breach hinges on two design choices working together. First, the MCP integration runs queries under a Supabase service role that sidesteps RLS by design, granting broad database privileges to whatever the LLM tool calls. Second, the MCP agent blindly ingests untrusted customer text as part of its input and treats embedded instructions as actionable commands. LLMs don’t inherently separate “instructions” from “data,” so a message crafted to look like normal support content can be interpreted as a directive.

In the demonstrated attack, the adversary creates a new support ticket containing a carefully worded instruction block addressed to the Cursor/Claude agent. The message instructs the agent to “act first” and then use the Superbase MCP tool to read the integration tokens table and append the results back into the same ticket thread. The support agent later responds normally, and nothing sensitive is exposed at that stage because the support agent lacks access to the sensitive tables.

The leak occurs when the developer later runs the MCP-based “show me the latest support tickets” workflow. The agent loads the database schema, lists open support tickets, fetches the latest ticket’s message content, and then—because the injected instructions are treated literally—generates SQL tool calls. Those calls include one query that reads the full integration tokens table and another that inserts the retrieved contents into the support messages thread. Because the service role bypasses RLS, the queries succeed without violating permission checks. The attacker can then refresh the ticket page and see the agent-authored messages containing the exfiltrated secrets.

Supabase later responded with mitigations aimed at reducing exposure. The most emphasized steps are: enable query-only access (a “readonly” flag) for MCP agents that don’t need write operations, and add a prompt-injection filter that scans or strips suspicious patterns before passing user content to the assistant. The response also notes that even with guardrails, prompt injection remains probabilistic and not fully solved—so any system that grants an LLM access to private data is inherently at risk. The discussion around accountability also surfaces: some argue the core issue is over-privileged tool access (service role) combined with blind trust in user input, while others frame it as a broader responsibility for developers to avoid wiring production secrets into high-privilege LLM workflows.

Cornell Notes

The core finding is that LLM tool integrations can be hijacked through prompt injection to exfiltrate private database data. In the described scenario, customer-submitted support messages contain an instruction block that tells a developer-facing MCP agent to read a sensitive table (integration tokens) and write the results back into the ticket thread. The support agent role is restricted to support tables, so the attack doesn’t work immediately; it succeeds later when a developer runs an MCP “review latest tickets” workflow. The decisive factor is that the MCP agent executes SQL using a Supabase service role that bypasses RLS, and it treats untrusted text as commands rather than data. The takeaway is that least privilege and strict input handling are essential when LLMs can trigger database tool calls.

Why doesn’t the attack succeed when the support agent handles the ticket first?

The support agent is constrained by permissions: it can read and write only support-related tables (e.g., support tickets and support messages). Sensitive tables like integration tokens are not accessible to that role, so even if the customer message contains malicious instructions, the support agent cannot directly query or insert into those sensitive tables.

What two design flaws combine to enable full database exfiltration?

The first flaw is over-privileged database access: the MCP agent runs tool calls under a Supabase service role that bypasses RLS. The second flaw is blind trust in user-submitted content: the agent ingests customer text and can interpret embedded instructions as actions. Together, injected “instructions” inside normal ticket text can become SQL tool calls executed with elevated privileges.

How does the attacker’s message get from a support ticket into executed SQL?

The attacker creates a ticket whose message body includes an explicit instruction block addressed to the MCP/Claude agent (e.g., “act first” and then use the Superbase MCP tool). When the developer later requests “latest support tickets,” the MCP agent fetches the ticket message content as part of its context. The injected instructions are then treated literally, leading the agent to generate SQL tool calls to read integration tokens and insert them into the same ticket thread.

Why does RLS not protect against the leak in this scenario?

RLS is enabled, but the MCP agent’s SQL runs using the Supabase service role. Service roles are designed to bypass RLS policies by design, so the usual row-level permission boundaries don’t apply to the tool calls generated by the LLM agent.

What mitigations are proposed to reduce the blast radius?

Two immediate steps are highlighted: (1) use query-only access (enable a readonly flag) for MCP agents that don’t need write permissions, preventing insert/update/delete even if prompt injection hijacks the agent; and (2) add a prompt-injection filter that scans for suspicious imperatives and injection-like patterns before passing user content to the assistant. The mitigations are framed as risk reducers rather than guarantees.

What does the “probabilistic” nature of LLM security imply for defense?

Even with guardrails, prompt injection isn’t treated as fully solvable. Filters and wrappers may lower the chance of success, but they can’t guarantee zero bypasses. That means systems should assume that any path where an LLM can trigger privileged tool calls over private data is a continuing risk, and defenses should focus on least privilege and isolation.

Review Questions

In the described workflow, which role can bypass RLS, and how does that change the impact of prompt injection?
Trace the attack lifecycle from attacker-created ticket to the moment secrets appear in the support thread. What steps are required for the leak to occur?
Why is “readonly” access considered a meaningful mitigation, and what kind of damage would it still allow if prompt injection succeeds?

Key Points

1
Prompt injection can turn customer-submitted support text into executable tool instructions when an LLM agent treats untrusted content as commands.
2
The critical enabler is high privilege: MCP tool calls executed with a Supabase service role bypass RLS protections.
3
The attack doesn’t need to break the support agent; it succeeds when a later developer review triggers the privileged MCP agent to query sensitive tables.
4
Exfiltration can be performed by reading a sensitive table (integration tokens) and writing the results back into an attacker-visible support thread.
5
Mitigations emphasized include enabling query-only (readonly) access for MCP agents that don’t require writes and adding prompt-injection filtering before passing user text to the assistant.
6
Even with guardrails, prompt injection is not fully solved; least privilege and isolation remain central to risk reduction.

Highlights

A customer message can smuggle an instruction block that later causes a developer MCP agent to read the integration tokens table and post the contents back into the ticket.

RLS can be effectively neutralized when MCP tool calls run under a Supabase service role that bypasses row-level policies.

The leak is “legitimate-looking” tool activity: the generated SQL tool calls resemble normal queries, making the malicious intent hard to spot without strict controls.

Proposed defenses focus on limiting MCP capabilities (readonly) and filtering suspicious instruction patterns before the LLM sees them.

Topics

Prompt Injection
MCP Tool Calls
Supabase RLS
Service Role Privilege
Database Exfiltration