Authority Before Autonomy: A Half-Day Access Trial for UK Agent Pilots
Photo: Picture Show Who's Who on the screen 1932. UK magazine., Public domain, via Wikimedia Commons
UK organisations are moving from AI assistants that suggest text to agents that query systems, write records and trigger workflows. That shift changes the governance question. The issue is no longer whether the model gives a plausible answer; it is what the agent can reach when it acts. Before an agent gets production keys, data teams should run a permission rehearsal: a structured half-day in which access is mapped, reduced, tested and scored. The aim is not to certify autonomy. It is to establish whether the organisation can contain the agent if a prompt, a credential or a workflow goes wrong.
Why an access trial is not a model evaluation
A model evaluation asks whether outputs are accurate, grounded and safe. A permission rehearsal asks a narrower and more operational question: what is the blast radius? Agents often inherit service accounts, API tokens and delegated permissions assembled for human users or older integrations. Those identities may carry broad read access, write scopes or the ability to send email, update tickets or move money. In a UK context, the accountability principle under UK GDPR requires the controller to demonstrate compliance. An agent that acts on personal data without an attributable human decision, a clear purpose and a retrievable audit trail weakens that position.
The half-day shape
The rehearsal should involve the data owner, platform or integration engineer, security lead, privacy officer or DPO, and the business process owner. Four sessions of roughly 45 minutes each are enough for a first pass. Use a sandbox or a restricted copy of the data where possible. The output is an evidence pack and a scorecard, not a slide deck.
Session one: map the agent's reach
Start with identities, not prompts. List every account, service principal, token and delegated permission the agent will use. For each, record read, write, send, delete and trigger rights. Then map destinations: internal databases, SaaS tools, email, file shares, payment systems and external APIs. Classify each action as low, medium or high impact. A high-impact action includes sending personal data outside the organisation, changing a customer record, approving a transaction or deleting evidence.
Session two: cut scopes to the task
Compare requested permissions with the minimum needed for the pilot. Split identities by agent and environment: development, test and production should not share a service account. Prefer short-lived credentials and task-specific scopes. Where a high-impact action is unavoidable, insert a human approval gate and record who approved what, when and on what evidence. Remove inherited permissions that belong to a former integration or a broad admin account. This is the least-privilege step, and it is often where the pilot's real cost becomes visible.
Session three: rehearse a bad day
Run scripted scenarios rather than happy paths. Test a prompt injection in a retrieved document, an ambiguous request that could widen a query, a stale permission left after a role change, and a vendor outage during a write. Check whether the agent stops, asks, or proceeds. Confirm that the approval gate cannot be bypassed by rephrasing a prompt. Review the audit trail: can the team reconstruct the agent identity, the instruction, the data touched and the human decision? If the trail depends on a vendor console that the organisation cannot export, record that as a control gap.
Session four: score readiness
Use a simple scorecard with seven dimensions. Score each from 0 to 2, where 0 means absent, 1 means partial and 2 means evidenced and repeatable. The dimensions are identity separation, least-privilege scope, approval gates, audit trail completeness, UK GDPR accountability, rollback and vendor terms. A total below 8 should stop wider access. A score of 8 to 11 supports a conditional pilot with named owners and a review date. A score of 12 or above supports a controlled expansion, provided the evidence is current.
| Dimension | Evidence to request | Score |
|---|---|---|
| Identity separation | Unique agent identity per environment; no shared admin account | 0-2 |
| Least-privilege scope | Scope list mapped to task; high-impact actions removed or gated | 0-2 |
| Approval gates | Named approver, recorded decision, no prompt-only bypass | 0-2 |
| Audit trail | Exportable record of identity, instruction, data and action | 0-2 |
| UK GDPR accountability | Purpose, lawful basis and retention documented for agent actions | 0-2 |
| Rollback | Ability to revoke credentials and reverse writes within an agreed time | 0-2 |
| Vendor terms | Clear allocation of responsibility for agent actions and logs | 0-2 |
Make the rehearsal repeatable
A permission rehearsal is not a one-off procurement exercise. Agents change, scopes drift and staff move. Add the scorecard to change control, review agent access monthly, and re-run the bad-day scenarios after any new integration. Report the score to the data governance forum alongside other access risks. The point is not to slow the pilot down. It is to give UK data leaders a defensible answer when a business sponsor asks whether the agent is ready for wider access. Authority should come before autonomy, and the evidence should be in place before the keys change hands.
