News for hackers. Stuff that matters.
Re:Launch HN: Slauth (YC S22) – auto-generate secure IAM pol... by verdverm on Monday December 04, 2023 @09:23AM (#38517598)
More important than SLAs is who takes on the liability for these mistakes? With the changing laws and regulations for breaches, do I want to rely on an LLM that isn't going to own that liability?
Re:Launch HN: Slauth (YC S22) – auto-generate secure IAM pol... by zebomon on Monday December 04, 2023 @09:28AM (#38517649)
Yeah, I think it's a curious decision to have launched this thing with the LLM alone, as using an LLM for something this potentially disastrous is a moot point for me. If they can get a formal simulator running with it, on the other hand, then I'd imagine they may feel more comfortable putting out a guarantee and taking on some kind of liability themselves.
Re:Launch HN: Slauth (YC S22) – auto-generate secure IAM pol... by DanielSlauth on Monday December 04, 2023 @09:31AM (#38517701)
Perhaps I should have emphasized better that indeed the LLM's are trustworthy by themselves and require several extra checks. These would be policy simulators, connecting to cloud environments and running checks in Dev/Staging.

Again, I understand the skepticism using LLM's but currently everything is done manually and it shows that doesn't work well. So using LLM's is a quick way to improve the current situation and hopefully we can further compliment it with checks and balances

Re:Launch HN: Slauth (YC S22) – auto-generate secure IAM pol... by verdverm on Monday December 04, 2023 @09:51AM (#38517966)
> but currently everything is done manually and it shows that doesn't work well

If it is all done manually, and there are both good and bad IAM setups, can you really extrapolate to "manual" being the root cause? How can you even get an LLM to produce secure policies without having existing secure policies to train on? The entire premiss seems off and misleading to me

I would expect a hands-off approach to have worse outcomes