Should organisations centralise agent, human and workload identity governance?

Why centralised governance works only when identity types stay distinct

Centralising governance is useful because it gives teams one place to define policy, review access, enforce approval paths and trace revocation decisions. The mistake is to centralise by flattening everything into a single account model. Human, workload and agent identities have different lifecycle triggers, proof requirements, delegation patterns and blast-radius profiles, so the shared layer should govern rules, not erase semantics.

That distinction matters for authorisation and audit. A policy engine can apply common standards for least privilege, approvals and evidence retention while still recognising that a person, a service account and an autonomous agent are governed differently at runtime.

The control objective is consistency at the policy layer, not uniformity in how identity is issued, authenticated or retired. For workload identity patterns, SPIFFE workload identity specification is a useful reference point because it separates workload identity from human login concepts and anchors trust in workload attestation.

What centralisation should actually cover

A shared governance model should centralise the decisions that benefit from standardisation: who owns the identity, which approval path applies, what evidence is required, how long access may last, and how revocation is verified. That gives security and platform teams a common operating model without forcing every identity into the same technical shape.

In practice, the shared layer is strongest where policy, audit and revocation need to line up across populations. Human access reviews, workload credential rotation and agent delegation controls can all be managed under one governance umbrella, but each needs its own identity semantics underneath.

This is also where lifecycle control matters. NHIMG’s IAM and IGA Basics and NHI Lifecycle Management Guide both reflect the same operating principle: provisioning, review, rotation and offboarding are easier to govern centrally when the enterprise treats identity as a governed asset rather than an ad hoc implementation detail.

For autonomous software, the same idea applies to delegated authority. Agentic AI Identity Guide is relevant because agent identity is not just another account, it is an actor with ownership, registration, delegation and retirement requirements that need explicit governance.

Why the three identity classes should not be collapsed into one account type

Collapsing the populations into one account type creates bad operational assumptions. Humans can be challenged interactively, workloads often need non-interactive authentication, and agents may act on behalf of another principal or invoke tools with bounded autonomy. If those differences disappear in the governance model, teams lose clarity about proof, delegation, revocation and acceptable runtime behaviour.

The more scalable pattern is a central control plane with distinct identity semantics. That lets an organisation enforce common policy while preserving separate rules for human sign-in, machine authentication, and agent delegation or tool use. It also reduces the chance that one population inherits controls designed for another population and creates hidden privilege or lifecycle gaps.

Where workload identity is part of the picture, Cloud Workload Identity Guide and Guide to SPIFFE and SPIRE show why static credentials and broad shared accounts are poor substitutes for purpose-built workload trust. Where agent behaviour is part of the picture, Human vs Non-Human Identity is useful because it highlights the governance boundary between people, machines and delegated action.

Risk and Threat Considerations

Centralisation becomes risky when it is mistaken for unification. If one account model is forced across humans, workloads and agents, organisations can end up with overbroad permissions, ambiguous ownership, brittle offboarding and poor visibility into who or what actually exercised access.

Failure mechanism: A single governance process is applied to identities with different authentication and delegation semantics, so revocation, review and approval controls are tuned for the wrong actor type and leave residual access in place.

Impact: Attackers or insiders can exploit the weakest identity class, then pivot through shared governance blind spots into service access, agent tool access or privileged runtime actions.

Practitioner Guidance

What to prioritise: centralise the policy engine, the approval workflow and the audit model first. Keep identity issuance, credential format, lifecycle triggers and delegation rules separate for people, workloads and agents so the control plane stays governable without flattening the actors.

What to verify: every identity class should have an owner, a revocation path and a review cadence that matches how it actually operates. If the team cannot tell whether a principal is human, workload or agent at enforcement time, the model is already too generic.

Common mistake: treating “centralised governance” as permission to consolidate accounts. That usually improves reporting while weakening security semantics, which is the wrong trade-off for systems that rely on distinct authentication and authorisation behaviour.

Practitioner takeaway: centralise governance to standardise decisions, not to erase identity differences; the healthiest model is one policy framework with multiple identity semantics underneath.

Related resources from NHI Mgmt Group

• Should organisations compare AI access governance with human IAM or workload identity?
• What is the difference between human identity governance and AI agent governance?
• Why is it important to integrate identity and data governance?
• What is the difference between human IAM controls and NHI governance?