Who should be accountable for enforcing access policy across applications, identities, devices, and AI agents?

Accountability should sit with the teams that own identity governance, access policy, and endpoint trust together, usually across IAM, security architecture, and platform operations. If access decisions span applications, devices, and AI agents, fragmented ownership creates gaps. Clear accountability is needed so policy, telemetry, and remediation are aligned across the full access chain.

Why This Matters for Security Teams

Accountability for access policy is not just an org chart question. When applications, identities, devices, and AI agents are governed by different teams, policy drifts into exceptions, telemetry lands in silos, and remediation becomes someone else’s problem. That is how over-permissioned access survives audits and how autonomous systems keep operating after controls were supposed to stop them.

This is especially acute for agentic workloads because access is no longer limited to a person signing in from a managed device. An AI agent can chain tools, reuse tokens, and act outside the original request path. NHIMG research on the AI Agents: The New Attack Surface report shows that 80% of organisations have already seen agents behave beyond intended scope, while only 44% have implemented policies to govern them. That gap is a governance failure, not a tooling issue.

Security teams should treat access policy enforcement as a cross-domain control plane, not a set of isolated approvals. The relevant standards are converging in that direction, with NIST Cybersecurity Framework 2.0 and NIST AI Risk Management Framework both emphasizing coordinated governance, not fragmented ownership. In practice, many security teams encounter access sprawl only after an exception, a leaked token, or an agent misuse event has already expanded the blast radius.

How It Works in Practice

The accountable function is usually a shared control owner model led by identity governance, access policy, and endpoint trust, with security architecture defining the policy standard and platform operations enforcing it in systems. That means one team owns the policy logic, another ensures it is implemented consistently, and both share responsibility for exceptions, telemetry, and revocation. For human access, that often maps to IAM, PAM, and device posture. For autonomous systems, it must also include workload identity and runtime authorization.

For AI agents, static RBAC alone is not enough because the agent’s intent changes from task to task. Current guidance suggests runtime authorization based on what the agent is trying to do, with decisions informed by context such as task, data sensitivity, device trust, and workload identity. That is why many teams pair policy-as-code with ephemeral credentials, short-lived tokens, and explicit approval gates for sensitive actions. Frameworks such as the OWASP Agentic AI Top 10 and CSA MAESTRO agentic AI threat modeling framework both point toward this runtime, context-aware model.

• Define one accountable policy owner for applications, identities, devices, and agents.
• Enforce policy at request time, not only during provisioning or quarterly review.
• Use workload identity to prove what the agent is, then issue just-in-time access for the task.
• Centralize telemetry so access, posture, and agent activity are reviewable together.

NHIMG’s OWASP NHI Top 10 coverage aligns with this operational pattern: the control owner must see both human and non-human access paths as one policy surface. These controls tend to break down in federated environments where business units can grant local exceptions without feeding them back into central policy and revocation workflows.

Common Variations and Edge Cases

Tighter cross-domain control often increases coordination overhead, requiring organisations to balance speed against consistency. That tradeoff is real, especially where product teams need rapid deployment and security teams need auditability. Current guidance suggests the best outcome is a federated model with a single policy standard, not a fully centralized bottleneck.

There is no universal standard for this yet in agent-heavy environments. Some organisations place final accountability with IAM leadership; others assign it to security architecture or a platform trust team. The important point is that accountability must include enforcement authority across all access vectors, not just review authority over human identities. If the team cannot change policy, revoke credentials, or block a device or agent session, it is not actually accountable.

This becomes harder when agents operate across SaaS, internal APIs, and shadow integrations, or when device trust is managed separately from identity lifecycle. The operational lesson from NHIMG research such as CoPhish OAuth Token Theft via Copilot Studio and Moltbook AI agent keys breach is that shared accountability must extend to token lifecycle, approval paths, and revocation speed, otherwise one weak link undermines the whole control chain.

Related resources from NHI Mgmt Group

• How should security teams use enterprise password management to reduce credential sprawl across applications, devices, and AI agents?
• Who should be accountable for governing access across SaaS apps, devices, and AI workflows?
• How should security teams implement policy controls for identities, applications, and devices in a business password management programme?
• Who should be accountable for closing access-trust gaps across BYOD, shadow IT, and unmanaged applications?