Agents need identities, not API keys
An agent needs an identifiable actor, explicit authority and bounded credentials. Preserve the delegating person or organisational owner in the action record, and test scope, expiry and revocation before granting access.
Trace the interfaces between applications and records before changing a system.
An agent’s first integration often creates its identity boundary. The credential should represent a defined actor and purpose, with permissions limited to the work it is authorised to perform. Additional access for possible future use expands the consequences of both mistakes and compromise.
A shared service credential can make later investigation difficult. The log may identify the account while omitting the person, task or delegation behind an action. Treat that missing context as a design requirement, rather than expecting investigators to reconstruct it from application traces.
Design agent identity around explicit authority. An API key can authenticate a principal, but a key alone does not explain the delegation, purpose or approval behind a particular action. Preserve those relationships in the receiving system’s authorisation checks and action record.
What a key cannot answer
| A shared key or service account | A delegated agent identity |
|---|---|
| Who initiated this action? The service account | Which person the agent was acting for, carried in the token |
| Was it authorised? It had the permission, so yes | It had the permission the delegating user held, for this task, at that moment |
| What else can it reach? Everything in its scope, indefinitely | What the task needed, until the credential expires |
| Can it be revoked? Yes, and everything using it stops | Yes, for one agent or one delegation, without an outage |
| What was it doing last March? Whatever the logs happen to say | The delegation chain is in the record, because it was in the token |
Check whether an agent’s technical permissions exceed the authority of the requester or scheduled task. A valid credential can still enable an action outside that authority. Token issuance and the receiving service should enforce the boundary, rather than relying on the model to choose permitted operations.
The Cloud Security Alliance’s work on non-human identity and agentic AI governance recommends treating agent identities as managed actors, with lifecycle controls and bounded privileges. This is governance guidance. It does not establish that a particular token design is adequate for an organisation’s systems.
The decision, and when to make it
On whose authority does this agent act?
- Delegated credentials, scoped to that user, expiring with the task. The default for anything reading organisational data. Test that receiving services enforce the delegated scope.
- Its own identity, minimum scope, short-lived, with a named human owner. Batch enrichment, monitoring, reporting. Nobody is waiting, so nothing needs broad access.
- Define separate actors and preserve the authority for each integration. Shared access needs explicit task-level attribution and control.
Delegated access can constrain the information and actions available to an agent acting for a person. It reduces exposure beyond that person’s entitlements, provided the receiving services enforce the scope. It does not prevent prompt injection or an unwanted action within the permitted scope. Consequential operations still need appropriate approval and effect controls.
What to put in place
The third line is the one that pays for itself in the first investigation. When an agent’s action is recorded as the agent, the audit trail ends at a piece of software. When it is recorded as the agent acting for a named person on a named task, the trail continues into the organisation, which is where the accountability was all along.
The unglamorous part
Short-lived credentials, scoped tokens and workload identity provide established mechanisms for this design. Their suitability depends on the services involved and the delegation they can preserve. Review the AI workflow with the identity team before choosing a credential merely because an SDK accepts it.
Agree the actor, authority and revocation requirements with the identity team before production access is granted. Exercise the actual receiving services and inspect their logs. A design diagram that carries a user identity is insufficient if the final tool call drops it.
What this does not tell you
Delegated identity does not stop an agent from doing something wrong. It bounds what wrong looks like, and it makes the record legible afterwards. An agent acting for a user can still take an action that user would not have wanted, and the control for that is the irreversibility classification and the confirmation step, not the credential.
It also does not remove the case for monitoring. Short-lived scoped credentials reduce the blast radius of a compromise. They do not detect one, and an agent behaving anomalously within its legitimate scope is still the hardest thing in this space to see.
Before provisioning the next agent, identify whose authority it exercises and how each receiving service checks it. Require a traceable owner for scheduled work and an explicit delegation for work on a person’s behalf. Test the access boundary and revocation path before treating the integration as ready.