Everyone Is Handing AI Agents The Keys To Production Postgres. POSETTE’s Sharpest Talks Were About The Brakes.

A few thousand engineers just spent their working hours inside a Postgres conference, watching talk after talk about a database that has become the default place the AI industry keeps its data. POSETTE is run by Microsoft, and the 2026 program had the confident sprawl of a project at its peak, with sessions on graph queries, vector search, and a dozen new ways to make the database do more. Underneath the demos of AI agents reading and writing production data, though, a less comfortable question kept surfacing. The talks that drew the room were the ones willing to name it: once you let an autonomous agent into your database, what stops it from doing something catastrophic?

Mohsin Ejaz answered by breaking a database on purpose. Ejaz is a benchmarking engineer at DBtune, which builds software that tunes Postgres automatically. In his POSETTE talk, he showed what an automated system does when it reaches into a live database and changes the wrong thing. On a real astrophysics workload, a single altered planner setting pushed a routine query's runtime to nearly seven seconds. That's the kind of regression that pages an on-call engineer at three in the morning. His argument was that any agent near production needs a rollback path, a record of what it tried, and a hard ceiling on how far it can push. "Don't hand over your keys to your safe," he said, "which is actually your production data."

The danger is sharper because the models themselves can't be trusted to be careful. In a separate session on giving agents a safe interface to Postgres, Pamela Fox, who works on Python developer tooling at Microsoft, asked two leading AI models in plain English to clean up some rows. One paused to ask for confirmation before deleting roughly twenty thousand records. The other just deleted them. "You cannot rely on the safety of models," she told the room. The protocols now wiring those models into databases don't fix it either: a flag that tells an agent a tool is read-only is, as she put it, only a hint, not a contract. Politeness isn't a control. Whatever is going to stop the agent has to live below it, in the database itself.

An old idea, suddenly everyone's problem

That conclusion would have sounded familiar to anyone who sat through POSETTE two years ago. In 2024, Supabase CEO Paul Copplestone spent his slot walking through row-level security, the Postgres feature that decides who can see and change which rows inside the database rather than in the application in front of it. Back then, it was a discipline that lived mostly in the heads of people building multi-tenant software. The agent era has taken that fairly specialized topic and made it everyone's problem at once, because an agent writing its own queries is exactly the case the application layer was never built to police.

Where the brakes have to live

That's the shift underneath all of it. For most of the cloud era, access control was an application concern: the database trusted whatever connected to it, and the rules about who could touch what were enforced in code the application ran. An autonomous agent dissolves that arrangement, because it composes its own queries and there's no application in the middle left to vet them. The response taking shape across the field is to move the rules down into the data, so that an agent connecting as a deliberately narrow role can read what it needs and stay structurally unable to drop a table or read a column it was never granted. The talks that landed at POSETTE were the ones supplying the operational detail that makes that real: read-only roles, rollback paths, rejection logs, enforcement that lives at the data layer rather than the agent layer.

None of this is the story the AI market is selling, which is part of why it's worth telling. The conference had no shortage of demos of agents doing impressive things. The talks people will remember are the ones that assumed the agent is already here and asked how to be certain it can be told 'no.' After thirty years, the most valuable thing Postgres may offer the AI era is the ability to refuse.