The decision should follow the identity behaviour being governed, not the organisational silo. Security owns access boundaries and auditability, privacy owns data use constraints, and platform teams often own the technical control points. The key is shared governance with clear ownership for each layer of the agent lifecycle.
Why This Matters for Security Teams
ai governance does not stay neatly inside one function because the risk surface is split across access control, data handling, and the systems that actually run the workload. Security teams are usually asked to own the identity boundary, privacy teams the use of personal or regulated data, and platform engineering the implementation details. The real challenge is that AI systems, especially agentic workloads, can act with broad technical reach while still appearing like ordinary software. That is why the ownership question should follow the control point, not the org chart.
This is not theoretical. NHIMG’s The 2026 Infrastructure Identity Survey found that 52% of respondents see AI security decision-making power shifting toward platform and infrastructure teams, while 69% of security leaders say identity management must fundamentally shift for agentic AI systems. The pattern is familiar in post-incident reviews: teams discover too late that the boundary between policy, platform, and data governance was never explicitly defined.
How It Works in Practice
Most teams get better outcomes when they separate governance into layers. Security defines who or what can authenticate, what counts as approved access, how exceptions are approved, and how audit evidence is retained. Privacy defines what data the system may process, retain, infer, or expose, especially where personal or sensitive data is involved. Platform engineering then implements the technical control points, such as workload identity, policy enforcement, secrets delivery, logging, and safe rollout patterns.
For AI and agentic systems, the control model should be runtime-based rather than static. The more autonomous the workload, the less useful it is to rely on role assumptions alone. Current guidance suggests treating the agent as a workload identity and evaluating permissions at request time using the task context, data sensitivity, and destination system. That is where frameworks like the NIST AI Risk Management Framework and the NIST Cybersecurity Framework 2.0 help teams translate governance into operational controls.
A practical operating model often includes:
- Security owns identity issuance, least privilege, approval gates, and evidence collection.
- Privacy owns data classification, consent, retention, and purpose limitation.
- Platform engineering owns implementation of policy as code, secrets handling, and runtime enforcement.
- Joint review covers escalation paths, break-glass access, and incident response for autonomous actions.
NHIMG’s Top 10 NHI Issues and Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs are useful references for mapping these responsibilities across the full identity lifecycle, from provisioning through revocation. These controls tend to break down when teams allow platform owners to set policy without security review, because technical convenience quickly outpaces governance discipline.
Common Variations and Edge Cases
Tighter governance often increases coordination overhead, requiring organisations to balance speed against assurance. That tradeoff becomes more visible in teams running fast-moving AI products, regulated data workflows, or infrastructure agents that can make changes autonomously. There is no universal standard for this yet, so the best practice is evolving rather than settled.
In privacy-heavy environments, privacy may take the lead on data approvals while security still owns identity and auditability. In highly regulated industries, legal or risk teams may also need a formal role in approvals. In platform-heavy organisations, the platform team may manage the technical enforcement layer, but that should not mean it owns the policy decision itself. The distinction matters because implementation authority is not the same as governance authority.
One common failure mode is treating AI governance as a model-risk task instead of an access and data-control task. Another is centralising every decision in security, which can slow delivery and cause shadow implementations. A better pattern is shared governance with a RACI-style split and explicit escalation paths. For broader context, NHIMG’s Ultimate Guide to NHIs — Regulatory and Audit Perspectives and the NIST AI 600-1 Generative AI Profile are helpful when teams need to show auditors how governance responsibilities map to actual controls.
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 | Agent autonomy changes access decisions at runtime, not by static role. |
| CSA MAESTRO | GOV-1 | Defines governance separation across AI, security, and platform functions. |
| NIST AI RMF | GOVERN | Maps decision ownership and accountability for AI risk management. |
Assign ownership for policy, implementation, and oversight to different teams.
Related resources from NHI Mgmt Group
- How should teams decide whether AI procurement belongs in security governance review?
- How can security teams tell whether their governance model is semantically sound?
- What do security teams get wrong about AI governance inventories?
- How can security teams tell whether NHI governance is actually working?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 23, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
