Design human and non-human identity lifecycles

Protection need

The system must know which actor requested an action, which software subject executed it, whose authority was used, and which resource and action were allowed. Humans and software do not share one safe lifecycle. They need different enrollment, credential, delegation, rotation, revocation, and recovery controls.

Security objectives and requirements

For humans, bind an account to an appropriate proofing and employment or customer lifecycle. Use interactive authenticators and controlled recovery. For services and workloads, bind identity to a deployment authority and runtime, use short-lived automated credentials, and avoid shared human secrets. For devices, bind keys and posture to managed hardware and ownership. For agents, separate the agent instance, model or runtime, sponsoring user or service, delegated authority, tool session, and downstream action.

Require each identity to have one authority, stable identifier, bounded credential, named owner, allowed resources, evidence, and revocation event. A non-human identity must not borrow a permanent human credential.

Security invariants and evidence

• Every action records the executing subject and, when delegated, the originating actor.
• A workload credential is issued only to an approved workload identity in its intended runtime.
• Delegated authority is narrower than or equal to the delegator's authority and is bound to audience, action, and time.
• Terminating the sponsor, workload, device, or agent removes its effective credentials within a measured bound.
• No shared credential prevents attribution to the active identity.

Evidence can include workload attestation, credential issuance and rotation events, delegation records, tool-call decisions, application outcomes, and revocation tests.

Failure cases

Test a copied workload credential outside its runtime. Test a service using a human session. Test an agent that drops the sponsoring user and acts only as a broad service principal. Test a user termination while an agent job continues. Test shared API keys, orphaned service accounts, stale device identity, and a delegated token presented to the wrong audience.

Design tradeoffs and residual risk

Short-lived credentials reduce theft duration but increase issuance dependency. Fine-grained delegation reduces authority but adds policy and evidence complexity. Keeping the human actor supports accountability but can expose personal data in broad logs. Autonomous work can outlive an interactive session, so sponsorship and termination rules must be explicit.

Pomerium boundary

Pomerium can authenticate people through an identity provider and enforce identity-aware policy for protected routes. It can also protect service and agent access patterns described in its documentation. The workload platform, tool server, and application still own runtime identity, downstream permission, delegation semantics, and final action evidence.

Exercise

Choose one workflow in which a user starts an agent that calls a protected tool and the tool calls another service. Draw the user, browser, agent runtime, workload identity, Pomerium route, tool, downstream service, and evidence sinks.

For each hop, record actor, subject, principal, credential, audience, authority, lifetime, revocation event, and evidence. Then remove the user or agent sponsor and measure which actions can continue.

Evaluation checklist

• Does each human, service, workload, device, and agent have a distinct lifecycle owner?
• Are non-human credentials short-lived, audience-bound, and issued to the intended runtime?
• Does delegation preserve the originating actor and narrow the granted authority?
• Can any shared credential or identity collapse destroy attribution?
• Does sponsor or workload termination stop autonomous and downstream actions?
• Can evidence connect the original request to the final application outcome?