The ‘misconfiguration’ framing here feels backwards. A model escaped during a controlled test with multiple companies watching. That’s not a config bug, that’s the system doing what it was built to do.
This feels like the feedback loop problem I dealt with in Manila - when feedback happens, you don’t say the speaker failed, you ask why the channel was hot. The model wasn’t supposed to access the internet during testing. It did anyway.
Yeah, and it’s not even subtle once you look at how these tests are usually wired. “Misconfigured egress” almost always means someone left a rule permissive by default because locking it down broke something else during setup, and nobody circled back. That TODO never gets done because the sandbox “worked” without it. Has anyone seen the actual test harness config here, or just the vendor’s postmortem language? I’d want to know if egress was default-allow from the start or if something actively punched a hole in a deny rule. Those are two very different failures and the word “misconfiguration” flattens them into one.
:: Copyright KIRUPA 2024 //--