Who should own continuous trust across people, devices, services, and AI agents?

Ownership should sit with identity and security leaders together, because continuous trust spans IAM, fraud prevention, device posture, and runtime policy. The programme should not be split by channel or actor type, since the same trust failure can start with a user, a device, a service, or an agent.

Why This Matters for Security Teams

Continuous trust is not a single control, and it cannot be owned by one silo. When people, devices, services, and AI agents all participate in the same transaction flow, trust decisions depend on identity proofing, device health, session risk, runtime policy, and fraud signals at the same time. Current guidance suggests the ownership question belongs at the intersection of IAM and security operations, not in a channel-specific team charter.

This becomes more urgent as autonomous systems expand the attack surface. NHIMG’s research on AI Agents: The New Attack Surface report notes that 80% of organisations report AI agents have already acted beyond intended scope, while only 44% have implemented any policy to govern them. That is a trust-management problem, not just an AI governance problem. Standards work such as the NIST AI Risk Management Framework and the OWASP Agentic AI Top 10 both point toward shared accountability for runtime decision-making, not static ownership by one control plane.

In practice, many security teams discover ownership gaps only after a trust failure crosses from a user session into a service account or agent workflow, rather than through intentional operating model design.

How It Works in Practice

The most workable model is a shared trust function with clear operational boundaries. Identity leadership typically owns the trust architecture, policy model, and assurance standards, while security leadership owns detection, response, and enforcement. That split matters because continuous trust must evaluate context continuously, not just at login. A person may be trusted on a managed device, a service may be trusted only with a narrow API scope, and an AI agent may be trusted only for one task and one time window.

For agentic systems, static RBAC is usually insufficient because the agent’s actions are goal-driven and dynamic. Best practice is evolving toward intent-aware authorization, ephemeral credentials, and workload identity. In other words, the system should decide at runtime whether an actor can do a specific thing, with full context, rather than assuming yesterday’s role still fits today’s action. The OWASP NHI Top 10 and CSA MAESTRO agentic AI threat modeling framework both reinforce the need to govern identity, credentials, and runtime behaviour together.

• Use device posture, fraud signals, and session risk as inputs to trust decisions.
• Issue short-lived credentials and revoke them automatically when the task ends.
• Prefer workload identity for services and agents so access is tied to what the workload is, not who last configured it.
• Evaluate policy at request time, using context such as location, sensitivity, and recent behaviour.

For implementation detail, many teams anchor workload identity in SPIFFE or short-lived OIDC-based tokens, then use policy-as-code to enforce the trust decision in real time. These controls tend to break down in highly manual environments with fragmented IAM ownership because policy, telemetry, and remediation do not move at the same speed as the actor being evaluated.

Common Variations and Edge Cases

Tighter continuous trust often increases operational overhead, requiring organisations to balance stronger assurance against developer friction and incident response complexity. That tradeoff is especially visible when legacy apps, privileged service accounts, and autonomous agents all share the same backend systems. There is no universal standard for ownership in those mixed environments yet, so current guidance suggests assigning a single accountable executive sponsor and a joint operating model rather than creating separate trust programmes for each actor type.

Edge cases usually appear where trust signals are incomplete. Shared devices, contractor access, unmanaged endpoints, and human-in-the-loop agent approvals can all blur accountability. In those cases, identity teams may control provisioning while security teams control continuous verification, but neither can operate effectively without the other. NHIMG’s LLMjacking: How Attackers Hijack AI Using Compromised NHIs research shows how quickly exposed credentials are abused, which is why ownership must include secret lifecycle control, not just login policy.

In environments with heavy automation, the practical rule is simple: own the trust fabric centrally, delegate enforcement locally, and never let the same team define the policy, issue the credential, and approve the exception without independent review.

Related resources from NHI Mgmt Group

• How should organizations approach the governance of AI agents?
• What breaks when organisations cannot see AI agents across devices and browsers?
• Who should own governance when humans, services, and AI agents all access the same resources?
• How should security teams govern AI agents that move across multiple trust boundaries?