AI Agent Permissions: What We Let Agents Do, and What We Kept for People

Letting AI agents use your product sounds like an API project.

Turns out it's mostly a permissions project. And most of that is deciding what an agent should never be allowed to do.

I had to make those calls when we opened Search on Tomorrow Central to agents. An agent can now find your projects, search them and read their statistics. It can upload a catalogue, get a search key and switch Search on. Before any of that went live, we had to sort out AI agent permissions. What can an agent do alone? What needs a person's yes? What stays with people?

Short version: the agent gets the person's permissions and nothing more. It reads on its own, asks before it changes anything, and never deletes. Here's why.

Whose permissions does an AI agent use?

The person's. Never more.

Think of an agent as a person's hands, moving very fast. So it gets the same keys that person has, cut down to what they agreed to share, and nothing on top.

If you can't change your organisation's settings, neither can the agent you connected. If your organisation hasn't switched a product on, the agent can't reach it either. Every request the agent makes is checked the same way a person's is, on our side, every time.

I like this rule because it ends a lot of arguments early. You never have to ask "should the agent be allowed to do this?" in the abstract. The answer always starts with "is the person allowed to?"

We didn't invent this. OWASP calls the opposite excessive agency, and its fix is least privilege. In plain words, act in the user's name, with no more access than the job needs. The MCP authorization spec has the same shape. The client acts for a person, and the person says yes.

What should AI agents be allowed to do without asking?

Read.

Listing your projects. Running a search and looking at the results. Checking which searches found nothing last week. If the person can see it, the agent can see it once they've connected it. Reading breaks nothing.

Reading isn't free of risk, though. Whatever an agent reads is data, even when it looks like an order. A product name that says "ignore your instructions" is still a product name. I wrote about that in tool output is not instruction.

When does an agent need a person's explicit yes?

The moment it changes something.

Uploading a catalogue is a good example. In Search, an upload replaces the whole catalogue in one go. That's the right design for a person who knows what they're uploading. An agent that picked up the wrong file will replace your catalogue just as quickly, and much more politely.

So changing things is a separate permission. It shows up on the consent screen with its own name, and the person can leave it out. It's never hidden inside "connect".

Getting a search key sits in the same group. It's a small action with a long tail, because the key goes on to live on a website.

This is what people mean by human in the loop. The agent does the work, and a person says yes before anything changes.

Why is switching a product on a separate yes?

Because it touches everyone, not just the person asking.

Switching Search on changes the whole organisation. It decides what everyone in it can reach. That's a bigger decision than editing a catalogue.

So we decided switching it on needs its own yes, unticked by default.

A pre-ticked box is a trap with good manners. If a person wants their agent to switch software on for the organisation, they tick it themselves.

What should stay human-only?

Deleting.

There is no delete for an agent in Search. Not with a yes, not with any setting. Removing a project is never an agent's job.

My reason is simple. An agent can be wrong confidently and fast. A person about to delete something usually pauses. An agent doesn't. It will delete the wrong project at the speed of a for loop and report back that the task went well.

Some mistakes you can undo with the next upload. A deletion isn't one of them.

The same thinking applies elsewhere on Tomorrow Central. On the cloud cost side, an agent can price things and read a linked account, but linking a new account needs a human. Anything that hands out new trust, or can't be taken back, stays away from agents.

Can a person take consent back?

At any time. Otherwise it was never really consent.

Saying yes to an agent should never be a one-way door. A person who connected an agent last month, for a job that's finished, should be able to withdraw that access, and the agent should lose it then, not at some later date when a token happens to run out.

Taking a yes back has to be as easy as giving it. If withdrawing consent takes a support ticket, people will stop granting it.

What I'd tell a founder opening their product to agents

Sort every action before you build a single tool. Not by feature. By what happens if it goes wrong.

1. Give the agent the person's permissions, never its own, and never more.
2. Let it read freely. Check every request on your side anyway.
3. Make every change a separate, named yes on the consent screen.
4. Anything that affects the whole organisation gets its own yes, unticked by default.
5. Keep deleting, and anything else you can't undo, away from agents.
6. Make consent easy to withdraw, and make withdrawal take effect straight away.

All of this sits on a bigger idea, the line between what an agent may follow, read, call and change. I wrote it up as the trust boundary model for AI agents.

None of this makes the agent less useful. It does the boring parts fast, and people keep the parts where a mistake hurts. Honestly, that's how I'd start a new hire too.

Frequently asked questions

What permissions should an AI agent get in a product?

The permissions of the person it acts for, cut down to what that person agreed to, and never more. Every request should be checked on the product's side, the same way a person's request is.

What actions should need a person's explicit consent?

Anything that changes something: uploading data, issuing keys, editing settings. Decisions that affect the whole organisation, like switching a product on, should be a separate yes that starts unticked.

Should AI agents be allowed to delete data?

I wouldn't let them. An agent can be wrong confidently and fast, and a deletion can't be undone, so destructive actions stay away from agents.

Can a person revoke an agent's access?

They should be able to, at any time, and the agent should lose access straight away. Withdrawing consent should be as easy as giving it.

Try it

If you're opening your own product to agents, start with the trust boundary model and tool output is not instruction.

If you want to see these rules from the other side, Search runs on Tomorrow Central with a free plan, for people and the agents they connect. Sign up here, see what Search does, or read how agents connect to Tomorrow Central.

If you're curious how the product got here, the story starts with validating it with our first customer.