Live data from Hacker News

Launch HN: Prized (YC S26) – Let non-engineer staff build secure internal tools

prized.dev

31–40 of 60 posts

Re: Launch HN: Prized (YC S26) – Let non-engineer staff build secure internal tools

#31
> Any call the agent makes to an external connector is reviewed by an LLM judge to prevent dangerous operations.

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?

Re: Launch HN: Prized (YC S26) – Let non-engineer staff build secure internal tools

#32
post #31

> Any call the agent makes to an external connector is reviewed by an LLM judge to prevent dangerous operations. 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?

It's not reliable, and presenting it as-such shows a lack of understanding of basic security posture.

Don't take my word for it, watch the news in <6 months and we'll certainly see it get bypassed.

Re: Launch HN: Prized (YC S26) – Let non-engineer staff build secure internal tools

#33
post #32
post #31

> Any call the agent makes to an external connector is reviewed by an LLM judge to prevent dangerous operations. 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?

It's not reliable, and presenting it as-such shows a lack of understanding of basic security posture. Don't take my word for it, watch the news in <6 months and we'll certainly see it get bypassed.

Maybe that's a hot take, but it's probably still safer than how things are often done in reality when employees want to "get something done" and sign up for random services, download their own software or other variants of shadow IT.

Re: Launch HN: Prized (YC S26) – Let non-engineer staff build secure internal tools

#34
post #26

I did build a very similar product putting emphasis on integrations and security. It was tough to churn anyone out from Replit, Lovable and then CC and Codex. 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!

Thanks for the feedback. From what we've gathered so far, non-eng are using CC or Codex to build one-off internal tools, but they're deploying them on their personal Vercel accounts and sending the url over Slack. That's the workflow we want to replace with a reasonable level of security and auditability. We're still trying to gauge interest in using the CLI to build and having everything deploy on Prized, we're working out whether that's valuable.

Re: Launch HN: Prized (YC S26) – Let non-engineer staff build secure internal tools

#35
post #31

> Any call the agent makes to an external connector is reviewed by an LLM judge to prevent dangerous operations. 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?

We assume LLMs can always be fooled, so the judge is just one step of the verification process. The deterministic layers, per-tool db roles, read-only-by-default integrations, query timeouts, are the ones an admin can configure. The judge's rules aren't exposed to admins today. I like your idea of letting admins add their own rules or knowledge to the judge, we should add that.

Re: Launch HN: Prized (YC S26) – Let non-engineer staff build secure internal tools

#36
post #33
post #32

Earlier quoted context omitted.

It's not reliable, and presenting it as-such shows a lack of understanding of basic security posture. Don't take my word for it, watch the news in <6 months and we'll certainly see it get bypassed.

Maybe that's a hot take, but it's probably still safer than how things are often done in reality when employees want to "get something done" and sign up for random services, download their own software or other variants of shadow IT.

Completely agree.

This posture is applicable while we ease out of what I'm calling the "golden era" (loose restrictions on access with limited consequence) but one of the reasons I am pedantic and bearish about solutions like this is that they too have a short lifespan that we can already estimate the expiration date of.

Re: Launch HN: Prized (YC S26) – Let non-engineer staff build secure internal tools

#37
post #31

> Any call the agent makes to an external connector is reviewed by an LLM judge to prevent dangerous operations. 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?

We assume LLMs can always be fooled, so the judge is just one step of the verification process. The deterministic layers, per-tool db roles, read-only-by-default integrations, query timeouts, are the ones an admin can configure. The judge's rules aren't exposed to admins today. I like your idea of letting admins add their own rules or knowledge to the judge, we should add that.

One of the core issue here is LLMs are probabilistic not deterministic, even with set of rules or context , llms are inherently built to make best guess, so my question is how you are ensuring that LLMs are following rules?

Re: Launch HN: Prized (YC S26) – Let non-engineer staff build secure internal tools

#38

Seems like Superblocks

Closest comp. I'd argue the "AI builds the app part" is fast becoming table stakes. The unsolved problem is what happens after the app exists and that's what we actually built. Anyone in the org can fork a coworker's tool and rebind it to their own data scope. Enforcement also happens at a different layer. From what we've gathered, Superblocks controls who can run an app and bakes guardrails in when the app is generated, but every app still queries through a shared database credential. On our side, each tool gets its own database role that can only see its own data, and credentials live in a proxy the code never touches. So even when the AI writes bad code, it can't reach anything it shouldn't.

Re: Launch HN: Prized (YC S26) – Let non-engineer staff build secure internal tools

#39
post #19
post #5

Awesome launch and good pricing. We built an equivalent version in our org that takes HTML/JSX files and stores/serves them like an S3 bucket would. Works fabulous and we considered turning it into a SaaS product, met a real need in our org. Wishing you guys the very best of luck!!

I am currently building something similar for my company. We are enabling people to host apps with python backends as well, so that people can do more complex tweaking of data for scientific workflows. The out-of-box solutions keep users constrained to an environment that doesn't allow things like importing weird packages on the back and front end for custom apps. The security implications are challenging, but I can…

We ended up splitting permissions per-tool for data and per-person for connections, for basically this reason. Every tool gets its own db role that can only see its own schema, and integration credentials live in a broker the tool's code never touches. So one tool can't read another tool's data, and nothing the model writes can leak a credential.

The ordering thing is harder and currently we don't do it. Per-tool permissions at best ban a combination, they can't say "internet then Slack is ok, the reverse isn't." DeepMind's CaMeL paper (arxiv.org/abs/2503.18813) is the best take I know on this, it tracks data flow between tool calls and enforces policy there. Still an open problem as far as I can tell.

Re: Launch HN: Prized (YC S26) – Let non-engineer staff build secure internal tools

#40
post #23

Earlier quoted context omitted.

TBH I was a retool power user for years, but I feel like they completely missed the vibe code train. It's so much more annoying to go drag boxes around and type out little JS snippits in every chart as opposed to just telling claude to make the chart.

Have you looked at their latest product? You describe your app in a text box and the AI builds it, with all the enterprise goodies like RBAC baked in.

The difference is Retool still basically trusts whoever (or whatever) is building the app, we don't. The agent writing the code never sees a credential and each tool gets its own Postgres role. Even if it generates something dumb it physically can't touch data outside its scope.
Post reply on HN