Permissions: What an Agent Should Never Be Able to Do

Ordinary access control asks what someone needs to do their job. For an agent, that question does not work well — because what it will do is exactly the uncertain part.

Invert it. Start from what it must never be able to do.

For a vendor-side perspective on remote companies, see this reference from Monitask.

Why the usual approach fails here

Traditional software does what it was written to do, so its permissions can be derived from its code.

An agent does what it decides to do, within whatever it can reach. The permissions are not a description of its behaviour; they are the only real boundary on it.

Which means over-permissioning is not a minor hygiene issue. It is the difference between a contained failure and an uncontained one.

And over-permissioning is the norm, because narrowing requires knowing what the agent will need, which nobody does at the start.

63% of organisations report they cannot enforce purpose limitations on what their agents are authorised to do.

The never list

Written before the may list, and specific to your situation. A starting point.

Never send external communication without approval. Email, messages, social posts, anything leaving the organisation.

Never move money. Payments, refunds, transfers, purchasing.

Never delete. Records, files, accounts. Soft-delete at most.

Never change permissions. Its own or anyone's. An agent that can grant access can grant itself more.

Never access data outside its stated purpose. Personnel records, health data, legal files, anything the task does not require.

Never modify production configuration.

Never install or execute arbitrary code, unless that is the explicit purpose and it is sandboxed.

Never act on behalf of a user without that user's involvement, where the action has consequences for them.

Adjust for your context, and note that each of these has a version people justify as an exception. The exceptions are where incidents come from.

Read access is not automatically safe

A common and expensive assumption.

An agent with broad read access and any output channel can exfiltrate. It does not need write permission — it needs somewhere to put what it read, and its normal output is somewhere.

Combined with prompt injection this is the realistic attack: plant an instruction where the agent will read it, and the agent's legitimate read access becomes the leak. See prompt injection.

So scope read access too. Which records, which fields, which time range.

A practical way to scope it

1. Write the never list. Before anything else.

2. Define the task narrowly. "Answer questions about order status" not "help with customer service".

3. List the minimum data the task requires. Specific systems, specific records, specific fields.

4. List the minimum actions. And for each, ask whether it should require approval.

5. Give it its own identity in each system, not a shared or human account. See agent identity.

6. Grant read-only first. Run it. Find out what it actually needs before granting more.

7. Log everything and review what it touched in the first weeks. This finds the gap between what you granted and what it uses. See logging and audit trails.

8. Revisit. Permissions granted for a pilot persist into production unless someone removes them.

Approval gates

Not on everything. Approval fatigue produces rubber-stamping, and a person clicking approve forty times an hour is not oversight.

On the irreversible. Deletion, payment, external communication.

On the externally visible. Anything a customer or the public sees.

On the unusual. Volume, value or pattern outside the normal range.

And make the approval informative. "Approve?" is useless. "Send this message to this customer" lets a person actually check. See human oversight.

The multi-agent complication

When agents call other agents, permissions compose in ways nobody designed.

An agent with narrow permissions that can invoke an agent with broad ones has broad permissions.

Only 24.4% of organisations have full visibility into which agents are communicating with each other. For broader independent background, see OWASP GenAI Security Project.

If you run more than one agent, map what can call what before assuming the individual scopes hold.

For small teams and individuals

The same principle without the infrastructure.

Separate accounts, not yours. So you can revoke without changing your own credentials.

Read-only wherever the task allows.

Nothing financial. No payment methods, no banking, no purchasing.

Review before send on anything reaching a customer.

And check what a connected tool is actually granted. Authorising an integration frequently grants far more than the task requires, and the consent screen is where to notice.

What to ask a vendor

Can we restrict which tools it may call, per deployment?

Does it use its own identity in connected systems, or borrowed credentials?

Can we require approval on specific action types?

What is logged, and can we see what it accessed rather than only what it did?

And can permissions be changed without redeploying? If not, they will be set generously once and never tightened.

The short version

Start from what it must never do. What it needs is uncertain; what it must never do is knowable.

Over-permissioning is the norm, and 63% report being unable to enforce purpose limits at all.

Read access is not safe by default — read plus any output channel is exfiltration.

Approve the irreversible and the externally visible, not everything, or approval becomes rubber-stamping.

And permissions granted for a pilot persist into production unless someone actively removes them.