I gave my prod database credentials to claude
I've been connecting my coding agents to everything: Datadog logs, Linear, Slack. It still feels like I hit the same wall every time I actually need to debug something serious.
The model can read the stack trace and the ticket thread. The part where I prove what happened in the data, row by row, is still on me. I open the database viewer, find the connection, find the table, rebuild the join in my head, export a slice, paste it back into chat. It's not hard. It's a time sink, and it breaks the flow of everything else I wired up.
So I'm on the thread with my coding AI Agent, I explain the bug, then I tab away and click through schemas anyway. After a while that mismatch started to really annoy me.
At some point I hacked together a repo on my laptop. It generated SQL and talked to the database for me, and it worked better than I expected.
It also made me nervous. Credentials sitting around, no real story for who could run what, no audit trail I could point at if something went sideways. I kept using it for a week and felt worse about it each day.
I wanted the same speed without the part where I pretend that's fine.
So I ended up with something that looks like a wrapper: read-only paths, permissions that actually mean something. The schema gets pulled in and cached so I'm not dumping DDL into a new chat every time I start over. There are timeouts and rate limits so a bad prompt can't turn into a runaway query.
Somewhere in there I shipped QueryBear.com. I wasn't chasing a market thesis. I was the person who needed the thing.
Now when I'm chasing a production issue, I can stay in one thread with my coding AI Agent. The model isn't guessing my tables from memory, and it's not holding raw keys to the kingdom either.
I'm not saying I solved security for everyone. I'm saying this is the first setup where the convenience didn't make me feel like I was about to regret it.
If you've wired up agents to everything but you still live in the database viewer, I'm curious what you did. I'm still figuring out where the line should be.
The interesting question buried in this story, for me at least, is which version of "prod credentials" you actually handed over. There's a real architectural difference between a scoped read-only role on three specific tables, which is something I'd hand to an agent without thinking too hard, and a full DB user with write access across the schema, which is the version that lights up the room.
Curious which one this was, because the takeaway from the post depends almost entirely on that. The framing of "you should never give an agent prod access" is the productivity-blogger version of the lesson. The actual lesson, when I've been close to the fire, is that prod access is a permissions-design question, not a binary one. Agents make the lazy version of the design more expensive.
“This is a really sharp observation — most AI debugging setups stop at semantic context, but production issues live in data verification.
The real friction isn’t reading logs or tickets anymore — it’s safely bridging into structured data without breaking trust boundaries or forcing humans back into the database layer every time.
What you built is basically that missing middle layer: controlled execution + cached schema context + safety boundaries. That’s exactly where most ‘agentic debugging’ tools quietly fall apart today.
You should test this thinking in a live setting as well — we’re running a small round where builders are exploring infra + agent workflows like this. $19 entry, winner gets a Tokyo trip (flights + hotel).
Round 01 just opened (100 cap) — best odds right now.”