ClarifyThe autonomous CRM that helps you sell more
Promoted
valv
Your database, safe for agents to query
46 followers
Your database, safe for agents to query
46 followers
Connect Postgres, MySQL, ClickHouse and PostHog once. Scope each role down to the row. Your team's agents work on live data and never see more than you allow.
valv
valv
Hey everyone 👋
We launched the valv library a while back. Today we're taking it all the way.
valv gives your agents access to all your data, safely, in seconds. No handing over credentials, no exposing a row they shouldn't see.
Connect Postgres, MySQL, ClickHouse and PostHog, scope every role down to the row, and let your whole team point their own MCP agent at live data.
The part we're most excited about: your coding agent can now build custom HTML dashboards straight from your data and share them across the platform, each with its own per-query permissions. Real dashboards, built by your agent, in minutes, locked down by default.
Take a look at https://valv.sh and use PRODUCTHUNT for 50% off your first 3 months.
Curious which data sources you'd connect, and what we should add support for next 🙏
Scoping agents down to the ROW is the right unit — table-level grants are way too coarse once agents run against live customer data. Curious about the failure mode though: when an agent's query touches rows outside its scope, do you filter silently or fail loudly? Silent filtering keeps things running but produces confidently-wrong answers on aggregates (the agent never knows its SUM is missing half the rows). How do you handle that trade-off? Congrats on the launch.
valv
@nitish_garg4 Hey, thanks! Permissions are always scoped to the user. That means the agent doesn't even know a table doesn't exist if it's not within it's permissions.
The query will fail with a permission error if it runs anyways, informing the model that access is restricted.
Giving agents scoped, safe query access to a database is exactly the missing piece in most agent-SDK stacks right now — most teams either hand over full DB creds or write a brittle custom proxy. Is the permission model row/column-level or table-level, and how do you handle write-adjacent operations (temp tables, CTEs with side effects) that could leak data even under read-only grants?
valv
@hazy0 Hey, the permissions can be scoped to table level or row level depending on your use case. You can even create different roles with different permissions.
The query tools don't allow for anything potentially risky to run on the database, but we are expanding it to make it more powerful constantly!
Dial
the dashboard sharing part is what caught my attention. if my agent builds a dashboard off data i can see and shares it to a teammate with narrower row access, does the dashboard re-check permissions against the viewer at load time, or does it bake in whatever the builder could see at creation time
valv
@galdayan Hey, permissions are checked for the individual user every time they load the dashboard. Even if you revoke someone's permissions this will affect what they can see on custom dashboards, through MCP or the chat instantly!
Database access for agents is where small mistakes get expensive. I would be curious how valv handles write operations: dry-run by default, schema-aware guardrails, or approval queues before anything mutates data?
valv
@yaroslav_stelmakh Hey, the valv platform currently doesn't allow writes. Would be curious what your use case is here!