Disclosure: I work on Busabase, which takes the approach described at the end. Everything before that is quoted from the three companies' own documentation, with links.
Three platforms shipped AI agent write access in the last year. All three had to answer the same question — what happens when the agent writes something wrong — and they gave three genuinely different answers.
I read the documentation for a comparison project and ended up with three quotes that are more interesting side by side than apart. None of these companies is wrong. They are solving the problem at different layers, and knowing which layer yours is on saves you from adopting the wrong mechanism.
Sanity: drafts, by default
Sanity's Agent Actions are event-driven APIs that generate, transform and translate content. The notable part is the default:
By default, Agent Actions never mutate a published document. Whenever you supply a published ID, the action creates a draft first before applying any changes.
And if you run one against a published document, the new value "was written to a new draft document and will need to be published."
You can turn this off with forcePublishedWrite: true, and schemas marked liveEdit: true already behave that way. But the safe path is the default — which is the opposite of how most products shipped agent write access, and it deserves more credit than it gets.
What it buys: nothing reaches a reader until a human publishes it.
What it does not answer: whether the value is correct. A draft with a confidently wrong number in it looks exactly like a draft with a right one.
Notion: audit logs, after the fact
Notion 3.6 (July 2026) shipped External Agents, and the first two are Claude and Cursor. You "assign them tasks from a board shared with your whole team, @-mention them like teammates, and watch them run." Custom Agents run on schedules and triggers; AI Autofill brings them directly into databases.
For oversight, Enterprise plans get this:
The audit log includes Custom Agent activity, so you can see when an agent runs, what it changed, and who triggered it.
That is a real mechanism. It answers who changed this, and when.
What it does not answer: should this have become true — and it answers the first question only after the write has landed.
This is the part worth sitting with. Audit logs were designed for a world where writes were slow and the next reader was a person. An agent can update 800 rows in a minute, and the next reader is usually the next agent run, a scheduled report, or a page a customer sees. By the time a human notices, the wrong value has been read, summarized and acted on.
"You can see what the agent changed" and "you can control what the agent changes" quietly stopped being the same promise.
Supabase: don't point it at production
Supabase positions itself as "the complete Postgres developer platform built for agentic workloads" — MCP server, Agent Skills, RLS on every call. Their own engineering post about agents is unusually candid. Agents, they write:
- "skip RLS policies on exposed schemas"
- create views without
security_invoker = true, "which silently bypasses RLS" - miss that "UPDATE requires a SELECT policy. Without one, updates silently return 0 rows"
- "hallucinate CLI commands that don't exist"
- "ignore the docs entirely, relying on training data that may be months out of date"
And plainly: "agents are lazy about it."
Their conclusion follows from the evidence:
We strongly discourage connecting the Supabase MCP server to your production database.
Local or staging only.
That is sound advice, and it is worth noticing why it is sound. Look at their list again: every item is a failure of correctness, and the mechanism being asked to catch it — RLS — governs permission. RLS answers may this caller write this row. It cannot answer is this the right value. An agent with entirely correct permissions writing a confidently wrong number passes every check the database has.
At the engine layer there is no other answer available, which is exactly why "keep agents off production" is the honest recommendation rather than a cop-out.
Three layers, not three grades
Put the three next to each other and they are not competing implementations of one idea. They are three different layers:
| Platform | Gate | Unit | Catches |
|---|---|---|---|
| Sanity | Before publication | The document version | Content reaching an audience unreviewed |
| Notion | After the write | The session | Attribution — who ran what, when |
| Supabase | At the connection | The environment | Agents touching production at all |
Each is well-matched to what that product is for. Sanity's destination is a reader, so the gate is publication. Notion's surface is a collaborative workspace where most edits are low-stakes, so the mechanism is attribution. Supabase is infrastructure, where the only lever available is who may connect.
The gap all three leave open is the same one: a write that is permitted, well-formed, and false.
How to tell which one you need
Three questions, in order:
- Does the output get published to an audience? If yes, a publication gate is the right mechanism, and Sanity's default is the shape you want.
- Is the next reader a person who was watching? If yes, attribution is enough — an audit log answers the questions that actually get asked.
- Is the next reader another agent, a report, or an app? Then neither gate helps, because nothing in the path evaluates whether the value is true before something downstream consumes it.
The third case is where teams get surprised. It looks like the first two until a wrong row has been read by four things before anyone opens it.
What closes it: a pull request for your data
Developers already have the mental model. Code does not go straight into main. It goes through a pull request: a diff of exactly what changes, an author, a place to comment, an approval, and a merge commit that records when it became real.
Agent writes to data today are the equivalent of giving everyone direct push access to main. The three gates above are each a partial substitute — publication review is a release branch, an audit log is git log with no review step, and "don't connect to production" is not granting access at all.
What none of them is, is a pull request. Applied to data, that means:
| Pull request | Applied to a data write |
|---|---|
| The diff | Which fields change, from what to what |
| The author | Which agent proposed it, on what evidence |
| Review | A person sees it before it is true, not after |
| The merge commit | When it became canonical, and who decided |
The same shape applies to what an agent knows, not just what it writes — prompts, instructions and reusable skills drift exactly the way code does, and benefit from exactly the same treatment.
What that looks like in practice
Busabase is the third option — a workspace built so the write path is a pull request by default. Disclosure again: I work on it. It is MIT-licensed and runs locally, so the fastest way to judge it is to run it rather than read about it:
npx busabase server
# → http://localhost:15419/dashboard/local
No signup, no account, no cloud. It starts with an embedded Postgres (PGlite), local file storage, and demo content already in place.
Point an agent at it — MCP, an Agent Skill, or the OpenAPI surface at /api/v1 — and have it write something. This is what arrives:
The changed fields with before and after, which agent proposed it, the source it used, and a comment thread. You approve, request changes, or reject. Approved values become canonical and keep the proposer, reviewer and commit attached.
The same applies to the agent's skills and instructions, which is the part I did not expect to matter as much as it does: a reusable skill that drifts silently is the same failure as a record that drifts silently, and it responds to the same fix.
Two honest limits, since this is a post about reading documentation carefully: review is proportional to consequence — low-stakes writes stay fast, and a key with merge rights merges immediately — and if nothing your agents write is worth inspecting, this whole mechanism is overhead you do not need.
Sources: Sanity Agent Actions docs, Notion 3.6 release notes, Supabase — AI Agents Know About Supabase. They Don't Always Use It Right.. Verified 21 September 2026; all three ship frequently.
Longer versions of each comparison, with the sources and a section on where the other product is the better choice: vs Notion · vs Sanity · vs Supabase
Top comments (1)
The distinction between “is this write allowed?” and “is this write correct?” is the part I’d emphasize most. Permissions, RLS, and audit logs can establish who was allowed to change something and what happened, but none of them validate the business truth of the resulting state.
I’d add one layer between the agent and canonical data: a semantic validation boundary. The agent can propose the mutation, deterministic checks can validate schema/invariants, and domain-specific checks can flag changes that are technically valid but inconsistent with expected state. Only then should the write become authoritative.
That separation has been useful for us at IT Path Solutions when working with production AI workflows. The important question isn’t just whether the agent can write it’s whether the system can independently establish why that write should become the new source of truth.
The “pull request for data” analogy works well here because it also gives you something code reviews already provide: a durable record of proposed state, evidence, review, and the exact point at which the change became canonical.