If you've connected an AI assistant to a tool — your calendar, a repo, your email, a browser — you've seen the dialog. The agent wants to do something, and you get a choice: allow this action, or don't. And, helpfully, a third button: always allow.

You clicked it. Everyone does.

There are two things happening here. Both reveal something important about why AI security is broken, and how we can fix it.

Allow/deny is the wrong question

“Should I allow this agent to access my email?” is asking about whether the agent should be given permission to read (or send) email on your behalf. But the question that actually matters is: “What is the agent going to do once I grant it access?” Hell, even the agent doesn’t know! LLMs generate their output token by token—an agent truly has no idea what it will do with a permission until it’s already doing it.

Choosing “always allow” is a rational response

The second problem is that you clicked always allow, and you were right to. Being forced to approve every individual action most likely destroys the reason you connected the tool in the first place. Security that gets in the way gets turned off — that’s one of the oldest findings in the field. This is sometimes called “approval fatigue,” and it’s common and for the most part expected. Faced with a choice between unusable and unsafe, people reliably choose unsafe. Not because they are stupid or bad, but because the choice gave them exactly two options, and one of them defeated the purpose of the product.

AI has made a core security assumption false

It’s worth being very clear about what’s happening here: you are granting a standing permission to a non-deterministic system.

I don’t know about you, but this sentence is a horror movie to me. We didn’t just let the killer into the house by mistake. We intentionally opened the door, greeted them warmly, and handed them a knife from our butcher block.

Every access-control model we have—firewalls, IAM roles, OAuth scopes, allowlists—was built on an assumption so foundational (and until recently, so obvious) that nobody thought to write it down: the application being authorized behaves predictably.

A service account does exactly what its code says. A firewall rule governs packets that mean the same thing every time. When you grant standing permission to a deterministic system, you can reason about what you’ve granted, because the system’s future behavior is a function of its code.

AI agents break this fundamental assumption. Nobody—not you, not the company that deployed it, not the lab that trained the model—can tell you what an AI will decide to do with that authority six months from now, on an input no one anticipated. The permission itself is static and well scoped. The thing you’re granting permission to is not.

The structural question vs. the semantic question

All of that preamble brings us back to the dialog. The dialog asks you a structural question: do you trust this tool, yes or no?

The question that matters is semantic: what is the AI trying to do, right now, in this context—and is that okay?

This gap is not a UX flaw. It’s the entire deterministic security model showing its age. Every security layer that has ever worked has worked for the same reason: the thing it inspected had structure. Ports, packets, scopes, roles, signatures. You could enumerate the classes, decide about each class once, and enforce forever. Class-level decisions were sufficient because behavior within a class was uniform.

Agent behavior within a class is not uniform. “Send an email” is a class of action containing both “confirm the meeting time” and “forward the customer database to an address that appeared in a prompt injection.” Same tool. Same scope. Same permission. Wildly different actions. A class-level gate is blind to the only distinction that matters.

Scale it up

Ever if this were only a problem for consumer AI, it would still be a problem that needs solving. But it gets so much worse. Replace you with a company, and replace the dialog with a config file.

An enterprise deploying agents has to make this same allow/deny decision. But now they have to make it once—at deployment time. The engineer making the decision isn’t magical. They have to make the same decision you do when the dialog appears. And just like you, they are unable to know what a non-deterministic system will do with the authority. Except now the impact is potentially thousands of actions a day, against customer data, with potential money attached, and without a human overseeing the system as it runs. Suddenly, “always allow” is baked right into the architecture.

A better dialog doesn’t fix this

The knee-jerk reaction might be that the model providers will just build better permission systems—finer-grained scopes, smarter prompts, risk-tiered confirmations. Some of that will happen, and some of it will help at the margins.

But a better dialog is still a structural gate. Narrower classes are still classes. You can subdivide “access the repo” into “read the repo”, “write to the repo” and “open a PR.” But now, you’ve made the product experience worse (more dialogs to respond to) and the same problem reappears anyway.

Making permissions finer-grained doesn’t change the fact that the question still isn’t about whether opening pull requests or sending emails is ok. The question is about whether this particular PR is safe to post or this particular email is safe to send. And the answer depends entirely on what’s inside the PR (or the email), and what the agent was asked to do. None of that is determinable based on the access scope.

Put simply: You cannot enumerate your way out of a semantic problem.

What the right primitive looks like

I promise I’m not just complaining and screaming about the sky falling. I believe this is solvable. And the solution follows logically now that we’ve thought carefully about what questions actually matter.

The solution is to move the decision from provisioning time to action time, and from the class to the instance. Every action an agent takes—every tool call, every argument, every output—gets evaluated in flight, in context, against policy, in the milliseconds before it executes. Not “is this agent allowed to send email,” but “is this email, composed this way, going to this recipient, in the middle of this task, okay?”

That’s the judgment a human would apply if a human could sit behind every action. No human can, which is why the evaluation layer has to be as fast and as automatic as the agents it governs.

There’s a cool side benefit here actually: Once you’re evaluating instances instead of classes, a third option actually becomes possible—one that dialog cannot offer.

Binary gates can only say yes or no, and we’ve already established what people do when those are the choices. Instance-level evaluation can say “yes, but like this.” Instead of allowing or denying, we can rewrite the off-policy tool call, strip the exfiltrated field, cap the refund to its authorized limit, and let the task proceed. The agent actually stays useful. The action stays secure. Nobody had to pick between “allow” and “deny”—and that false choice is what created the impetus for “always allow” in the first place.

“Always allow” is a confession

The “always allow” button is a confession. It’s the architecture admitting, in UI form, that per-action judgment is what’s needed—and that nobody has a way to deliver it yet. So instead, the judgment gets handed to you, once, in advance, about a system whose future behavior nobody can predict.

Agents are about to hold more standing permissions than any workforce in history. The security model that governs them can’t be the one we built for the predictable systems of the past. We need a new AI security model—one that evaluates what an AI is actually doing with the permissions we grant. Every single action, every time, in context.

The era of permission based security ended the moment we authorized the first non-deterministic system. And most of us clicked right past it.