The Unbadged Workforce: A Quarterly Access Review for UK AI Agents

Most UK operations teams now run some form of AI assistant. It may draft responses in a shared mailbox, reconcile supplier invoices, triage service-desk tickets or query a CRM on behalf of a sales team. These tools are often introduced as productivity aids, but behind the interface they hold real access: OAuth grants, application permissions, shared-mailbox delegation, API scopes and, in some cases, long-lived credentials. The difficulty is that none of this tends to appear on a standard joiner-mover-leaver report. Agents are not employees, so they do not trigger the usual access review. They are an unbadged workforce with keys to the building.

The answer is not a blanket ban. It is a quarterly discipline that treats agent access as a managed estate: visible, justified, tested and owned. The review below is designed for UK operations leads who need a defensible control without turning the exercise into a six-month programme.

Why agents escape the usual access review

Traditional access reviews start from people. They ask whether a leaver still has an account, whether a mover still needs their old finance system role, and whether a contractor's sponsor has confirmed continued need. Agents bypass that logic. They are created by a business unit, authorised through a consent screen, embedded in a workflow and then left to run. The original sponsor may have changed role, the pilot may have ended, and the agent may still be active.

The permissions are also awkward to see. A Microsoft 365 or Google Workspace administrator can usually list enterprise applications and third-party grants, but agents may also sit inside automation platforms, ticketing tools, finance systems and browser extensions. Shared-mailbox access is frequently granted directly rather than through a group. API keys may be stored in workflow builders or low-code tools. Each of these is a legitimate route to access, and each can drift out of view.

The quarterly review in four moves

1. Build an agent register

Start with a simple register rather than a perfect inventory. Capture the agent name, business function, vendor or internal build, the human sponsor, the systems it reaches, the permissions it holds, the data classifications involved and the date access was last reviewed. Draw from identity-provider app registrations, OAuth consent records, mailbox delegation reports, API gateway logs and the procurement team's software list. Ask each operations function to name any automation that acts on its behalf, including tools bought on a departmental card.

The register should distinguish between assistants that suggest actions and agents that execute them. A copilot that drafts an email is a different risk from an agent that can approve a refund, update a supplier record or move funds. Record that distinction explicitly.

2. Tie every permission to a purpose

For each agent, ask what business outcome requires the access and whether the permission is the minimum needed. Read-only access to a CRM may be justified for a reporting assistant; write access to the same system needs a clearer case. Shared-mailbox access should be limited to the mailboxes the agent actually services. Application permissions that grant access to all users' files deserve particular scrutiny.

Challenge inherited scopes. Many agents are granted broad permissions during a pilot because it is quicker than mapping the smallest viable scope. A quarterly review is the moment to narrow them. Record the purpose in plain English, not just the scope name, so that a later reviewer can test whether the business case still holds.

3. Test revocation and logging

A permission that cannot be revoked quickly is not controlled. Pick a sample of agents each quarter and test revocation in a non-production environment or under a controlled change. Confirm that removing the grant actually stops the agent, that refresh tokens do not quietly restore access, and that the business process fails safely rather than bypassing the control.

Logging matters just as much. If an agent takes an action, the organisation should be able to attribute it to that agent, identify the human sponsor and reconstruct what happened. Check whether the vendor exposes tool-call or action logs, how long they are retained and whether they flow into the organisation's monitoring. An agent that cannot be logged is difficult to defend in an incident review.

4. Name a human owner

Every agent should have a named human owner at management level, not a generic team mailbox. The owner confirms the business purpose, reviews the permission set and signs off continued access each quarter. When that person moves role, ownership must transfer explicitly. This is the simplest defence against the orphaned pilot that quietly becomes permanent infrastructure.

What good evidence looks like

A completed review should produce a dated register, a signed owner confirmation for each agent, a list of permissions removed or narrowed, and a record of revocation and logging tests. Keep the evidence proportionate. A one-page summary per agent is usually enough, provided it shows the purpose, the access, the owner and the test result.

Procurement questions for the next agent

Before buying another assistant, ask vendors how agent identities are created and scoped, whether permissions can be limited to specific mailboxes, records or fields, how revocation works and how quickly it takes effect, what action logs are available and in what format, whether the vendor can notify the buyer of scope changes, and how data is deleted at exit. Ask also whether the agent can be constrained to read-only mode and whether subprocessors receive access.

Contract language that keeps access visible

Contracts should require the supplier to maintain a current description of agent permissions and to notify the buyer before any material expansion of scope. Include audit rights over access logs, a defined revocation process with a service level, data-use restrictions that prevent customer content from training shared models, deletion obligations at termination, and a requirement to cooperate with the buyer's quarterly access review. These clauses are not exotic; they are the agent-era equivalent of standard security schedules.

A control, not a ban

AI agents can be genuinely useful in UK operations, but only if their access is treated with the same seriousness as a human account. A quarterly review does not need to be heavy. It needs to be regular, evidenced and owned. The organisations that get this right will not necessarily have fewer agents; they will know exactly which ones are acting, on whose authority and with what reach.