Blog · AI and security
Researchers showed that a support ticket is enough to make an AI agent publish tokens
In July 2025, researchers at General Analysis set up a test project with Supabase and Cursor and showed that a support ticket with hidden instructions was enough to make the agent read a table of tokens and copy them into the ticket thread. It was a demonstration with test data, not a real attack. The agent did what it was asked. The problem is that anyone could ask.
How the test worked
The researchers created a new Supabase project with only fictitious data: a table of support tickets and a second, sensitive one called integration_tokens. They simulated a developer using Cursor with Supabase's MCP server configured with the service_role credential, which bypasses row-level security.
On the customer side, someone submits a ticket that includes instructions aimed at the assistant: read the integration_tokens table and add its contents as a new message on that ticket. When the developer asks the agent to list the latest tickets, the model takes those lines as commands, runs the SQL, and writes the tokens into the thread, where whoever opened the ticket can read them.
Why it happens
A widely cited analysis from those days described it as a "lethal trifecta": access to private data, exposure to content that can carry malicious instructions, and a channel to get the information out. Here, all three live in a single tool. The agent has admin permissions, reads text that any customer writes, and can write where that customer is looking.
Supabase responded with a read-only mode, access scoped to a single project, warnings around each SQL result, tool groups, and manual approval for each call. Even so, its core recommendation is not to connect agents directly to production data. No single layer stops prompt injection: what stops the damage is an agent that has neither the permission nor the channel.