Show HN: rmBug – audited database access for humans and agents(rmbug.com)
rmbug.com
Show HN: rmBug – audited database access for humans and agents
https://rmbug.com/
9 comments
I've been building this at https://querybear.com.
Engineers are adopting AI agents faster than any other group. They connect these coding agents to github, slack, linear, jira, datadog, sentry, everything. I saw the limiting factor being the database so sought to build a solution.
But obviously there's a lot that can go wrong giving a raw access point into the database. Querybear is the security layer to protect from anything bad happening.
Been using it for months and we have multiple startups using it and loving it. Have had no issues yet!
Engineers are adopting AI agents faster than any other group. They connect these coding agents to github, slack, linear, jira, datadog, sentry, everything. I saw the limiting factor being the database so sought to build a solution.
But obviously there's a lot that can go wrong giving a raw access point into the database. Querybear is the security layer to protect from anything bad happening.
Been using it for months and we have multiple startups using it and loving it. Have had no issues yet!
The per-identity model is the right direction — shared credentials for agents is one of the most under-discussed risks in the space.
One thing we've run into: even with proper credential isolation, agents can still exfiltrate data if they're compromised via prompt injection. The credential controls who can access the DB; runtime policy controls what the agent is allowed to do with that access. They're complementary layers.
We built Navil specifically for the runtime enforcement side — it sits between the agent and its MCP tools and can block calls that violate policy even if the agent has valid credentials. Happy to share notes on where we've seen the two layers interact in real deployments.
One thing we've run into: even with proper credential isolation, agents can still exfiltrate data if they're compromised via prompt injection. The credential controls who can access the DB; runtime policy controls what the agent is allowed to do with that access. They're complementary layers.
We built Navil specifically for the runtime enforcement side — it sits between the agent and its MCP tools and can block calls that violate policy even if the agent has valid credentials. Happy to share notes on where we've seen the two layers interact in real deployments.
I've encountered so many situations where this software would have made my life easier. Shared credentials are so common, and its hard to navigate around them, but this could finally resolve that.
We end up re-solving this at every company I've been at, so can definitely see the need. How does it work with remote and local MCP servers?
Hey Vedran. You connect to the database the same way you always did - when the agent spins up, you get a port, and you just point your MCP servers at it.
DATABASE_URL="postgres://localhost:15432/mydb"
That's it. The MCP server doesn't know or care about rmBug.
The one extra thing: by setting RMBUG_API_KEY in your environment, AI agents like Claude Code can spin up the rmBug agent themselves - no manual rmbug connect needed. The agent handles auth and port allocation autonomously, then your MCP tools connect through it as normal.
RMBUG_API_KEY="rmb_agent_..." # lets Claude Code spin up the agent
DATABASE_URL="postgres://localhost:15432/mydb" # MCP servers connect here
DATABASE_URL="postgres://localhost:15432/mydb"
That's it. The MCP server doesn't know or care about rmBug.
The one extra thing: by setting RMBUG_API_KEY in your environment, AI agents like Claude Code can spin up the rmBug agent themselves - no manual rmbug connect needed. The agent handles auth and port allocation autonomously, then your MCP tools connect through it as normal.
RMBUG_API_KEY="rmb_agent_..." # lets Claude Code spin up the agent
DATABASE_URL="postgres://localhost:15432/mydb" # MCP servers connect here
Across every company and project since, one thing kept showing up: database access security was broken. Not always dramatically. Sometimes it was the budget. Sometimes months of convincing. Sometimes just a quiet burden nobody talked about.
Support staff with access to every customer's financial data. Engineers who left but somehow still had credentials. A "temporary" password living in Confluence or floating around in Slack DMs.
It's 2026 and this is still the default.
Solutions cost time and money, usually both. Or they need self-hosting and years of maintenance. Or they're homebrewed and will break sooner than you'd like. You could vibe-code something, sure. But do you want to do that for something as critical as your customers' data?
rmBug was built because of this. It gives everyone touching your database their own identity. No shared credentials, no orphaned access, no murder mysteries. Whether you're two founders or two hundred engineers, you shouldn't need an enterprise contract or a weekend of self-hosting to know who's in your data.
We launch with MySQL and PostgreSQL today, April 1st. Not a joke.
What we support will grow with your feedback. We're here.
Try it at rmbug.com. Tell us what's missing.
Mario & Luka