On the egress judge: an LLM reviewing connector calls inline is a probabilistic control sitting where a capability grant belongs. The operations that actually cause damage are largely enumerable: writes, deletes, and bulk reads of personal data. Those should be absent from the scoped token rather than present and then argued about by a judge with a nonzero false-negative rate under adversarial input, with the judge kept for the ambiguous long tail where enumeration genuinely fails. This is the WAF story again, request inspection in front of an app was a useful compensating control, and every team that mistook it for the boundary relearned that the boundary was the parameterized query and the database grant.
Launch HN: Prized (YC S26) – Let non-engineer staff build secure internal tools
51–60 of 60 posts
Re: Launch HN: Prized (YC S26) – Let non-engineer staff build secure internal tools
#52Earlier quoted context omitted.
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?
I wouldn't say that's a "Marketing person" failure mode, there's enough open buckets, public mongodb or Elastic instances with wrong credentials.
Re: Launch HN: Prized (YC S26) – Let non-engineer staff build secure internal tools
#53the credentials-out-of-the-sandbox part is the easy half. the quieter failure is a tool that holds no keys and still renders rows this particular employee was never meant to see.. sign-in proves who someone is, it doesn't scope what the query returns.
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?
Re: Launch HN: Prized (YC S26) – Let non-engineer staff build secure internal tools
#54Earlier quoted context omitted.
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?
I wouldn't say that's a "Marketing person" failure mode, there's enough open buckets, public mongodb or Elastic instances with wrong credentials.
Fair point.
Re: Launch HN: Prized (YC S26) – Let non-engineer staff build secure internal tools
#55As someone who isn't an engineer but shipped a real product this year by leaning
on AI tooling, the thing that surprised me most wasn't building the features — it
was everything around them: payments, auth, not breaking prod, knowing when the
output was subtly wrong. The "build" got cheap; the judgment didn't. Curious how
you handle that last part for non-technical users.
Re: Launch HN: Prized (YC S26) – Let non-engineer staff build secure internal tools
#56I know someone who could use this but a price point/plan between $0 and $100 would be a good way to help people get started.
Heard, we're actively working on this and should have updated pricing plans soon.
Re: Launch HN: Prized (YC S26) – Let non-engineer staff build secure internal tools
#57Please don't let users "try" your product only to immediately hit a signup/signin wall. It instantly undermines whatever trust the demo may have established.
More on this, we're still experimenting between a hard vs. soft paywall. Regardless, if you sign up it should be easy enough to play around with it for a while on the free tier. We promise that we don't send spam/marketing emails.
Re: Launch HN: Prized (YC S26) – Let non-engineer staff build secure internal tools
#58As someone who isn't an engineer but shipped a real product this year by leaning on AI tooling, the thing that surprised me most wasn't building the features — it was everything around them: payments, auth, not breaking prod, knowing when the output was subtly wrong. The "build" got cheap; the judgment didn't. Curious how you handle that last part for non-technical users.
The basic build was never that expensive; the complications are always where the time goes.
Re: Launch HN: Prized (YC S26) – Let non-engineer staff build secure internal tools
#59>Let non-engineer staff build secure internal tools
That seems like a really bad idea.
Re: Launch HN: Prized (YC S26) – Let non-engineer staff build secure internal tools
#60Please don't let users "try" your product only to immediately hit a signup/signin wall. It instantly undermines whatever trust the demo may have established.
More on this, we're still experimenting between a hard vs. soft paywall. Regardless, if you sign up it should be easy enough to play around with it for a while on the free tier. We promise that we don't send spam/marketing emails.
It’s not about what you offer on the free tier. It’s about whether what you say matches what you do.
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.