Machine Agency, Human Accountability: Auditing Delegated Access in UK Data Estates

Autonomous and semi-autonomous AI tools do not merely read data at the point of a prompt. They hold credentials, call APIs, retrieve records, write to systems and may trigger downstream actions. In many UK data estates, such identities were created during a proof of value and retained when the tool moved into production. Conventional joiner-mover-leaver processes rarely catch them because there is no joiner and no leaver in the ordinary sense. The audit question is therefore one of delegated identity: who authorised this machine agency, within what data boundary, and on what evidence can the controller demonstrate that the delegation remains lawful and controlled?

The gap in conventional access governance

Joiner-mover-leaver controls are built around people. They assume a named individual, a role, a line manager and a departure date. Agentic AI introduces non-human identities: service principals, OAuth clients, API tokens, integration users, copilot connectors and retrieval indexes. These identities may inherit broad scopes, persist beyond the pilot and act without a human present at the moment of access. In 2026, agentic tools can also chain actions across systems, turning a narrow permission into a broader operational capability.

This is not an argument against using such tools. It is an argument for auditing them as delegated identities with the same discipline applied to privileged human accounts, and with additional evidence where the agent acts at machine speed.

1. Establish named ownership for every delegated identity

Every agent identity should have a named accountable owner, not a team mailbox and not a vendor contact. Ownership should attach to a role and a named individual who can attest to the purpose, scope and continued need for the access. The supporting register should record the agent identifier, business purpose, product or supplier, accountable owner, technical custodian, data domains, approved scopes, approval reference, review date and decommissioning route.

Owner attestation should be obtained at go-live and refreshed at least annually or on material change. For UK GDPR accountability, the register should link to the relevant DPIA, record of processing entry and lawful basis assessment. An agent without a named owner should not be expanded, and should be suspended where the access cannot be justified.

2. Map least privilege to the task, not the tool

The practical test is not whether the tool is capable of broad access, but whether the specific agent needs it. Map each scope to the task it performs. An agent may need read access to five fields in a case management system rather than the entire customer record. It may need to retrieve documents but not write to authoritative records. It may need to summarise but not transmit data externally.

The evidence should include a scope-to-task matrix, written justification, token lifetime, secret storage arrangements and confirmation that administrative scopes have been excluded unless explicitly approved. Reconcile intended scopes against observed API calls. Least privilege is not a one-off design decision; it is a recurring reconciliation between what the agent was permitted to do and what it actually did.

3. Make action logging reconstructable

Logs must allow the organisation to reconstruct what the agent did, on whose behalf, to which data, when and with what outcome. At minimum, record the agent identity, initiating user or trigger, system called, data object or category, action taken, timestamp, correlation identifier and result. Where prompts or outputs contain personal data, logging should be proportionate and governed by retention rules rather than left to vendor defaults.

A useful test is to select a sample transaction and reconstruct it end to end from logs held across the estate. If the organisation cannot explain which agent acted, what it accessed and what followed, the logging is not yet fit for accountability evidence. Logs should be tamper-resistant, retained in line with the retention schedule and available in a readable extract for regulatory or subject access purposes.

4. Test data boundaries with controlled probes

Define the agent’s data boundary in terms of domains, classifications, purposes and jurisdictions. Then test it. Controlled probes can ask the agent to retrieve data outside its approved domain, take a prohibited action or follow an instruction that conflicts with its purpose. The point is not only to test technical refusal, but to verify that the refusal is logged, that the boundary is understood by the business owner and that exceptions are remediated.

Record the test date, expected behaviour, actual behaviour, evidence of refusal or failure, remediation action and retest date. Include supplier subprocessors and cross-border transfers within the boundary assessment. A boundary that exists only in a design document is not a control.

5. Define human approval points in the workflow

Some agent actions should not proceed without human approval. Examples include high-risk decisions, bulk disclosure, writes to authoritative records, external communications and actions with financial or legal effect. The approval framework should set thresholds, identify the approver role, record the approval and define what happens when approval is not given or times out.

Approval must be meaningful rather than a rubber stamp. The approver should see enough context to understand the proposed action and its data implications. Where an agent makes solely automated decisions with legal or similarly significant effects, the organisation should assess Article 22 considerations separately. Approval records should be retained as part of the evidence file.

6. Prove rapid revocation

Every production agent should have a revocation plan that identifies who can disable it, how quickly, and across which components: tokens, sessions, cached credentials, embedded secrets, downstream automations and supplier-side configurations. Test the plan at least quarterly and after major change. Record the date, time to revoke, systems confirmed as disabled, communications issued and any residual access found.

Revocation should be possible without disrupting unrelated services. Where an agent is embedded in a supplier platform, the organisation should confirm the supplier’s disablement process and evidence it. An access control that cannot be withdrawn promptly is not fully controlled.

Assembling the evidence file

The audit should produce a compact evidence file: the agent inventory extract, ownership attestations, scope matrix, log samples, boundary test reports, approval records, revocation test results, change history and links to the DPIA and record of processing. This file should be reviewed by the data governance function and, where appropriate, reported to the audit committee.

Under UK GDPR, the controller must be able to demonstrate compliance with the accountability principle. The ICO is unlikely to be persuaded by an assertion that an agent was ‘just a tool’. The evidence must show that the organisation knew the identity existed, constrained its access, observed its actions, tested its boundaries and could stop it.

Agentic AI does not sit outside existing obligations. It tests whether access governance can see non-human actors clearly. The audit is modest in design but demanding in practice: name the identity, constrain it, observe it, test the boundary, place a human where needed, and prove that revocation works.