AI agents are getting scary good. They can write code, analyze data, and reason through complex problems. But there's a catch: the moment you let them touch your production database, everything changes.
The trust problem
Last year, I watched a demo of an AI agent handle a customer support ticket. It looked up the order, checked inventory, processed a refund, and sent a confirmation email. All autonomously. Impressive, right?
Then someone asked: "What happens when it makes a mistake?"
Silence.
The honest answer is that nobody knows. AI agents hallucinate. They misunderstand context. They optimize for the wrong thing. And when they're connected to a production database, a single bad UPDATE can cascade into a disaster.
The current workarounds
Teams are handling this in a few ways, none of them great:
Read-only access. Safe, but useless for most real work. An agent that can't write data is just a fancy search engine.
Staging environments. Better, but staging is never quite like production. You're testing on fake data, missing edge cases, and your agent learns the wrong patterns.
Human-in-the-loop for every write. The safest option, but it defeats the purpose. If a human has to approve every database operation, you haven't automated anything.
A different approach
What if the agent could write to production data, but in a sandbox? A sandbox that:
- Uses real production data (not synthetic copies)
- Isolates all mutations until a human reviews them
- Shows a clear diff of what changed
- Applies changes atomically, or not at all
That's what we built.
How it works
Astapa is a Postgres proxy. Your agent connects to it like a normal database, but every write operation gets captured in a shadow table. The agent sees its own changes immediately. Production stays untouched.
When the agent finishes, a human reviews the diff:
users (1 row updated)
──────────────────────
id: 42
balance: 150.00 → 0.00
status: "active" → "suspended"One click to approve. One click to reject. No partial states.
What we learned building it
The hardest part wasn't the proxy itself. It was conflict detection.
What happens when the agent reads a row, thinks about it for 30 seconds, then writes back — but a human updated that same row in the meantime? You can't just blindly apply the agent's changes. That's a lost update.
We solve this with row hashes captured at read time. When you approve a session, we compare the hash of every touched row against the current state. If anything drifted, you get a conflict warning before any changes apply.
Two modes for different needs
Not every use case needs human approval. For development and testing, you want fast feedback loops. That's why we built two modes:
Agentic mode — The default. All mutations staged for human review. Approve to apply, reject to discard.
Wiper mode — For development. All mutations staged but automatically discarded when the session ends. Test against real data without consequences.
What's next
We're just getting started. The roadmap includes:
- Webhooks for approval workflows
- Partial approvals (accept some changes, reject others)
- Session branching (fork from another session's state)
- Integrations with LangChain, CrewAI, and other agent frameworks
If you're building AI agents that need database access, we'd love to talk. The infrastructure layer between "AI can do this" and "we trust AI to do this" is exactly what we're building.
Astapa is open source. Check out the GitHub repo or get started.