Published: Last updated:

Non-Human Identity

Every technical action needs an identity

Every machine, workload, and software agent acts under an identity. When these actors are treated as their own principals, scoped, attributable, and revocable, non-human identity becomes the extension of Identity/SSO and Zero Trust.

Non-human identities are not a side form of user accounts. They carry deployments, interfaces, pipelines, integrations, automation, and increasingly AI agents. The more autonomously these actors operate, the more important the separation between identity, authorisation, and context becomes.

Why non-human identity matters

Non-human identity first answers the question of auditability: which technical actor performed which action? Without its own identity, actions disappear behind shared keys, generic service accounts, or implicit trust between systems. That weakens audits and makes incidents hard to reconstruct.

The second point is least privilege. Every machine, workload, and agent needs only the rights that fit the current task. A build job needs different rights from a production service, a data import different rights from an agent that classifies documents. Shared accounts blur these boundaries and make rights broader than the task requires.

The real cost sits in operations: identities must be provisioned, bound to workloads, and revoked; tokens, keys, and certificates must be rotated and monitored. Every non-human identity needs a named business or technical owner responsible for purpose, permissions, review cycle, rotation, and revocation. Otherwise old tokens and service accounts remain open access. Non-human identity is therefore less a login topic than an operating model for technical actors.

Every technical identity needs at least an owner, purpose, runtime, allowed resources, scopes, rotation rule, and audit trail.

For an association, this means: a knowledge assistant, import script, or website automation gets its own account with clearly limited rights. When the purpose ends, that access is revoked.

The layered model

A resilient architecture separates three layers that are often mixed in daily practice.

  1. Principal: who acts. The principal is the technical actor whose identity is authenticated: machine, workload, service, pipeline, or software agent. This layer answers whether the actor is genuine.
  2. Authorisation: what is allowed. Roles, groups, policies, and scopes determine which resources the principal may use. This layer answers whether the action is allowed.
  3. Context: where and how it ran. Runtime environment, deployment, device, network, time, task, and approval are metadata for decision-making and traceability. This layer answers under which conditions the action happened.

The mistake is to turn deployment location into identity. An identity such as production-importer-eu-west may look practical at first, but it couples the principal to a snapshot of the infrastructure. As soon as the workload moves, replicates, or runs differently, the name no longer fits. Location, environment, and execution mode are attributes. They belong in context, not in identity.

Better: invoice-importer as the stable principal. Environment, region, and deployment live as context attributes in the token, policy, or log.

flowchart LR
    P["Principal<br/>machine, workload, agent"] --> IDP["Identity provider<br/>authentication"]
    IDP --> AUTH["Roles, groups, policies<br/>authorisation"]
    AUTH --> RES["Resources<br/>APIs, data, systems"]
    RES --> LOG["Audit log<br/>action and outcome"]
    CTX["Context metadata<br/>location, runtime, task"] -.-> AUTH
    CTX -.-> LOG

The model keeps identity stable and the decision flexible. The same principal can be evaluated differently under different contexts without inventing a new identity for every location or runtime.

AI agents as principals

AI agents make the topic visible because they do not only read, but execute tasks: edit documents, create tickets, suggest code, prepare commits, or hand work to other actors. Each agent needs its own identity with scoped permissions and traceable access boundaries. Actions therefore remain attributable across documents, commits, tasks, and approvals.

This attribution does not replace human accountability. In a RASCI matrix, an agent can be Responsible, Consulted, or Informed: it performs work, supplies context, or receives updates. Accountable remains a named human role. Only a human can answer for outcome, approval, and risk.

In practice this leads to simple rules: no shared agent account, no blanket admin rights, no long-lived secrets without rotation, no action without a log trail. Agents are treated like other technical principals, but watched more closely because of their depth of action.

References

Related topics

Ask AI

These links open external AI services, the conversation and its content are sent to their providers.