Agents fit neither IAM model, so the bill lands on per-step tokens and an intent authority

Both of the inherited models break here, and they break in opposite directions.

The human path assumes someone is present to answer a challenge: MFA, SSO, an interactive session ^[1]. An agent grinding through a multi-step workflow has nobody at the keyboard to re-prompt, so any control that depends on a live human response is decorative ^[3]. The service-account path assumes the reverse: a program that does one known thing forever, which is why a static key or an allowlisted IP was tolerable ^[1]. Its blast radius was settled at deployment time. An agent reasoning about which tool to call next has no scope you can write down in advance ^[2], and that is precisely the property that made coarse role-based grants usable and now makes them too broad for the job ^[8].

Then there is the plumbing. Minting a credential per operational step, set to expire in seconds or minutes ^[6], puts the token issuer inline with every tool call an agent makes ^[1]. A workflow with a hundred calls buys a hundred credentials; the issuer's tail latency becomes part of step time and its availability becomes the agent's availability. Token binding and PKCE cover the other half of the problem, replay outside the intended runtime context ^[7].

Intent binding is where the design gets genuinely hard, and the article's own example shows why. "Agent X may read Document Y only if human user Z is the document owner and the active workflow is Data Summarization" ^[9] mixes two unlike kinds of fact. Ownership the platform can look up for itself. The workflow name is an assertion, and if the agent supplies it, the policy engine is accepting evidence from the thing it exists to constrain ^[2]. Someone has to decide which component is authoritative for intent, and that decision, rather than the policy syntax, is the actual control.

Delegation chains repeat the shape one level up. The stated requirement is an immutable, traceable record of who authorized an action and what scope was granted, including when a primary agent spawns sub-agents ^[5]. Cryptographic attestation is meant to anchor it, binding each agent instance to its model version, execution environment and deployment origin ^[4].

Read the source as what it is: a prescription. There are no breach counts, no deployment numbers and no cost figures behind the recommendation, and the supplied text advertises six capabilities but breaks off partway through the fourth ^[4]. The taxonomy still earns its keep, because each item is specific about which old assumption it retires. "Continuous, agent-aware Zero Trust governance" is the wrapper ^[3]; the work underneath is a credential service on the hot path and an intent authority nobody has appointed yet.