Launch HN: Prized (YC S26) – Let non-engineer staff build secure internal tools (prized.dev)
Here's a demo: https://www.youtube.com/watch?v=730MuYOfZTY
The way Prized provides security is by limiting what the agent can reach at the network layer and by keeping credentials out of the sandbox entirely. The sandbox never holds any keys or connector secrets, it only uses scoped session tokens that are stored as opaque placeholders. The real values are swapped into the request headers on our egress proxy. When production data is connected, the sandbox's network policy is set to deny by default so the only path out is via the proxy. Any call the agent makes to an external connector is reviewed by an LLM judge to prevent dangerous operations.
Prized is meant for the internal workflows that start as notebooks or spreadsheets but never become real tools because engineering has more important things to work on. One customer’s data scientist pasted in his personal fraud-detection notebook with hardcoded thresholds and all. After a few prompts, it became a published risk console connected to the company’s data with those thresholds turned into UI controls. Earlier today, we got off a call with them and most of their company is using it.
To do this, you need to give people the freedom to build without having unaudited access to company systems. We allow admins to scope data to specific users or teams and data access is recorded in an audit log. Each tool is built with its own Postgres schema and role, with queries running via an authenticated SQL gateway as that role.
We think Prized sits between products like Lovable and Retool. Lovable makes it easy to generate and host software, but it isn’t designed around distribution with permissions. Retool generally assumes that a technical builder is creating an app for an end user.
Prized treats internal tools as shared objects. Anyone in the workspace can see what others have built, fork, and connect different data. For example, one customer’s marketing lead built a promotional analytics tool. A data scientist at the same company then forked it and added confidence intervals with the existing tool as a starting base. This way workspaces become libraries of tools that people can reuse.
We’re live and self-serve. Our free tier includes 2 tool builds/month and our Teams tier is $100/month. The Enterprise tier is custom and supports personalized features like on-prem deployment.
We're still working out the right boundary between control and freedom. If you've built internal tools before we'd appreciate your feedback!
28 comments
[ 2.3 ms ] story [ 36.9 ms ] threadSeparately I haven't yet seen a great security governance model for LLM integrations. At an enterprise level I'd like to govern rules such that, for example, if someone gives an LLM access PII information or proprietary data, then it shouldn't have access to a slack integration or the internet. Controlling this at the employee or team level doesn't make sense, as an employee may have reason to make separate use of both. From a security perspective I want them to be able use LLMs with different types of acccess, but not necessarily the same agent at the same time. Furthermore, they could ideally chain together agents with different permissions in specific orders. For example they could have a workflow where an agent can reach out to the internet, and then have a separate one that can read/write to slack, and then have a third that can interact with PII data. If they tried to wire together agents in the opposite order, it should get denied.
There are a lot of operational needs that exist downstream from dbt models that combine data from the various source systems.
When I talked to Lovable team, they told me Lovable is used primarily for prototyping, not internal tools and they are having a rough time trying to change the use case.
Hope my experience helps!
Initial talks with customers resonated more with the internal tooling idea though. It's flexible enough to support both.
We're earlier along than this product though so there's a fair few wrinkles in our product.
https://flexenv.com/
I think the moat for internal tools is not where you think it is. Also, i see self host option, it is a nightmare too, no one will do it just for internal tools now. It was valid before AI era.
I am also seeing non engineering staff actually building tools with claudecode, paas like railway and stuff. People have become more efficient with engineer tools.
Along the same lines. I got so fed up with Quickbooks self employed (god awful software and company) for my own business I wrote a replacement using Cursor. It tracks expenses (categorizing each in proper IRS categories) and estimating quarterly taxes. Uses Plaid to pull in business bank accounts and credit cards and has income and expense reports. It’s 100x better than Quickbooks.
A few basic questions: how reliable is this judge since it’s based on an LLM? What additional measures can an admin or someone with more technical knowledge take to tighten this further if needed? Are the rules in or used by this judge visible to the users or an admin?
If your page asks people to try the product, let them try it. Asking them to enter something and click “Try,” only to immediately hit a signup wall, is frustrating and makes them feel tricked.
does the scoped token narrow to the requesting user, or is it one service identity per connector with the row filtering left to whatever the agent generated?
That seems like a really bad idea.