What You Should Know Before Clicking “Allow” To AI

I hit "Allow" probably 10–15 times a day. Location, notifications, cookies, whatever it may be. I don't read any of them. I doubt you do either.

Most of the time, not reading it is not a problem when it's your phone asking if the weather app can see where you are. It's a lot less fine when the thing asking is an AI agent that can read your email and send messages as you.

In September of 2025, someone put a package called "postmark-mcp" on npm. It looked like the official tool for Postmark, an email service, but it was actually an unofficial copy. People installed it, gave it permissions to read and send emails for them, and it worked great. Shortly after, an update added a line of code. After that update, every email the agent sent was secretly BCC'd to the attacker.

Nobody really got "hacked", no password stolen, no malware installed. People just clicked "Allow" to connect Postmark.

The more I read about situations like this, the more I think the problem isn't faulty code or bad packages, it's what the "Allow" means when you're giving it to AI.

Permissions Have to Change For AI

Think about how we give permissions on our phone. An app that asks for your camera, lets take Snapchat, for example. You install Snapchat, and you click "Allow." From then on, the app can access the camera whenever it wants, until you remember to go into Settings and turn it off yourself.

This traditional way assumes a few things:

Your trust stays the same. The app that you clicked "Allow" on is the same app you'll have tomorrow.
You know what it's going to do: A camera takes photos.
It only takes orders from you.

AI agents break all three rules.

Agents update and add new tools, packages, and code on the fly. The postmark-mcp was trustworthy right up until the updated version. Agents decide for themselves which tools to use and how they should use them, so you and I can't predict what they'll do with the access you gave them. And most importantly, agents take instructions from anything that they read.

The Problem

The part that concerned me the most was that even if every tool an agent uses or will ever use was perfectly honest and trustworthy, the agent can still be turned against you.

AI models can't accurately and reliably tell the difference between instructions from you and text they happen to be reading. OWASP's new Top 10 Agentic Applications, published in December 2025, puts this as the #1 security risk and calls it "Agent Goal Hijack." If an agent reads a web page, an email, or a shared document containing hidden instructions, it may simply follow them. This is also known as Prompt Injection.

This isn't hypothetical. In 2025, researches found an attack called EchoLeak. One crafted the email, which the victim never had to open, could get Microsoft 365 Copilot to leak confidential emails, logs and files.

When you click "Allow" for an agent, you are trusting every website, email, document, and tool it will ever read, forever.

The Trifecta

Simon Willison gave the clearest explanation I found, he calls it the "lethal trifecta." An agent becomes dangerous when it meets all of these three at once:

Access to private information (inbox, files, databases, etc.)
Exposure to untrusted content (web pages, incoming emails, third-party tools, etc.)
A way to send information out (sending email, making web requests)

Any one of these alone is fine. Two is manageable. All three together means a single malicious sentence hidden in a web page or email can tell your agent to collect your private data and send it to a third-party, and the agent has all it needs at its disposal.

Meta's security team came up with a similar conclusion that they call the "Rule of Two": an agent should have at most two of these three powers in any single session. If it needs all three, a human should be in command.

What I find weird is that our current permissions systems ask "can this agent read your email?" and "can this agent do this…?" as separate yes/no questions. But notice how they don't ask: should it be able to do both in the same task, is it even necessary, while also reading content from strangers?

What Permission Should Mean Instead

My argument is this: For AI agents, permissions should not be a switch that you flip once. It should work like a payment token: issued for one specific action, good only for that action, and useless the moment it's done.

We already solved a version of this problem with money. When you tap your phone to pay, the store never sees your real card number. Your phone sends a stand-in number and a one-time code that only works for that one purchase. If a hacker steals it, they get nothing they can reuse.

Yes, there are drawbacks to this, but in terms of security, isn't it worth exploring?

In practice I am proposing something like this:

Task-scoped: Giving agents read-only access to unread emails for that job, not standing access to send, delete, and forward forever.
Time-limited: When the task is done, the access is gone.
Re-earned on change: If a tool updated, its old approval should not carry over automatically.
Trifecta-aware: The system itself should refuse to let a single task combine all three unless a human explicitly signs off.

This is not just my idea. OWASP's guidance recommends short-lived, task-scoped permissions as a key fix for agent privilege abuse, and coins the term: "Least Agency." Don't give an agent more freedom that it needs to get the job done.

"But people will just click Allow on everything"

If you ask people for permission more often, they stop reading and click "Allow" without a second thought. Remember those annoying cookie banners? More prompts could actually mean less security.

That's why I believe the answer is to build the limits into the system itself. Researchers at Google DeepMind and ETH Zurich have shown this is possible. Their system, CaMeL, doesn't have to train the AI to resist prompt injection. It, instead, :

writes a plan from your request before the agent reads anything untrusted, so nothing it reads later can change the plan
labels every piece of data with where it came from
checks rules before every action. For example, data from your private files can't be sent to an address that came from a random web page.

On a standard benchmark, CaMeL completed 77% of tasks with provable security, compared to 84% for an agent with no defense at all. 7 points in exchange for guarantee. Do you think that it's worth it?

Why Does This Matter?

AI Agents aren't chatbots anymore. They're being connected to inboxes, bank accounts, company databases and code. And almost every one of those connections is being set up with the same "Allow" button.

A lot of these conversations lately have been about kill switches, how to stop an AI AFTER something goes wrong. But that's only half of the pie. A kill switch is about taking power away from an AI. Permission is about how we hand it over in the first place. If we get that part wrong, we're going to need kill switches a lot more often.

References

Incidents

Agent security frameworks

Prompt injection research

Standards and guidance

Token analogy

Apple. Apple Pay Security and Privacy Overview.

Contents

References