Who should approve access requests when governance spans both data and AI assets?

Why This Matters for Security Teams

When access requests span both data and AI assets, the real risk is not just overprovisioning. It is misrouted accountability. Data owners may understand classification and retention, while AI owners understand model behaviour, prompt sensitivity, and downstream misuse. If one group approves without the other, review becomes a formality rather than a control. Guidance from the NIST Cybersecurity Framework 2.0 and OWASP Non-Human Identity Top 10 both reinforce that governance must map to the actual asset and its risk, not just the requester.

That matters because AI-linked access often looks legitimate at request time while still enabling data exfiltration, model inversion, or unsafe tool use later. NHIMG’s Ultimate Guide to NHIs — Regulatory and Audit Perspectives frames this as an auditability problem as much as an access problem: decision rights must be explicit, reviewable, and consistent across teams. In practice, many security teams encounter approval drift only after a data set has been connected to an AI workflow and the original reviewer cannot explain why access was granted.

How It Works in Practice

The cleanest operating model is shared governance with clear decision ownership. The approver should be the governance owner for the primary risk domain, with mandatory input from the adjacent domain when the request crosses boundaries. For example, a request for training data should be approved by the data owner, with AI governance review if the asset will be used for model tuning, embedding, or agentic retrieval. A request for model output logs or prompt stores should typically involve the AI owner, with data governance review if those logs contain regulated or sensitive information.

This works best when the workflow separates who can decide from who must be consulted. That avoids false bottlenecks while preserving accountability. Current guidance suggests aligning approvals to policy objects rather than org charts, so that classification, purpose, retention, and allowed use are evaluated together. The Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs is useful here because it links access to lifecycle state, not just a one-time ticket.

• Define the primary owner for each asset class: data, model, prompt store, vector index, or agent toolchain.
• Require dual review when access can change both data exposure and model behaviour.
• Use policy-as-code or equivalent rules to enforce approvals consistently at request time.
• Preserve an audit trail that records the asset owner, approver, purpose, and expiry.

For implementation detail, NIST SP 800-53 Rev. 5 security controls support authorization and accountability expectations, while the 2024 ESG Report: Managing Non-Human Identities shows why this discipline matters: breaches involving compromised NHIs are common enough that approval ambiguity becomes a material operational weakness. These controls tend to break down when access is granted through ad hoc exceptions, because exception paths usually skip the second review that cross-domain assets require.

Common Variations and Edge Cases

Tighter approval rules often increase cycle time, so organisations have to balance governance assurance against delivery speed. That tradeoff is real, especially for analytics teams and AI product groups that need frequent access changes. Best practice is evolving, but there is no universal standard for this yet. Some organisations route all requests through a single governance board; others use delegated approvers with mandatory consultation rules. The right answer depends on risk, regulatory exposure, and how tightly data and AI systems are coupled.

Edge cases usually appear when one asset serves multiple purposes. A dataset used for reporting may later feed fine-tuning, or a model access request may indirectly expose protected data through prompts, logs, or retrieval augmentation. In those cases, approval should not be delegated to a single owner who only sees one side of the risk. The practical test is simple: if the request changes both what the asset contains and how it can influence decisions, then the decision should involve both governance domains.

For organisations formalising this model, NHIMG’s Top 10 NHI Issues is a strong reminder that approval design is only one layer of control. The next layer is making sure access expires, is reviewed, and remains tied to a documented purpose. In shared data and AI environments, that is usually the difference between managed oversight and approval theatre.

Related resources from NHI Mgmt Group

• What breaks when reporting access is not scoped in AI-assisted data platforms?
• What should organisations evaluate before allowing AI agents to manage secrets, roles, and access requests?
• How should organisations approach identity governance when business applications, cloud infrastructure, and data access are all converging?
• Who is accountable for protecting PHI when access governance spans multiple healthcare applications?