Hacker News .hnnew | past | comments | ask | show | jobs | submitlogin
Show HN: rmBug – audited database access for humans and agents (rmbug.com)
14 points by mdjanic 57 days ago | hide | past | favorite | 8 comments
We've been building things together for a long time. LEGO first, then software.

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



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!


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.


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.


Right? I can’t think of a single company I worked at/with where this was not the case.


Feel free to reach out. We're always happy to talk to people and learn about how we can resolve your problem :)


Same here. I would have used this pretty much anywhere.


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




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: