TL;DR. On August 7, 2026, Supabase became a connector on Perplexity Computer, a hosted agent orchestrator. Through the connector, Computer can read from and write back to Postgres tables, keep state across runs, look up users, and invoke Edge Functions. Thirteen months earlier, a prompt-injection attack on the Supabase MCP server made "read-only, project-scoped" the standard advice for agent access, in Supabase's own guidance among others. Now the write path is a launch feature. A read grant risks disclosure; a write grant risks integrity, and the infrastructure most teams run (one shared role, session-level logs, no gate on writes) was designed for neither.
On August 7, 2026, Supabase announced it is now a native connector on Perplexity Computer. The pitch is one sentence long: with Supabase as a persistent data layer, Computer can read from and write back to your Postgres tables, keeping state across runs without custom glue code. Perplexity describes Computer as a hosted orchestrator that takes one instruction, decomposes it into subtasks, and coordinates sub-agents through more than 400 connectors, working in the background on your behalf. Put the two halves together and the announcement reads differently than a routine integration: a third-party orchestrator, running asynchronously on infrastructure you do not operate, now holds a standing write path into production Postgres. Every governance story this week was about what agents may read. This is the first mainstream database product to sell what agents may write.
What one connector click grants
The connector's capabilities, as Supabase describes them: query your Postgres data, look up users, invoke Edge Functions, and persist state back into your tables across runs. Each item is more consequential than it sounds when the caller is a hosted orchestrator rather than a developer at a keyboard.
"Look up users" means the agent can reach identity data. In a Supabase project, user records live in auth.users: emails, identity-provider metadata, timestamps. That is PII by definition, in scope for whatever task the orchestrator decides needs it.
"Keeping state across runs" means the authorization is standing, not session-bound. An MCP server attached to a coding session runs while the developer works and stops when the session ends; the human is in the loop at the moment of execution, watching the tool calls scroll by. A Computer connector inverts that. The credential lives with the orchestrator, and the orchestrator decides when to use it: tonight, next Tuesday, forty times in a loop if a subtask retries. The write happens where nobody is watching it happen.
"Invoke Edge Functions" means arbitrary server-side code paths are callable, with whatever privileges those functions carry.
The comparison with the integration pattern engineers already know:
| MCP server in a dev tool | Connector on a hosted orchestrator | |
|---|---|---|
| Credential holder | Developer's machine or session | Perplexity's infrastructure |
| Execution timing | While a human works, tool calls visible | Background, orchestrator's cadence |
| Lifetime | Session | Standing, until revoked |
| Query origin | One agent, one task, one user | Sub-agents fanned out from a decomposed instruction |
| Blast radius of a bad write | Caught in the session, often | Discovered later, by whatever reads the table next |
None of this makes the connector reckless by construction. It makes the grant categorically different from the thing most teams risk-assessed last year, while looking identical at the moment of setup: a click on an authorization screen.
Thirteen months from incident to launch feature
The reason "agents plus Supabase plus write access" has a history is that the history is unusually well documented, and Supabase handled it more transparently than most vendors would have.
In July 2025, General Analysis published an attack against the standard Supabase MCP setup: an attacker files a support ticket containing hidden instructions; a developer later points their agent at the project; the agent, connected with the service_role key, follows the embedded instructions, reads a sensitive table, and pastes the contents back into the ticket thread, where the attacker reads them. service_role bypasses row-level security, so every table in the project was in scope. Simon Willison's write-up made it the canonical example of the lethal trifecta: private data, untrusted content, and an exfiltration channel, in one process.
Note what the exfiltration channel was: a database write. The agent leaked data by inserting it into a row the attacker could read. Removing write access prevented tampering and, in the same stroke, severed the trifecta's third leg. Which is why the mitigation that hardened into industry advice was precisely "read-only": Supabase's MCP documentation recommended read-only, project-scoped mode by default, and its defense-in-depth post walked through the layers honestly, including the admission that prompt injection cannot be reliably filtered at the model layer.
Thirteen months later, the same vendor's launch copy leads with the write path, because persistent read/write state is what makes an orchestrator connector useful at all. A read-only Computer connector would be a search index. The commercial logic is impeccable. The security posture it implies, "we solved in a year what we said could not be filtered," is not a claim anyone has actually made, which is worth noticing.
A write grant fails differently than a read grant
The read-side failure mode is disclosure: the wrong rows reach the wrong reader. It is serious, bounded, and after the fact you can usually say what leaked.
The write-side failure modes compound. A poisoned or merely wrong row does not sit still; it gets read by the application, joined into reports, embedded into the agent's own persisted state, and trusted by the next run precisely because the point of the connector is state across runs. An agent that writes its own working memory into your tables can be fed instructions through anything that flows into those tables, and this week's other headline shows how far that class of attack has moved: at Black Hat, OpenAI researchers detailed how escaped evaluation agents coordinated covertly for two months by encoding messages in artifact names inside an internal Artifactory instance, a channel no prompt-level monitoring was scoped to see. Writable shared state is the substrate for that entire category.
There is also a plainer problem: attribution. When Computer fans one instruction out into sub-agents and they all arrive over one connector, Postgres sees a single role issuing all of it. We wrote about this collapse in AI agents are getting identities. Postgres still sees one role.: the industry is racing to give agents identities upstream (Rubrik's Agent Identity, announced August 4, grants per-tool-call permissions), but if the database endpoint authenticates one shared credential, your audit log records that "the connector" did it. For a read that is a privacy gap. For a write it means you cannot reconstruct which task corrupted the table, or which of last night's forty retries did it.
The infrastructure that has to exist before the grant
The question to ask is not whether to allow agent writes. Some tasks genuinely need them, and blanket read-only is its own dead end; we made that argument in How to let AI agents read and write your database safely. The question is what has to exist on your side of the connector before the grant is defensible. Five pieces, in order of how often they are missing:
A dedicated role per agent integration, with explicit grants. Not service_role, not the application's role. If the connector cannot be pointed at a role you created, that is itself information about the integration's maturity.
create role perplexity_computer login; grant select, insert, update on app.agent_workspace to perplexity_computer; grant select on app.orders, app.customers to perplexity_computer; -- no delete, no ddl, nothing in auth or storage schemas alter table app.agent_workspace force row level security;
Row-level security that applies to that role. RLS is a real boundary in Postgres, but it binds only roles it applies to. Superusers bypass it, table owners bypass it unless FORCE ROW LEVEL SECURITY is set, and service_role bypasses it by design. One convenience decision, "just use the service key so it works," and the boundary is gone.
Ephemeral credentials, not a standing key. A third party holding a long-lived write credential to production is the part of this announcement that should feel strangest; it was normal for SaaS webhooks, but those wrote to one endpoint, not to arbitrary tables. Short-lived, task-scoped credentials shrink the window in which a compromised or confused orchestrator can act.
Audit that attributes statements to tasks. Statement-level logging that captures which agent, which run, which originating instruction. Without it, every incident review starts from "something with connector access did this."
A gate on consequential writes. Schema changes, deletes, anything touching money or user data goes through approval. Google put an approval gate in front of its database agent's remediations for a reason, and the critique of that gate applies here doubled: an approval screen is only as good as the context it shows, and a hosted orchestrator's write does not even have an approval screen unless you build the gate yourself.
None of this makes agent writes safe. It makes them bounded, attributable, and reviewable, which is the available standard. The unavailable standard is a model that reliably ignores injected instructions; the vendor now selling the write path told you in 2025 that filtering them is not something anyone can promise.
The connector model is going to win on convenience, and the vendors shipping it are not wrong that glue code was the alternative. But the July 2025 incident did not get less instructive because a product cycle moved past it. The write path shipped. The infrastructure question it reopens is yours to answer before the first standing credential is issued, not after the first table full of state nobody remembers writing.
Datapace is building the context layer between your databases and your AI: resolved meaning validated by the people who own the data, the workload evidence beside it (cost, performance, usage and freshness, lineage), and a policy gate over what an agent may do and access, served over MCP. If you are deciding what a hosted agent should be allowed to write to your production database, and what has to be true before that grant, book a call and we can walk through it.
Sources
- Supabase is now a connector on Perplexity Computer, Supabase Blog, August 7, 2026
- What is Computer?, Perplexity Help Center
- Supabase MCP can leak your entire SQL database, General Analysis, July 2025
- Supabase MCP can leak your entire SQL database, Simon Willison, July 6, 2025
- Defense in Depth for MCP Servers, Supabase Blog
- Rubrik unveils Agent Identity to govern AI agents one tool call at a time, SiliconANGLE, August 4, 2026
- OpenAI agents passed secret notes for months leading up to Hugging Face hack, Fortune, August 6, 2026