The foundation: engage.re
AI Agents 30 July 2026 9 min read

What May an AI Agent Touch in Your Systems?

A role describes a job, and an agent has a task. Organisations give agents the permissions they built for staff, because those are the permissions they have. A role assumes a person who applies judgement about what falls outside it, and an agent applies no such judgement. This article explains why a service account is the wrong unit, what a capability gives you instead, and the four rules that decide whether a permission model holds at machine speed.

Connect with us about agent permissions · · Replies within 24 hours

219
scattered permission checks replaced by one gate in a production estate
57,267
narrow grants issued, each naming one action on one scope
1
call, the delay before a cancelled grant stops working

What permissions should an AI agent have?

Exactly the permissions its current task needs, and no more. Each grant should name one action on one defined scope, and it should expire or be revocable at once.

That answer sounds obvious, and almost no estate implements it. The reason is practical. Your systems hold roles, and a role is the only unit available, so the agent receives a role.

Why is a role the wrong unit?

A role encodes a job description. A housing officer may read tenancy records, update a repair, and raise a payment. Those three abilities travel together, because the person needs all three across a working week.

A person also carries a boundary that the role does not state. The officer knows not to read the record of a neighbour, a colleague or a relative. Nothing in the permission model prevents it, and the person does not do it.

An agent holds the same three abilities and none of the boundary. It reads what the task appears to need, and it does that at machine speed.

A role is a permission plus an assumption. The assumption is a person who applies judgement about what falls outside the job. Give the role to software, and you keep the permission and lose the assumption.

Why is a service account worse?

A service account exists to let software run without a person. It usually holds broad permissions, because narrowing it breaks something and nobody knows what.

Three properties make it the wrong home for an agent.

  • It is shared. Several agents and several scripts use it, so your log records the account and the account names nobody.
  • It is broad by design. Its permissions cover every task anybody ever gave it.
  • It is hard to change. Nobody narrows a live service account without a test plan, so the permissions stay as they are.

The Cloud Security Alliance describes the wider problem in a research note on the AI agent governance framework gap, published in April 2026.

What is a capability?

A capability is a grant that states one action on one scope. Read this resident's care plan. Update this repair job. Not a role, and not an account.

Property A role A capability
UnitA job description.One action on one scope.
DurationUntil somebody changes it.The task, or a stated period.
Change over timeIt accumulates.It narrows, and never widens.
WithdrawalA ticket and a deployment.Effective on the next call.
Evidence of useSometimes a log entry.Every use is an event.

Singapore's Model AI Governance Framework for Agentic AI requires each agent to hold a unique identity tied to its supervisor. A capability attaches to that identity, and the two requirements work together. We cover the identity half in your AI agent needs its own identity.

The four rules

A permission model holds at machine speed when four rules apply at the same time.

  1. Narrow at issue. A grant names one action on one scope. A wide grant is a wide grant on the first day, and time never narrows it.
  2. Never widens. An agent may pass on a grant it holds, or a narrower one, and never a broader one. Privilege therefore cannot grow through delegation.
  3. Cancellable now. A cancellation takes effect on the next call, not at the next deployment. An agent acting wrongly at machine speed needs a stop that works in seconds.
  4. Logged on use. Every use of a grant writes an event, and the event joins a record nobody can alter.

Rule two does the quiet work. Where an agent can hand a task to another agent, and grants can widen, your narrow first grant means nothing three hops later.

Where should the decision live?

In one place per domain boundary. The alternative is a check at every point of access, and that alternative fails in a specific way.

A large system accumulates checks. Each one made sense when a developer added it, and the set as a whole then holds no author. Nobody can state your policy, because the policy is spread across hundreds of places, and a change to one does not change the others.

One production estate we work on replaced 219 scattered checks with a single gate. The count is the evidence, and 219 places holding a policy means no place holds it.

The NIST AI Risk Management Framework treats this as a governance function, and the ICO's UK GDPR guidance requires access to personal data to be limited to what a purpose needs.

What ESRE Media offers

We build your system on engage.re, and the four rules are properties of the platform.

  • Every grant is narrow. A grant names one action on one scope, and one production estate on the platform holds 57,267 of them.
  • A grant can never widen. An agent may delegate what it holds, or less, and the platform refuses more.
  • Cancellation is immediate. A cancelled grant stops working on the next call.
  • One gate per domain boundary. One place decides every crossing, so you can state your policy by reading one thing.
  • Every use is an event. Each event joins a signed chain, and each entry carries a hash of the entry before it.

Sense Future built engage.re, and it has run in production since December 2025.

How to test your own estate

  1. Pick one agent and write down everything it may touch. The list is usually longer than anybody expected.
  2. Ask how long a withdrawal takes. Count in seconds, and compare that with how fast the agent acts.
  3. Ask whether an agent can pass on a permission, and whether the passed permission can be broader.
  4. Count the places in your code that decide access. One is right, and hundreds is the usual answer.
  5. Check whether a use leaves a record, or only a failure.

The same problem at two sizes

A council gives an agent the housing officer role so that it can triage repair requests. The role also allows the agent to read tenancy histories and raise payments. Nobody intended that, and the role was the only unit available. A narrow grant for one action on one repair job removes both extra abilities.

A care home group gives an agent access to the care records system so that it can draft shift handovers. The account reaches every resident record in every home. The group runs three systems rather than forty, and the shape of the mistake is the same.

The care home software and security company software pages set out the sector detail. Our guides to lone worker records and the Data Security and Protection Toolkit cover the access obligations that apply either way.

What we do not claim

  • Capabilities do not replace roles for people. A person needs a job description, and a role expresses one well.
  • Narrow permissions do not make an agent correct. They limit the damage of an incorrect one.
  • Retrofitting this is real work. A capability model is a property of a design, and no product adds it to an existing estate for you.

What to do next

  1. List every agent in your estate and the account each one uses.
  2. Find the broadest permission any agent holds, and ask which task needs it.
  3. Time a withdrawal from decision to effect.
  4. Count your access-decision points.
  5. Then decide whether your policy lives in hundreds of places or in one.

Common questions

What permissions should an AI agent have?

Exactly the permissions its current task needs. Each grant should name one action on one defined scope, and it should be revocable at once. An agent that holds a role holds every ability that role carries, including the ones its task does not need.

Why not give an agent a role like a member of staff?

Because a role is a permission plus an assumption. The assumption is a person who applies judgement about what falls outside the job. A housing officer knows not to read a neighbour's record, and nothing in the permission model prevents it. Give the role to software, and you keep the permission and lose the assumption.

What is a capability in access control?

A grant that states one action on one scope, held by a named identity. It lasts for the task rather than indefinitely, it can narrow and never widen, a cancellation takes effect on the next call, and every use writes an event.

Can an agent pass its permissions to another agent?

It should be able to pass on what it holds, or less, and never more. Where delegation can widen a grant, a narrow first grant means nothing three hops later. That single rule decides whether privilege can grow through a chain of agents.

Where should the access decision live?

In one place per domain boundary. A large system accumulates checks, each one sensible when it was added, and the set then holds no author. One estate we work on replaced 219 scattered checks with a single gate. Where 219 places hold a policy, no place holds it.

What does ESRE Media build?

We build your system on engage.re. Every grant names one action on one scope, a grant can never widen through delegation, a cancellation takes effect on the next call, one gate decides every domain crossing, and every use joins a signed event chain.

Connect with us about agent permissions · · Replies within 24 hours

Sources and further reading