Who should own zero trust policy when access spans users, workloads, and agents?

Why This Matters for Security Teams

When zero trust policy spans users, workloads, and agents, ownership is not a routing question. It is a governance question. The policy has to decide who can act, under what context, and with what proof, across human sign-in, service-to-service calls, and autonomous tool use. If that ownership fragments across infrastructure, app teams, and identity teams, exceptions multiply and enforcement becomes inconsistent.

Current guidance aligns best with NIST SP 800-207 Zero Trust Architecture, which treats policy as centrally defined but dynamically enforced, not improvised at the edge. For non-human identities, the operational stakes are even higher because machine identities often outnumber human identities and are harder to inventory and govern. NHIMG’s Ultimate Guide to NHIs shows why this is not theoretical: poor ownership and visibility are common drivers of exposure.

The practical answer is that identity, IAM, and PAM leaders should own the policy model, while platform teams own implementation guardrails and service integration. In practice, many security teams encounter access policy drift only after exceptions have already been normalized in production.

How It Works in Practice

A workable zero trust operating model separates policy ownership from policy enforcement. Identity and security architecture define the rules for authentication strength, device posture, workload identity, just-in-time elevation, and session constraints. Platform and engineering teams then implement those rules in control planes, proxies, gateways, and workload runtimes.

That split matters because users, workloads, and agents do not share the same trust signals. Human access may rely on strong identity proofing and session risk. Workloads need cryptographic workload identity, such as the patterns described in the SPIFFE workload identity specification. Agents add another layer: authorization must reflect the task, the tool, the data sensitivity, and the current runtime context, not just a standing role.

A practical ownership model usually includes:

• Identity architects defining the policy standard for all subjects.
• IAM teams governing authentication, federation, and entitlement rules.
• PAM teams controlling elevation, approvals, and time-bound access.
• Platform teams enforcing policy in Kubernetes, API gateways, CI/CD, and agent orchestration layers.
• Security governance reviewing exceptions and measuring drift across all three subject types.

For agentic systems, current guidance suggests pairing zero trust with runtime policy evaluation rather than static allow lists. That aligns with the direction of the OWASP Top 10 for Agentic Applications 2026 and NHIMG’s OWASP Agentic Applications Top 10, both of which emphasize dynamic control over autonomous action. These controls tend to break down when each platform team defines its own exception path because policy semantics stop being consistent across environments.

Common Variations and Edge Cases

Tighter ownership often increases coordination overhead, requiring organisations to balance governance consistency against delivery speed. That tradeoff is real, especially in environments with fast-moving platform teams or multiple cloud accounts. Best practice is evolving, but there is no universal standard for whether the central identity team must also approve every exception or only define the policy baseline.

In mature environments, the policy owner sets rules for all subject types, while domain teams request narrowly scoped exceptions with expiry dates and compensating controls. In earlier-stage environments, a federated model can work if it still preserves one policy language and one approval path. The key is that workload and agent access cannot be governed as an afterthought to human IAM.

Agent-heavy and microservice-heavy estates need special care because static RBAC alone cannot capture task intent, ephemeral tool use, or short-lived credentials. That is where JIT access, workload identity, and runtime authorization become part of the same operating model. NHIMG’s Guide to SPIFFE and SPIRE is useful here because it shows how workload identity can become the control point for policy consistency. The right owner is the team that can keep policy coherent across all subjects, not the team closest to the infrastructure toggle.

Related resources from NHI Mgmt Group

• Who should own policy governance for human, NHI, and agent access decisions?
• Who should own authorization governance when policy spans IT, security, and compliance?
• Who should own policy enforcement for AI inference workloads?
• Who should own access decisions when humans, machines, and agents all need different controls?