I’ve had a good think about this, and while it’s good to see them finally answering bubblewrap, the truth is that we as an industry have been ridiculously at permissioning for some time and this does not solve this. It’s all very well saying we have read only resource access, but then you connect up to JIRA and all of a sudden you’ve got a different identity system, different resource model and and more complexity than you can shake a stick at.
Our current answer of just making the security model more and more complex isn’t working. It just means that, when things inevitably fail, we can say “well, they didn’t secure it correctly”. When even describing what is correct is hard, and setting it up is harder.
Honestly, this looks good, but we need a root and branch rethink of security if we want something that can protect us from rogue agents.
> An agent cannot be its own security authority. It must run within a boundary defined by the developer or organization and enforced independently of the agent itself.
...so make it its own security principal, distinct from the human user?
> Without a managed execution boundary, the agent may decide that changing the server configuration is the fastest way to complete the task and potentially break the production site.
It can decide that even with the execution boundary in place, you know. What matters if it can actually act that out.
All in all, a very sloppily written announcement. Almost as if it was written by—
Windows already has a multi-user security context, with file- and API-level permissioning. We often call it “Users” or “RBAC”. I’ve read it and I’m still not sure what I can do now that I couldn’t a week ago.
Can I use this as a generic app permissions boundary or do I have to somehow fake it as an "agent"? We are well past the point where I need to be able to lock down that my music player has no ability to read my SSH keys or whatever.
Naturally, this will be gated to corporate customers - the plebs do not get access to better security unless they pay for a top tier license.
Our current answer of just making the security model more and more complex isn’t working. It just means that, when things inevitably fail, we can say “well, they didn’t secure it correctly”. When even describing what is correct is hard, and setting it up is harder.
Honestly, this looks good, but we need a root and branch rethink of security if we want something that can protect us from rogue agents.
...so make it its own security principal, distinct from the human user?
> Without a managed execution boundary, the agent may decide that changing the server configuration is the fastest way to complete the task and potentially break the production site.
It can decide that even with the execution boundary in place, you know. What matters if it can actually act that out.
All in all, a very sloppily written announcement. Almost as if it was written by—
That presumes the existence of a security context, which this product provides. Where do you configure the security principal otherwise?
https://en.wikipedia.org/wiki/Most_Extreme_Elimination_Chall...
Naturally, this will be gated to corporate customers - the plebs do not get access to better security unless they pay for a top tier license.