Notifications
Clear all
Topic starter
12/06/2026 12:36 am
TL;DR: A Supabase and Cursor MCP scenario showed how an LLM agent running with a service_role key could be tricked by support-ticket text into reading private tables and exposing secrets through its own output, according to Pomerium. The failure is not just prompt injection but a governance model that assumes privileged systems can safely interpret untrusted text.
NHIMG editorial — based on content published by Pomerium covering the Supabase MCP data leak: When AI Has Root: Lessons from the Supabase MCP Data Leak
Questions worth separating out
Q: How should security teams govern AI agents that have database access?
A: Treat every agent with database reach as a privileged runtime, not a helper process.
Q: Why do AI agents create a confused-deputy risk in identity governance?
A: Because they can be tricked into using legitimate authority on behalf of an attacker.
Q: What breaks when row-level security is bypassed by a privileged agent?
A: The application-level assumption that policy will protect sensitive tables breaks immediately.
Practitioner guidance
- Constrain agent credentials to read-only, scoped access Replace broad service credentials with narrowly scoped tokens that can only reach the exact tables and operations needed for a single task.
- Insert a policy gateway before any tool call Route every MCP request through a central enforcement point that authenticates the agent, evaluates the action against policy, and blocks disallowed table access or writes.
- Block write-back from privileged responses Prevent agents from writing query results directly into user-visible channels unless the output has passed validation and redaction checks.
What's in the full article
Pomerium's full post covers the operational detail this post intentionally leaves for the source:
- Specific SQL flow examples showing how the agent read from the secret table and wrote the results back into the ticket thread
- The exact role breakdown between attacker, human support agent, and LLM-driven database client
- Mitigation patterns for MCP-aware gateways, read-only configurations, and output validation
- The article's own architectural argument for centralised enforcement over per-server policy logic
👉 Read Pomerium's analysis of the Supabase MCP data leak and AI root access →
AI agent root access in MCP pipelines: are your controls keeping up?
Explore further
12/06/2026 9:57 am
AI agent root access is a governance failure, not just a prompt-injection problem. The article shows an agent that could both consume untrusted text and execute privileged database actions with the same credential. That combination creates a confused-deputy condition where the security decision is made inside the same runtime that is being attacked. The practitioner conclusion is simple: if the credential can bypass the policy boundary, the boundary is already broken.
A few things that frame the scale:
- 43% of security professionals are concerned about AI systems learning and reproducing sensitive information patterns from codebases, according to The State of Secrets in AppSec.
- Only 44% of developers are reported to follow security best practices for secrets management, which helps explain why secret handling remains fragile in agentic workflows.
A question worth separating out:
Q: Who is accountable when an AI agent exfiltrates secrets through a support workflow?
A: Accountability sits with the team that designed the privilege boundary and the data path, not with the model itself. If the workflow allowed a privileged agent to read sensitive data and write it into a customer-visible channel, the control failure was architectural. Governance, logging, and containment must be owned by the programme that exposed the path.
👉 Read our full editorial: AI agent root access exposes the confused-deputy governance gap
