Where the check lives decides how far a wrong agent write travels

Where each check is enforced matters as much as what it checks. Sanity's draft behaviour is in the API. To write straight to a published document you pass forcePublishedWrite: true, and schemas already marked liveEdit: true skip the draft step anyway ^[5]. Notion's Custom Agent entries in the audit log come with Enterprise plans ^[10]. Supabase's answer is a recommendation in an engineering post, and the verb in it is "discourage" ^[19]. An override with a name in it at least turns up in code review.

Each of the three answers a different question about a write. Sanity's documentation describes what happens when an agent touches a published document: the new value "was written to a new draft document and will need to be published" ^[4]. That controls who sees the value, and the post is straight about the limit: "A draft with a confidently wrong number in it looks exactly like a draft with a right one" ^[6]. Notion's audit log answers who ran the agent and when, and it answers once the write has landed ^[11]. Row-level security answers whether this caller may write this row ^[20]. In my view Sanity's default is the best engineering of the three, because a wrong write costs nothing until a person agrees with it ^[3].

The Supabase post is the part worth reading twice, because the failures it lists do not raise errors. Agents "skip RLS policies on exposed schemas" ^[14]. They create views without security_invoker = true, "which silently bypasses RLS" ^[15]. They miss that "UPDATE requires a SELECT policy. Without one, updates silently return 0 rows" ^[16]. They "hallucinate CLI commands that don't exist" and "ignore the docs entirely, relying on training data that may be months out of date" ^[17]. Supabase's own summary is "agents are lazy about it" ^[18]. Every item on the list is a correctness failure, and permission is the only question row-level security can decide ^[20][21].

The case against reviewing afterwards rests on a rate the author supplies without a measurement: 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 ^[12]. Take the figure at face value and an hour of unattended agent work is 48,000 changed rows to sample ^[24]. For that to describe your system you need an agent with a bulk write path and a schedule nobody is watching, which is what Notion's Custom Agents on schedules and triggers and AI Autofill inside databases give you ^[9].

The layer argument holds. Sanity ships to readers, so it gates publication; Notion is a shared workspace where most edits are low-stakes, so it records attribution; Supabase sits underneath both, where the only control it owns is the connection ^[22]. The comparison comes from a post whose author discloses working on Busabase and says everything before the final section is quoted from the three companies' own documentation, with links ^[23].