Who Owns the Bots? Rethinking Governance for Non-Human Identities
Not that long ago, non-human identities (NHIs) were governed by neglect; provisioned manually, tied to a cron job or batch script, maybe mentioned in a change ticket, and rarely touched again. No formal lifecycle, no regular reviews, and certainly no clear ownership. If you remembered to rotate the password once a year, you were ahead of the game.
That kind of ad hoc governance may have been tolerable in the on-prem world, but it doesn’t hold up in today’s environments. NHIs now sit at the heart of everything from cloud orchestration to API transactions. They scale faster than humans, act autonomously, and often outnumber user accounts by orders of magnitude.
Modern systems rely on NHIs—workloads, APIs, containers, data pipelines—to function. They’re created and destroyed in seconds. They make privileged requests across systems. And they rarely show up in traditional access review processes.
So who’s responsible for these identities?
Governance Models for NHIs
One of my colleagues takes a hardline view of NHI governance: every NHI should have a named human owner, just like every user account. It’s a familiar model, and it works, up to a point. But as infrastructure gets more complex, ownership becomes less about people and more about systems. Since I’m not convinced human ownership always works for NHIs, I wanted to dig a bit deeper. This blog post is the result.
Here are five governance models I think exist in the world, sometimes combined, sometimes purely their own thing. These are more my notes on the subject rather than a narrative post; I’d love your feedback as to any models I might have missed.
📩 Want to stay updated? I write about digital identity and related standards—because someone has to keep track of all this! Subscribe to get a notification when new blog posts go live. No spam, just announcements of new posts. [Subscribe here]
Human Stewardship: One Bot, One Human
Core idea: Every NHI is assigned a human owner who is responsible for managing its lifecycle and reviewing its access.
Example:
An integration with a payroll vendor uses a service account in your HR system. That account is assigned to the Payroll Manager, who gets pinged during quarterly access reviews to confirm it’s still needed and appropriately scoped.
Strengths:
- Fits with existing IAM workflows
- Clear accountability
- Easier to audit
Limitations:
- Doesn’t scale for environments with thousands of NHIs
- Owners often approve access by default, without understanding the technical context
- Orphaned NHIs become a problem when owners leave
Functional Ownership: Tied to Role, Not Person
Core idea: Instead of a specific individual, ownership is assigned to a team or function based on operational responsibility.
Example:
Your DevOps team owns a CI/CD pipeline that deploys applications. The workload identity used by that pipeline is assigned to “Platform Engineering” in your IAM system or tagging scheme, not to a specific engineer.
Strengths:
- Reflects how teams work today
- Works well for shared tools or infrastructure
- Reduces the need to reassign identities when staff change
Limitations:
- Diffuses accountability if the team structure is unclear
- Requires coordination when multiple teams interact with the same identity
- Less effective when “function” and “ownership” don’t align
Autonomous Lifecycle: Let the System Handle It
Core idea: NHIs are provisioned and deprovisioned automatically based on policies and runtime conditions—no human or team is directly assigned.
Example:
A containerized function spins up during an event-driven workflow in your payment processing system. It generates a short-lived identity for that execution context, with permissions scoped to the task. When the function completes, the identity is destroyed.
Strengths:
- Extremely scalable
- Limits exposure by minimizing identity lifespan
- Reduces human error
Limitations:
- Requires robust automation and observability
- Tougher to audit, especially for compliance
- Policy misconfigurations can be hard to detect
GitOps Ownership: The Code Is the Owner
Core idea: NHIs are defined in code repositories, and the team that owns the repo is responsible for the identity.
Example:
An engineering team defines workload identities in Kubernetes YAML files managed through Git. Any changes to identity permissions must go through a pull request. The team that maintains the repository is responsible for keeping identities secure and aligned with policy.
Strengths:
- Aligns with DevSecOps and infrastructure-as-code practices
- Makes governance auditable and version-controlled
- Scales with engineering workflows
Limitations:
- Repo ownership doesn’t always reflect operational ownership
- Policies may drift if teams copy or fork configurations
- Developers may overlook security settings unless guardrails are in place
Tag-Driven Governance: Metadata Rules Everything
Core idea: NHIs are governed through tags or labels that define ownership, sensitivity, environment, and other attributes used to drive policy.
Example:
An S3 bucket access role is tagged with env=prod, team=data, and owner=email@example.com. IAM automation tools use those tags to apply access restrictions, retention policies, and monitoring rules. When the owner tag changes, alerts are sent for review.
Strengths:
- Enables scalable policy enforcement
- Supports dynamic environments and multi-cloud deployments
- Works well with automation frameworks like Terraform or Pulumi
Limitations:
- Inconsistent tagging undermines policy enforcement
- Requires disciplined tagging practices across teams
- Can be bypassed if not integrated with enforcement mechanisms
Why NHI Governance Matters
These models aren’t mutually exclusive. Most organizations end up with a mix:
- Human ownership for persistent, high-risk identities
- Functional or Git-based ownership for shared infrastructure
- Automated governance for ephemeral workloads
- Tag-driven policies to tie everything together
That said, there’s a reason I’m researching this: non-human identity governance needs to be more strict than human identity governance. That’s not because machines are less trustworthy: it’s because they’re faster, quieter, and far more prolific. A misconfigured workload identity can do a lot of damage before anyone notices.
Think back to the BeyondTrust breach. A single, static API key—tied to an NHI with no clear governance—led to a major incident. The problem wasn’t just the key. It was the absence of lifecycle controls, automation, and ownership.
Rethinking IAM from the Ground Up
Managing NHIs well doesn’t just reduce risk. It also gives us a roadmap for what modern IAM could look like—automated, policy-driven, and flexible enough to work across platforms.
Standards like SPICE, WIMSE, and SCITT are laying the foundation for better tools and better governance models. But even without those in place, there’s work we can do now:
- Review your NHI inventory
- Assign ownership or implement tag-based policies and be consistent about it
- Identify where automation can reduce standing privilege
- Align NHI access with actual workflows, not ideals
Summary Table: Governance Models for NHIs
| Model | Best For | Watch Out For |
|---|---|---|
| Human Stewardship | Persistent, high-risk service accounts | Doesn’t scale; risk of orphaned identities |
| Functional Ownership | Team-managed infrastructure | Fuzzy boundaries; unclear accountability |
| Autonomous Lifecycle | Ephemeral, event-driven workloads | Auditing and monitoring complexity |
| GitOps Ownership | IaC, DevSecOps environments | Drift between config and reality |
| Tag-Driven Governance | Multi-cloud, large environments | Tag inconsistency; enforcement blind spots |
Want to Go Deeper?
You might also like:
