How should organisations design identity for AI agents that act on behalf of users across many services?

Organisations should treat AI agents as delegated actors that need verifiable identity, scoped permissions, and a clear accountability chain back to the human user. The practical goal is not just authentication, but controlled authorization, entitlement checks, and auditable delegation across every service the agent touches. Without that foundation, agents become powerful consumers with no trustworthy policy boundary.

When an AI agent acts on behalf of a user across many services, the identity problem shifts from simple authentication to delegated authority. The agent needs to prove who it is acting for, what it may do, and how far that authority extends in each service. That makes entitlement design, policy enforcement, and auditability more important than any single sign-in event. The Ultimate Guide to NHIs is useful here because it shows how machine identities become a control plane issue once access is distributed across systems.

The practical failure is treating the agent like a human user with a stronger password or a longer-lived token. Agents do not behave like users: they can chain tasks, call many APIs quickly, and reuse trust across services in ways that are hard to anticipate at design time. Identity for this pattern must therefore include delegation context, bounded consent, and a revocation path that works even after the original session has ended. Current guidance suggests that the real boundary is not the model prompt, but the combination of workload identity, policy, and service-side authorization checks.

In practice, teams usually discover the gap only after an agent has already accumulated broad access across systems that were never designed to recognise delegated machine behaviour.

How Delegated Agent Identity Should Work in Practice

A workable design starts by giving each agent its own workload identity rather than borrowing a human account. That identity should be tied to a specific user delegation, a specific task scope, and a specific time window. Short-lived credentials are preferable to static secrets because they reduce the blast radius if an agent session is replayed, intercepted, or overextended. The agent should authenticate separately from the human, but authorization should still reflect the human’s approved intent and the service’s own policy checks.

In this model, the agent is not trusted because it is intelligent. It is trusted only to the extent that it can present verifiable identity, a constrained token, and an auditable chain of delegation. Services should evaluate access at request time, not assume that a one-time approval covers every downstream action. That usually means combining just-in-time entitlements, explicit per-service consent, and logging that preserves who initiated the delegation, what the agent attempted, and what was actually approved.

The strongest control pattern is to separate identity, authorization, and execution:

Identity proves the agent is the delegated workload, not an unverified tool invocation.
Authorization limits which services, actions, and data classes the agent may touch.
Execution boundaries ensure the agent cannot silently widen scope by chaining from one service to another.

This is also where agent identity differs from ordinary app integration. Many integrations rely on a fixed service account, but agentic systems need dynamic authority because the same agent may be safe for one workflow and excessive for another. The OWASP Agentic AI Top 10 captures why prompt injection, tool misuse, and excessive autonomy become identity problems as soon as the agent can act beyond a single boundary.

Organisations that want stronger governance should also define revocation as a first-class function: if the user withdraws consent, the agent should lose both its active session and any downstream service grants derived from that session. These controls tend to break down when services accept delegated tokens but do not verify the original user context on each call, because authority then persists long after the business need has ended.

Where Agent Identity Design Breaks Down

Tighter delegation often increases integration overhead, so organisations have to balance usability against the need to preserve a clear authority chain. The hardest edge case is cross-service orchestration, where one agent performs a sequence of small actions that are individually low risk but collectively high impact. In that setting, coarse permissions or shared tokens can make the agent effectively indistinguishable from a privileged operator.

Another common issue is inconsistent service support. Some platforms can evaluate contextual policy and short-lived credentials cleanly; others only accept long-lived API keys or broad OAuth grants. Best practice is evolving, but the design principle is clear: if a service cannot enforce per-action or per-session constraints, it should not receive unconstrained agent access. The same caution applies when organisations try to reuse human authentication flows for agents, because that often hides delegation failures inside familiar login infrastructure.

The most useful design decisions usually come down to three questions: whether the agent has its own identity, whether each service can validate the delegation context, and whether revocation is immediate enough to matter operationally. One relevant external reference is the NIST AI Risk Management Framework, which helps organisations reason about governance, accountability, and trust in AI-enabled systems.

If those answers are weak, the model may still function, but the identity layer will not be able to explain or constrain what the agent did once it starts combining access across many services.

Risk and Threat Considerations

AI agents that hold delegated authority create a concentration risk: one compromised or over-scoped agent can reach multiple services through a single trust path. The main exposure is not just unauthorized login, but trust abuse, token replay, excessive privilege, and weak revocation of delegated access.

Failure mechanism: Attackers or malicious prompts can exploit over-broad grants, stolen short-lived tokens, or services that fail to re-check user context, turning the agent into a bridge between otherwise separate systems.

Impact: A single agent session can expose data, trigger transactions, modify records, or propagate access far beyond the original user intent, making containment and forensic attribution much harder.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Agentic AI Top 10, CSA MAESTRO and MITRE ATT&CK address the attack and risk surface, while NIST AI RMF, NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
OWASP Agentic AI Top 10	A1 — Agentic Access Control	AI agents acting for users need constrained delegated authority across tools and services.
	A3 — Prompt Injection	Agent identity can be abused when prompts redirect an authorised agent into unsafe actions.
Recommendation — Enforce per-tool authorization and deny broad autonomous access by default. Validate agent inputs and isolate tool execution from untrusted instructions.
CSA MAESTRO	GOVERN — Governance and Oversight	Agent identity design depends on accountability, consent, and oversight across delegated actions.
Recommendation — Define ownership, approval, and review for every delegated agent workflow.
NIST AI RMF	GOVERN-1 — Map and Govern AI Systems	Delegated agent identity is an AI governance issue requiring accountability and policy control.
Recommendation — Map agent roles, approvals, and escalation paths before enabling service access.
NIST CSF 2.0	PR.AA-01 — Identity and Access Management	Agents need managed identity, authentication, and authorization separate from human users.
	PR.DS-01 — Data-at-Rest Protection	Delegated agents often access sensitive data across services, requiring scoped handling.
Recommendation — Assign distinct agent identities and enforce least-privilege access controls. Limit agent data access to approved datasets and protect sensitive records in transit and storage.
CIS Controls v8	6 — Access Control Management	Agent permissions must be provisioned, reviewed, and revoked like other privileged access.
Recommendation — Centralise agent entitlement review and revoke unused or excessive access quickly.

Practitioner Guidance

What to prioritise: Design the agent identity model around the smallest delegable unit of work, not around the convenience of a shared login. If an agent must touch finance, messaging, and storage, do not give it one broad token; define separate scopes and service-specific policy checks.

What to verify: Confirm that every downstream service can validate both the agent’s workload identity and the user’s delegation context before it honours an action. If a platform cannot do that, treat it as a high-risk integration and constrain it accordingly.

Decision rule: If revocation cannot reliably cut off already-issued delegated access, the design is too permissive for agentic use. The control is not working unless the organisation can remove authority quickly enough to matter during misuse, error, or session theft.

Practitioner takeaway: The central design challenge is not making AI agents authenticated; it is making their authority narrow, inspectable, and reversible at every service boundary.