Static IAM cannot express delegated agent authority

Human identity and machine-to-machine delegation describe different authorization problems. Static IAM — RBAC, attribute-based access control, AWS IAM policies — models the former: a user gets assigned a role; that role maps to a policy document. It works when the identity is human because humans stop acting at session boundaries. They leave. Or change their title. Authorization decisions are effectively one-time.

Agents do not stop. They compose actions across boundaries, delegate sub-tasks to other agents, and execute decisions you did not explicitly enumerate at design time. Static IAM cannot express the delegation chains produced by autonomous behavior. A human's delegated authority is written once; an agent's authority emerges continuously through its tool calls.

The five-principle gap

The research on dynamic authorization models identifies this precisely: static RBAC and IAM treat authorization as a fixed mapping — role X gets policy Y — where policies are deployed once and changed infrequently. For agents, who act through tool calls that compose over time, the model's five-principle architecture replaces each of those design-time decisions with runtime-enforced capability tokens.

1. Clauses over roles: The agent's authorization is a signed claim carrying its own operational capabilities — not a static role assigned at deployment. Each token encodes what the agent can do, for how long, and to whom.
2. Delegated chains instead of flat permissions: When an orchestrator delegates to a sub-agent, the delegation carries reduced scope in its signed claim. The subordinate cannot escalate beyond what it was given. Static IAM has no concept of nested delegation.
3. Time-bounded scope: Access tokens expire on schedules you define per-action or per-transaction; revoked authorization does not need policy redeployment — the token simply ceases to validate.
4. Situation-aware enforcement: Context from the operating environment (location, time, data sensitivity) enters every authorization decision. The same request fails differently depending on whether it occurs in a sandbox or against a production database.
5. Behavioral monitoring as part of the chain: Authorization decisions incorporate observed agent behavior at execution time, not just declared capabilities. An unusual tool call pattern invalidates existing scope — monitoring replaces static policy review.

Why this is not optional

The research data reports that over 70 percent of enterprise agent deployments still use static API keys; fewer than 10 percent implement any delegation-chain tracking. This is a compliance failure in regulated environments: audit systems need to answer who acted, on whose behalf, under what authority — and if every action carries the same bearer API key, you have a single identity at the top of every chain without evidence of intermediate hops.

Digital signatures provide the material mechanism. JWT-based capability tokens signed by an orchestrator carry authorization scope, expiration, and target agents; they can be rotated without redeploying IAM policies because the signature remains valid under the same authority chain. The difference from static IAM is operational: delegation happens continuously instead of at configuration time.

The implication for multi-agent systems

An agent's authorization model determines how you audit it in an incident. If the system produces chains through sub-agents and you track only the first-level identity, you know what happened but not who controlled it. Dynamic authorization with scoped delegation chains preserves evidence about the full chain: which orchestrator authorized which action for whose benefit under what scope.

The practical difference: static IAM measures compliance against a configuration file; dynamic authorization produces behavioral audit evidence that is meaningful after the fact. The two answer different questions.