Most enterprise authentication systems can identify a user, service, or workload. Agent systems introduce another layer: software actors that operate inside a workload, receive delegated tasks, and may create more actors.
The first architectural question is not whether existing IAM is obsolete. It is which identity and authority facts are missing when an agent attempts an action.
Workload identity is necessary but incomplete
A workload credential can prove that a request came from an approved service. If several agents share that service, the credential may not distinguish:
- which agent selected the action;
- which user or workflow initiated the task;
- which permissions were delegated;
- whether the delegation is still valid;
- whether a child agent exceeded its parent's authority.
Preserve the enterprise identity layer. Add agent-specific context where policy needs to reason about those distinctions.
Model the chain
An agent action record should connect:
human or system principal → workload → agent → delegated agent → tool action
Each edge should carry a bounded scope and expiration. The effective permission at the end of the chain must be no broader than the intersection of those grants.
Do not rely on a prompt statement such as "you are authorized." Authorization belongs in signed credentials, policy state, or another mechanism outside model generated text.
Design checks
Before moving an agent workflow into production, verify:
- Every acting agent has a stable identifier within the relevant tenant.
- Credentials are isolated across environments and tenants.
- Delegation is explicit, scoped, expiring, and revocable.
- Child agents cannot increase privilege.
- Consequential actions require stronger evidence or approval.
- Denied and allowed decisions carry a traceable parent.
- Revocation and enforcement-point failure have tested behavior.
- Bypass paths are documented rather than counted as covered.
Illustrative scenario
A reporting service hosts an analyst agent and an export agent. Both run inside the same workload, but only the export agent needs permission to create a download. If they share an undifferentiated service credential, policy cannot reliably enforce that distinction.
This is a design scenario, not a customer report.
Enterprise IAM remains the root of trust. Agent identity extends it so runtime policy can answer a narrower question: may this software actor perform this specific action under this delegated authority now?