Who should own security decisions for generative AI deployments in the enterprise?

Why This Matters for Security Teams

Generative AI deployments do not fit neatly into a single team’s control plane. They consume secrets, call internal APIs, move data across environments, and can change behaviour as prompts, tools, and integrations change. That means ownership has to sit with the teams that can govern identity, policy, and runtime access together, not with a project sponsor after the system is already in production. The NIST AI 600-1 Generative AI Profile is useful here because it frames AI risk as an operational governance issue, not just a model-quality issue.

NHIMG research shows why this matters now: in AI Agents: The New Attack Surface report, 92% of respondents agreed governing AI agents is critical, yet only 44% had implemented policies to do so. That gap is exactly where enterprise deployments fail, because access decisions, logging, and incident response are often split across security, cloud, and application teams without a single accountable owner. In practice, many security teams encounter over-permissioned GenAI access only after sensitive data has already been exposed or an agent has already acted beyond scope.

How It Works in Practice

Ownership should be organised around decision rights, not titles. Security governance should define the policy baseline, identity and cloud teams should enforce runtime controls, and application or platform owners should carry the operational responsibility for the specific GenAI service. That split works only when the accountable owner can approve access patterns, review exceptions, and trigger containment actions when behaviour changes.

For enterprise GenAI, the practical control set is usually:

• assign a named owner for model, tooling, and data access approvals
• tie each deployment to a workload identity rather than a shared service account
• issue just-in-time secrets with short TTLs for prompts, tools, and API access
• monitor tool calls, data movement, and privilege escalation attempts continuously
• route incidents through the same owner who approved the deployment

This is where identity governance becomes central. NIST SP 800-53 Rev 5 Security and Privacy Controls supports control ownership, access enforcement, and auditability, while Ultimate Guide to NHIs — Why NHI Security Matters Now explains why machine identities need tighter lifecycle control than human accounts. For AI-specific deployments, the NIST AI 600-1 GenAI Profile and NIST AI 600-1 Generative AI Profile both reinforce that governance, measurement, and response need to be embedded into operational workflows, not handled as a one-time review. Where mature programmes go further, they use policy-as-code and runtime authorisation so the same owner can approve intent, not just static access. These controls tend to break down when GenAI is embedded in shadow IT workflows because no single team can see the full chain from prompt to data access to downstream action.

Common Variations and Edge Cases

Tighter ownership often increases coordination overhead, requiring organisations to balance speed against assurance. That tradeoff is real, especially in environments where multiple business units are piloting separate copilots, retrieval layers, or agentic workflows.

Best practice is evolving for frontier use cases. In highly decentralised enterprises, the central security team should not become the day-to-day operator of every deployment, but it must still own the policy framework and escalation path. In regulated environments, legal, privacy, and compliance may need formal sign-off on data use, while cloud and platform teams own technical enforcement. There is no universal standard for this yet, but current guidance suggests one accountable owner per deployment, with shared control execution across adjacent teams.

Edge cases arise when vendors host the model, business teams connect the data, and engineering wires in automation. In those situations, ambiguity around who can approve tool access, rotate secrets, or suspend the agent quickly becomes a breach problem. The safest pattern is a documented RACI that names the decision-maker for access, monitoring, exceptions, and incident response, then tests that ownership during tabletop exercises and access reviews.

Related resources from NHI Mgmt Group

• Why is single-provider AI agent governance not enough for enterprise security?
• How should security teams govern API keys used for generative AI access?
• Who should own secrets security and NHI governance across the enterprise?
• How should organisations use AI governance signals during enterprise procurement for generative AI tools?