Non-Human and Agentic AI Identity: Governing What You Cannot Interview
When I co-authored an enterprise security architecture standard for AI applications, the identity domain produced twelve mandatory principles. Almost all of them reduce to one observation: an AI agent is an identity with no employment contract, no manager, and no natural end date - unless you architect one.
Agents are non-human identities with delegation
We have governed non-human identities (NHIs) for years: service accounts, workload identities, API clients. Agentic AI adds a twist - delegation. An agent frequently acts on behalf of a human, which means two identities are in play for every action: the agent’s own identity and the delegated user context. Your access model must evaluate both. An agent should never be able to do more on a user’s behalf than the user could do directly, and usually it should be able to do far less.
Constrained authority chains
Multi-agent systems introduce chains: agent A invokes agent B which calls a tool. Authority must attenuate down the chain, never amplify. In practice that means scoped, short-lived tokens minted per hop, with the full chain recorded in the token or in an auditable side channel. If you cannot answer “which chain of identities caused this write”, you do not have an agentic architecture - you have an incident report waiting for an author.
Lifecycle: joiners, movers, leavers for machines
Apply JML thinking ruthlessly:
- Join - every agent identity is created through a governed process with a named human owner, a business justification, and an assurance tier matched to the sensitivity of the resources it touches.
- Move - when an agent’s purpose changes, its entitlements are re-certified, not accumulated.
- Leave - every agent has an expiry and a decommissioning path. Orphaned agents are the new orphaned service accounts, except they can act.
Cloud-native by mandate
One of the more contentious controls I authored prohibits Kerberos and on-premises Active Directory authentication patterns for AI applications. AI workloads are cloud-native; chaining them to legacy authentication drags Tier 0 exposure into a domain that changes weekly. Platforms such as Entra Agent ID are emerging to give agents first-class directory citizenship - governance should land there, not in a 25-year-old protocol stack.
Federating agents across boundaries
The hard problems arrive when agents cross organisational boundaries. Federated agent identity needs the same rigour we apply to B2B federation: explicit trust establishment, attribute contracts, revocation paths, and no transitive trust by default. Start writing those patterns now - your first cross-organisation agent integration request is closer than you think.
Have an identity challenge worth solving?
I take a small number of freelance and contract engagements each year.