Who Signs the Agent's Passport? Governing Non-Human Identities Before They Touch Production

The workforce that never clocks off

UK organisations have spent the past few years tightening identity controls around people. Multi-factor authentication, joiner-mover-leaver processes and periodic access reviews are now routine in many enterprises. The next wave of identities does not fit that mould. AI agents now schedule meetings, raise and triage tickets, commit code, query knowledge bases and interact with supplier portals. They do not resign, forget a password or notice that a request looks unusual. They act at machine speed, often inside workflows that were designed for human judgement.

That creates a governance gap. An agent may be created by one team, authorised by another and monitored by nobody. It may inherit a password, an API key or an OAuth token that outlives the task it was created for. In zero-trust terms, this is not an AI problem. It is an identity problem with an AI accelerant.

Why conventional identity practice is a poor fit

Traditional identity and access management assumes a human principal with a role, a manager and a periodic recertification cycle. Agents break each assumption. Their permissions drift as prompts and tools change. Their useful life may be minutes rather than months. They may act on behalf of a person, a team or a business process, which makes accountability difficult to reconstruct after the fact.

The familiar shortcuts are tempting: a shared service account, a long-lived API key, a broad role that covers every tool the agent might need. Each shortcut enlarges the blast radius. If an agent is compromised, or simply misconfigured, the attacker inherits whatever the agent can reach. The zero-trust response is to treat every agent as its own principal, with its own passport, its own purpose and its own limits.

Control one: scoped permissions with an explicit purpose

An agent passport should record who owns it, what business outcome it serves, which systems it may call, which data classes it may read or write, and when its authority expires. Permissions should be narrow enough that a compromised agent cannot pivot into adjacent systems. Read access should not imply write access. Access to a ticketing platform should not imply access to the supplier portal behind it.

This is least privilege applied to a non-human worker, but it is also an audit artefact. In the UK, the accountability principle under UK GDPR and the Data Protection Act 2018 makes it important to show why an agent had access to personal data and who authorised that access. A broad role named after a team is unlikely to satisfy that test.

Control two: short-lived credentials and continuous attestation

Long-lived secrets are the weak point in many agent deployments. A token issued once and pasted into a configuration file becomes a permanent key to the estate. A stronger pattern is to issue credentials at runtime, bind them to the workload identity and expire them quickly. Workload identity federation, mutual TLS and short-lived OAuth tokens are not exotic; they are becoming the baseline for cloud-native systems.

Short life is not enough on its own. Credential issuance should be a policy decision, not a provisioning afterthought. The issuing system should check the agent's declared purpose, the environment it is running in and whether its owner still exists. Revocation should be immediate and testable. If an agent is retired, its credentials should die with it, not linger in a secrets vault until the next audit.

Control three: delegated authority with a paper trail

Agents often act on behalf of a person or a team. That delegation needs to be explicit. Which human principal authorised the agent to act? What was the scope of that authority? Was consent recorded? Can the organisation reconstruct the chain of delegation when a decision is challenged?

A useful test is to imagine a regulator or an internal auditor asking who approved a particular supplier change, data export or production deployment. If the answer is 'the agent did it', the control has failed. The answer should identify the human or role that delegated the authority, the policy that constrained it and the log entries that show what happened. Delegation without a paper trail is not autonomy; it is unaccounted authority.

Control four: human approval gates for consequential actions

Not every agent action needs a human in the loop. That would defeat the purpose of automation and create approval fatigue. But consequential actions need gates. Payments above a threshold, production changes, supplier onboarding, bulk data exports and security configuration changes should require human approval or a second automated control that is independently auditable.

A tiered model works well. Low-risk actions can run automatically with logging. Medium-risk actions can proceed with notification and a short reversal window. High-risk actions should pause for explicit approval, with a named approver and a recorded rationale. Break-glass access should exist, but it should be rare, time-bound and reviewed.

Evidence UK regulators will expect

For UK organisations, the audit question is rarely 'do you have an AI policy?' It is 'can you show who authorised this agent, what it could reach, what it did and how you would stop it?' Financial services firms will recognise the language of operational resilience and critical third-party oversight. Public sector bodies will think about data protection impact assessments and records of processing. All organisations should expect scrutiny under UK GDPR, the Data Protection Act 2018 and NCSC guidance on zero-trust design and secure AI adoption.

Practical evidence includes an inventory of non-human identities, policy decision logs, credential lifetimes, approval records, revocation tests and post-incident reviews. The inventory is often the hardest part. Many enterprises do not know how many agents exist, which teams own them or which credentials they hold.

A sensible starting sequence

Begin with discovery, not procurement. Inventory the agents already running in calendars, ticketing, code repositories and supplier portals. Classify them by business criticality and data sensitivity. Eliminate shared accounts and long-lived keys where possible. Introduce short-lived credentials for new deployments first, then retire the worst legacy cases. Add approval gates for the highest-risk actions and rehearse revocation. Finally, test the audit trail with a tabletop exercise: pick an agent, trace its authority and prove you could stop it within a defined time.

The point of zero trust for AI workers is not to distrust automation. It is to make automation governable. An agent without a passport is not a productivity tool; it is an unmanaged identity with a login.