Heaps of ranting here about agents sucking down private data to Microsoft servers without your knowledge, where a cursory look at this feature is to give you more control if you actually want to use agents. Sure, it might be learned reflex behavior, but that is exactly what OP was talking about.
"This feature is completely optional and is never turned on by default."
Reading the full article this is just a power user feature and in beta at that. I can see where it could be useful and the fact it puts further restrictions on how each agent works mitigates security issues.
Fundamentally, having a model that makes it easy to give access to an entire library instead of requiring explicit tight scoping of access to individual files is dangerous and teaches people to make mistakes that can lead to data misuse and leaks.
What evidence are you basing that on?
From what I read of the article if it was on by default, it does nothing.
When it's on you get the option to create an agent. That's when you need to be careful.
Even so, the current version is off, it has a big warning about the dangers of using it before and during switching it on.
> that makes it easy to give access to an entire library instead of requiring explicit tight scoping of access to individual files is dangerous
Again from the article, the user literally set the access rights of the agent.
So don’t give it access?
It clearly says it’ll have granular ACLs. How is this any different from something like Gemini CLI or Claude Code where you’re running it in your src directory?
It’s basically that, but for non-devs and with a GUI instead of a TUI.
It's similar to UAC - a good and important protection, but fundamentally if you're letting code run with access to your plain old non-administrator documents that's where the biggest data threats are.