Live data from Hacker News

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

prized.dev

41–50 of 60 posts

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

#41

Earlier quoted context omitted.

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?

You're right, and we don't. The judge is best-effort screening not enforcement. Enforcement is deterministic with per-tool Postgres roles, proxy-injected creds, host allow-list, human approval on destructive writes. Those hold whether the judge is right or wrong.

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

#42
post #28

nice this is awesome, what i've been building internally for a while now. lovable-esque internal platform with an agentic chat building experience, preview window, our internal auth, internal standards, sandboxed agent devcontainers on k8s. Even down to the shared experience -- these are shared tools for everbody, team ownership structure, not individual. easily forkable, auto-genned product docs etc etc. Hope you ca…

Thanks! The private endpoint tip is very much on point. We've already hit two prospects where the blocker was that they don't want full self-host but their security groups won't take generic cloud egress. It's on the list.

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

#43
post #29

You can do this in lovable too now. But i dont think it gets used a lot. I think it is not very unique, i have seen bunch of providers, some are selling ai workers, some are selling internal tools in different shape and form. 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.…

Fair, the generation part is commoditized. What we sell is the trust layer around company data. No credentials in the builder's hands, scoped access per tool, forkability etc. CC + Railway works until someone pastes a prod key into an env var.

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

#44

Congratulations on the launch. I’m very bullish on this concept of allowing SMB’s and startups to roll their own software and internal tools. Many many moons ago I built an entire inventory tracking and CRM for a very small company in PHP (circa 2006). It ran the entire company with orders, customers, devices, and revenue. It was a monstrous app, and took forever. Today, could be build in a matter of days and much be…

Thanks! Custom beats generic if building it takes days instead of months.

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

#47
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 safe or reliable, no matter how hard you try. Fundamentally, agents will try whatever they can to achieve the goal, as we've seen in many recent security incidents.

If determinism is important, as it is in many business use cases, use agents to build the tool, but don't let them run it.

I built a similar product around this exact idea: AI builds the workflow. Fixed rules run it.

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

#48
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.

Aren't a large number of massive data leaks caused by some Marketing person setting up an AWS instance, and dumping the corporate DB into it?

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

#49
post #29

You can do this in lovable too now. But i dont think it gets used a lot. I think it is not very unique, i have seen bunch of providers, some are selling ai workers, some are selling internal tools in different shape and form. 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.…

Fair, the generation part is commoditized. What we sell is the trust layer around company data. No credentials in the builder's hands, scoped access per tool, forkability etc. CC + Railway works until someone pastes a prod key into an env var.

This is not the most effective way to build trust layer. But anyways.

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

#50
post #21

Earlier quoted context omitted.

Thanks! We believe the building aspect is already commoditized and we're experimenting with leaning into this with BYOA (bring-your-own-agent). Our bet is that the labs will stay focused on the model and won't do the more unglamorous governed deployment layer needs (credential scoping, per-tool db, audit, etc), but time will tell.

Don’t know if anyone else is feeling this, but I’m getting a sense they’re gona have to go in to this layer. Not enough money to warrant the investment in the model only approach…

Particularly if LLMs plateau and intelligence becomes essentially commoditized. If they can't compete on models alone they'll start moving more and more up the stack.
Post reply on HN