Accountability should sit with the teams that own both the AI use case and the underlying data controls. That usually means identity, data governance, and platform teams sharing responsibility for provisioning, review, and enforcement. If ownership is unclear, AI risk becomes everybody’s problem and nobody’s control.
Why This Matters for Security Teams
When models and agents consume enterprise data, accountability is not just about who approved the use case. It also covers who owns the data classification, who grants access, who reviews tool connections, and who can revoke them when behaviour changes. That matters because autonomous and semi-autonomous systems can expand their own reach through prompts, APIs, and chained tools in ways traditional application reviews do not anticipate.
Current guidance from the NIST Cybersecurity Framework 2.0 and the NIST AI Risk Management Framework points toward shared governance, but there is no universal standard for which team should own every control. In practice, that gap often becomes visible only after an agent has already read more data than intended, copied it into a downstream workflow, or used a connected service in an unreviewed way. NHIMG research on non-human identity risk shows why this matters: only 1.5 out of 10 organisations are highly confident in securing NHIs, according to The State of Non-Human Identity Security. In practice, many security teams encounter ownership disputes only after a data exposure or over-privileged integration has already occurred, rather than through intentional governance design.
How It Works in Practice
The cleanest model is to assign accountability by control domain, not by organisational convenience. The team that owns the AI use case should be accountable for business justification, intended behaviour, and acceptable outputs. The data governance team should own data classification, retention, permitted datasets, and downstream sharing rules. Identity and platform teams should own provisioning, credential lifecycle, logging, and enforcement of least privilege. That division aligns with OWASP Agentic AI Top 10 and CSA MAESTRO agentic AI threat modeling framework, both of which emphasise that governance fails when control ownership is ambiguous.
In operational terms, the workflow usually looks like this:
- Define the approved use case, data sources, and prohibited data types before the model or agent is enabled.
- Map each dataset and tool to a named control owner, with explicit approval and revocation authority.
- Issue short-lived credentials or tokens per task rather than relying on broad, standing access.
- Log data access, tool calls, and policy decisions so reviewers can reconstruct what happened.
- Review exceptions regularly, because agent behaviour and connected data paths change faster than annual access reviews.
This approach is most effective when paired with a real-time policy layer that can evaluate context at the moment of access, rather than a static approval matrix. It also benefits from workload identity, because the system needs to know which agent or service is acting, not just which person requested it. NHIMG analysis of agent risk issues in OWASP NHI Top 10 reinforces that these controls should be designed for dynamic behaviour, not only human-like request patterns. These controls tend to break down when legacy data platforms cannot distinguish an approved service account from an over-scoped shared integration because the same credential is reused across multiple pipelines.
Common Variations and Edge Cases
Tighter governance often increases coordination overhead, requiring organisations to balance stronger data protection against slower delivery and more approval points. That tradeoff becomes sharper in federated environments, where data owners sit in one business unit, platform teams sit in another, and the AI product team is measured on speed. Current guidance suggests that shared accountability works best when one team is clearly the system owner and the other teams are named control operators, but there is no universal standard for this yet.
Edge cases often appear when the AI system uses third-party connectors, vendor-managed models, or shared data lakes. In those situations, accountability should extend to the supplier relationship and the integration layer, not stop at the internal application boundary. If the use case spans regulated data, the legal and compliance function may also need formal sign-off on retention, residency, and disclosure limits. For broader NHI lifecycle considerations, Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs and Ultimate Guide to NHIs — Regulatory and Audit Perspectives are useful references.
The biggest failure mode is assuming the model vendor owns governance just because the model is hosted externally. That is rarely true, and it leaves the enterprise exposed when agents inherit permissions from the surrounding workflow. Best practice is evolving toward explicit RACI-style ownership, with the business owner accountable for outcomes and the security, data, and platform teams accountable for the controls that make those outcomes safe.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OC | Governance and roles must be defined when AI uses enterprise data. |
| NIST AI RMF | GOVERN | AI governance requires accountability across model, data, and operations. |
| CSA MAESTRO | MAESTRO stresses control ownership across agentic AI workflows and tools. |
Assign named owners for use case, data, identity, and enforcement controls.
