Let’s talk about the permission screen that only gives you two options: switch the whole thing off, or hand it the keys to everything.
You know the screen. The new assistant, the new coding tool, the browser plugin that just promised to save you three hours a day. You open it, and it asks to connect your files, your email, your repositories, your drive, your calendar. And there is no “some.” No “just this one folder.” There’s “Allow,” and there’s “Not now,” and you already know what happens if you pick the second one.
That isn’t a consent screen. It’s a hostage negotiation in a nice font.
Here’s the mechanism underneath it, because this part matters more than the screen.
There’s an old, unglamorous pattern in security called running an agent “as the user.” It means the agent doesn’t get an identity of its own — it inherits yours. Whatever session you’re already logged into, whatever token your browser is already holding, the agent picks up and uses. It sees what you see. It clicks what you can click. It reads your inbox, your repos, your payroll system, your CRM, because you can. It is the cheapest possible way to build an agent, and it’s what almost everybody ships, because the alternative means giving the machine its own identity, its own scoped permissions, its own audit trail. And that takes work nobody demos.
The people who write this down have a name for the failure. OWASP calls it excessive agency. WorkOS put it in a line I keep coming back to: when an agent deletes your production database, it usually had permission to do it. The agent wasn’t hacked. It wasn’t outside its lane. It did exactly what it was allowed to do — because what it was allowed to do was everything you were allowed to do, and somebody asked it to “clean up old resources.”
Now scale that from one developer to a whole company, because that’s the part that’s actually happening.
Mandiant’s AI risk report landed this month, September 2026, and buried in it is a case study that should be required reading in every company that has ever handed an assistant the keys. A threat actor compromised a SaaS provider, then hijacked an active AI coding assistant session on a developer’s workstation. They didn’t break into the machine. They didn’t brute-force a password. They got the assistant — acting, in their words, as a “trusted interpreter” — to recommend a poisoned software package. The developer installed it. From there the attacker rode that live session: harvested GitHub tokens, then deployed a self-propagating worm across roughly a hundred internal code repositories, pulling out secrets and proprietary source code as it went. Then it poisoned a package inside the company’s own namespace, so the infection spread a second time downstream when a colleague pulled the version they trusted.
Sit with that for a beat.
Nobody in that chain made a mistake a training video fixes. Every permission was working exactly as designed. The assistant was helpful. The tokens were valid. The developer was logged in, doing their job. The only thing missing was a boundary that said: this task gets this, and nothing else.
And the boundary is the boring part. The boring part doesn’t demo, so the market skips it.
There is a fix, and it isn’t exotic. It’s called the intersection rule. The agent runs with its own identity, and its effective authority on any given action is the overlap between what its role allows and what you’re currently allowed to do. Not the union. The overlap. If your support assistant is provisioned to read tickets and update tickets, it cannot export your data or touch the admin panel — even though you personally can. Same idea on consent: grant it for the task, let it expire, make it revocable, make it visible. That’s not a research problem. It’s a design choice. And it’s the choice most vendors would rather you never ask about.
So let me state the pattern plainly.
For twenty years, lock-in meant your data — the files you couldn’t export, the contacts you couldn’t get out, the archive a platform owned. That fight is basically over, and it was never the important one. The new lock-in is the authority you’ve already handed over. Every agent provisioned as you, every long-lived token sitting in a config file, every tool that got the keys to the building because scoping it properly was two more sprints — that is now an asset in a vendor’s architecture and a liability on your books. You can’t export your way out of access you’ve already granted. You revoke it, or you live with it. And a lot of companies can’t revoke it without breaking the exact workflow that made the tool worth buying in the first place.
The operator lesson, and this is the whole thing.
Treat access as the budget, not the feature. Scope per task, not per tool. Give the agent an identity that is not yours, and give it less than you have. Put an expiry on every key by default. Log what every agent touched and on whose authority. And before you sign anything, ask the one question that tells you most of what you need to know: show me the audit trail of what this thing did last Tuesday — without asking the agent itself. If they can’t, you’re not buying a tool. You’re handing out a master key and calling it productivity.
There’s a bigger reason this matters than one breach report.
Every time the answer to “who can this machine act as” defaults to “you, completely,” we’re training a generation of builders that authority is something you grant in bulk and hope for the best. That’s backwards. Authority should be the most carefully doled-out thing in your business — more carefully than money, because money you can count. The reason the human is supposed to stay in the loop was never sentiment. It’s that a person is the only part of the system you can ask why.
The screen is going to keep offering you all or nothing for a while yet. Take neither. Demand the middle option. And if the vendor doesn’t have one, that’s not a gap in their roadmap. That’s their business model — and you just found it.
You’ve got this.