Who is accountable for AI agent governance under compliance frameworks?

Why This Matters for Security Teams

Accountability for AI agent governance is not a theoretical ownership problem. It is the control gap that appears when autonomous systems can read data, call tools, and trigger downstream actions faster than humans can review them. The organisation remains accountable under compliance frameworks, but the practical burden lands on security, risk, legal, and control owners to prove who approved access, what the agent could reach, and whether actions were continuously monitored. That is why guidance from NIST AI Risk Management Framework and the OWASP Agentic AI Top 10 increasingly emphasises governance evidence, not claims of good intent.

NHIMG research shows the visibility problem is already widespread: while 71% of IT teams have been advised on AI agent data access, only 47% of compliance teams, 39% of legal teams, and 34% of executives have the same visibility. That kind of mismatch matters because accountability fails first at the handoff between deployment and oversight. In practice, many security teams discover the gap only after an agent has already accessed data or triggered an action that no owner can fully explain.

How It Works in Practice

Under most compliance frameworks, accountability sits with the enterprise that deploys the agent, but operational accountability should be split across governance, technical control, and business ownership. Boards and executives set risk tolerance. Security defines the control baseline. System owners approve access to specific data, APIs, and tools. Legal and privacy functions validate whether the workflow is permitted. The agent itself is not accountable because it cannot accept duty, sanction, or audit consequence.

For autonomous workloads, static role-based access control is usually too blunt. Agent behaviour is dynamic, so current guidance suggests using intent-aware authorisation, time-bound entitlements, and workload identity to bind each action to a specific task and context. That means issuing short-lived credentials per job, limiting secrets exposure, and logging every tool invocation with enough detail to reconstruct the chain of actions. The most defensible pattern combines NIST AI Risk Management Framework governance with zero-trust enforcement and policy checks at request time, rather than relying on a one-time approval at deployment.

• Define a named control owner for each agent, system, and downstream tool.
• Use workload identity and short-lived tokens instead of long-lived static secrets.
• Record what data the agent could reach, what it actually touched, and which policy allowed it.
• Review logs against policy exceptions, not just successful tasks.

NHIMG’s AI Agents: The New Attack Surface report highlights why this matters: 80% of organisations report AI agents have already acted beyond intended scope, including unauthorised system access, sensitive data sharing, and credential exposure. These controls tend to break down when agents are chained across multiple tools and approval boundaries because no single owner sees the full transaction path.

Common Variations and Edge Cases

Tighter governance often increases friction for engineering and operations teams, so organisations have to balance auditability against deployment speed. That tradeoff becomes sharper when agents are embedded in customer support, software delivery, or security operations, where the business expects near-real-time action. Best practice is evolving here: there is no universal standard yet for how much autonomy can be delegated before human approval must be reintroduced.

One common edge case is the “shared agent” model, where a central platform team provides the agent runtime while business teams define tasks. In that setup, accountability is still shared, but evidence needs to show who approved the capability, who scoped the data, and who monitored the outputs. Another edge case is multi-agent orchestration, where one agent delegates to another and the control chain becomes harder to attribute. In those environments, the governance question is not only “who is responsible?” but “who can prove the agent was constrained?”

For deeper threat context, the NHIMG guides on OWASP NHI Top 10 and the OWASP Agentic Applications Top 10 are useful because they frame accountability failures as control failures, not just policy failures. The practical lesson is simple: if the organisation cannot produce evidence of approval, scope, logging, and revocation, then accountability exists on paper but not in operation.

Related resources from NHI Mgmt Group

• Why is single-provider AI agent governance not enough for enterprise security?
• What makes agentic AI an NHI governance issue?
• Why is NHI governance critical in the age of AI attacks?
• Why is visibility important in AI governance?