Who is accountable for setting policy around GenAI tools and AI agents in the enterprise?

Accountability should sit with security and governance leaders working alongside application, identity, and business owners. They must define acceptable use, review identity access to sensitive systems, and set enforcement thresholds that reflect risk. Clear ownership matters because AI usage cuts across user behavior, data protection, SaaS access, and third-party integrations.

Why This Matters for Security Teams

Accountability for GenAI tools and AI agents cannot sit in a single department because these systems cut across identity, data, application, and third-party risk. The practical issue is not just whether a tool is approved, but who owns the policy decisions that determine what it can touch, when it can act, and how misuse is detected. Guidance from the NIST AI Risk Management Framework and the OWASP Agentic AI Top 10 both point toward governance that is risk-based, documented, and continuously enforced rather than improvised by individual teams.

This matters because GenAI policy failures usually show up as shadow AI use, over-permissive SaaS integrations, and unclear exception handling. When ownership is vague, application teams may allow a model to call tools, identity teams may approve access without understanding the business workflow, and security teams may discover the gap only after data leaves an approved boundary. NHIMG research on AI Agents: The New Attack Surface report shows that 92% agree governing AI agents is critical, yet only 44% have implemented any policies to do so. In practice, many security teams encounter policy gaps only after an agent has already touched production data or automated an action nobody explicitly approved.

How It Works in Practice

Effective accountability is usually split by control domain, with a named policy owner for each layer and one executive-level accountable sponsor to resolve conflicts. Security and governance leaders typically own the baseline policy, but application owners define the use case, identity owners define how access is issued, and business owners approve the intended outcomes and acceptable risk. That structure matters because policy for GenAI tools is not just an IT usage rule. It must cover data classification, prompt handling, model and plugin approvals, service-to-service authentication, logging, and the circumstances under which an agent may act without human review.

For agentic systems, current guidance suggests moving from static approval lists to runtime control points. That means policy-as-code, explicit workflow approval, and enforcement tied to workload identity rather than user convenience. The operational pattern is to require a documented business purpose, define what data the agent may read or write, constrain tool access, and set thresholds for JIT elevation or step-up review. Resources such as the CSA MAESTRO agentic AI threat modeling framework and NHIMG’s OWASP Agentic Applications Top 10 are useful because they translate that accountability into control objectives, not just policy language.

A practical policy stack usually includes:

• A central GenAI policy that defines approved use, prohibited data, escalation paths, and exception ownership.
• Business-owned use cases that specify what the agent is allowed to do and what “success” means.
• Identity controls that bind each agent to a workload identity and short-lived access tokens.
• Security review for integrations, connectors, and any path that reaches sensitive systems or secrets.

That model aligns with the governance intent in the NIST Cybersecurity Framework 2.0, which expects clear ownership for protecting, detecting, and responding across the enterprise. These controls tend to break down when a GenAI deployment is embedded inside a fast-moving product team because ownership becomes fragmented across procurement, engineering, and operations.

Common Variations and Edge Cases

Tighter AI governance often increases workflow friction, requiring organisations to balance speed of adoption against review depth and operational overhead. That tradeoff becomes sharper when an agent is embedded in customer support, software delivery, or finance workflows, where a delay in approval can feel like a business blocker. The best practice is evolving, but there is no universal standard for this yet: some enterprises place policy ownership in security, while others use a shared governance board with legal, privacy, and business sign-off.

Edge cases usually involve delegated ownership. A low-risk internal chatbot may be governed by the application owner with security oversight, while a high-risk agent that can retrieve records, trigger transactions, or call external APIs should have formal security and identity approval before launch. Another common exception is vendor-managed GenAI, where the business owner still needs to be accountable for the use case even if a SaaS provider hosts the model. NHIMG’s Ultimate Guide to NHIs is relevant here because it frames non-human access as an identity governance problem, not only a software procurement problem.

For teams formalising accountability, the emerging pattern is simple: one owner defines policy, one owner approves the business use, and one owner enforces identity and logging controls. When any of those roles is missing, accountability becomes symbolic rather than actionable.

Related resources from NHI Mgmt Group

• Who is accountable for secure authorization when AI agents and MCP servers start accessing enterprise data?
• Who should be accountable for enforcing access policy across applications, identities, devices, and AI agents?
• How should security teams use enterprise password management to reduce credential sprawl across applications, devices, and AI agents?
• Who should be accountable for NHI governance when applications, pipelines, and AI agents all use credentials?