The CDO defines what the data is, how sensitive it is, and why it matters to the business. The CISO defines who and what can access it, how access is controlled, and how misuse is detected. In AI programmes, those responsibilities overlap so heavily that separate governance paths usually create friction without reducing risk.
Why This Matters for Security Teams
The CDO and CISO split sounds tidy on paper, but ai governance turns that split into a coordination problem. Data leaders are accountable for classification, lineage, retention, and business meaning. Security leaders are accountable for access, misuse detection, and containment. When AI systems consume data, generate outputs, and trigger actions, those boundaries blur fast, especially if the programme includes agents that can chain tools, request permissions, or act without human review.
That is why the practical question is less “who owns AI?” and more “who owns the control path from data to decision to action?” Current guidance from NIST AI Risk Management Framework and Ultimate Guide to NHIs — Regulatory and Audit Perspectives both point toward shared accountability, not siloed ownership. The CDO should define what data may be used, for what purpose, and under what sensitivity constraints. The CISO should define the identity, access, monitoring, and revocation model that prevents the AI from exceeding that purpose.
In practice, many security teams encounter entitlement sprawl, weak auditability, and agent misuse only after a data exposure or unsafe autonomous action has already occurred, rather than through intentional governance design.
How It Works in Practice
In a mature AI governance model, the CDO and CISO operate as complementary control owners. The CDO sets the data policy: which datasets are approved, whether personal or regulated data can be used, how retention works, and which business use cases are allowed. The CISO translates that policy into enforceable access control, telemetry, and response: identity binding, approval workflows, monitoring, anomaly detection, and revocation when the AI no longer needs access.
For agentic systems, the technical pattern usually shifts away from static role-based access and toward task-bound access. That means just-in-time credentials, short-lived secrets, workload identity, and runtime policy checks. The right question is not whether the agent belongs to a role forever, but whether it can prove what it is, what it is trying to do, and whether that action is permitted right now. The identity model becomes part of the control plane, not an afterthought.
- Use data classification to define what an AI can see, then enforce that with identity-aware policy.
- Prefer short-lived credentials and ephemeral secrets over standing access for autonomous workloads.
- Bind the agent to a workload identity and evaluate each request at runtime, rather than trusting pre-approved roles alone.
- Log the data source, model action, tool call, and downstream effect so audit teams can reconstruct the full chain.
This aligns with the direction in NIST Cybersecurity Framework 2.0 and with NHIMG guidance in Top 10 NHI Issues, especially where over-privileged AI systems are granted access far beyond what a human operator would receive. Those controls tend to break down when AI agents are embedded in fast-moving engineering environments with shared service accounts, because the organisation cannot reliably separate human, workload, and agent activity.
Common Variations and Edge Cases
Tighter access control often increases operational overhead, requiring organisations to balance risk reduction against delivery speed. That tradeoff becomes sharper when the AI programme supports analytics, customer service, and software engineering at the same time, because each use case may have different data sensitivity and response latency needs.
There is no universal standard for splitting CDO and CISO responsibility in AI governance yet. Current guidance suggests three common patterns. In the first, the CDO owns data eligibility and the CISO owns access enforcement, with a joint approval board for higher-risk use cases. In the second, a central AI governance lead coordinates both functions to avoid policy gaps. In the third, highly regulated environments keep the split but require formal evidence of policy alignment, often drawing on NIST AI 600-1 Generative AI Profile and Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs.
The edge case most teams miss is autonomous behaviour. Once an AI agent can decide its own sequence of tool calls, role-based governance becomes less reliable because the access path is dynamic. In those environments, the CDO cannot just label the data, and the CISO cannot just approve a role. They need a shared control model for intent-based authorisation, ephemeral access, and continuous monitoring. The guidance is evolving here, but the direction is clear: if the system can act on its own, governance must be able to constrain it at runtime, not just at design time.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A1 | Autonomous agents need runtime controls beyond static roles. |
| CSA MAESTRO | Defines governance patterns for securing multi-agent and AI workflows. | |
| NIST AI RMF | AI RMF frames governance accountability across data and security ownership. |
Use MAESTRO to map shared CDO/CISO controls across agent identity, policy, and monitoring.
