AI governance should be owned jointly by IAM, security architecture, and risk teams, because traffic control alone does not establish accountable use. The ownership model must cover identity lifecycle, policy enforcement, and audit evidence for both human and non-human actors. If no one owns delegated AI authority, no one can enforce it consistently.
Why This Matters for Security Teams
Traffic control answers where requests may go, but it does not answer who is accountable for granting, scoping, and revoking delegated AI authority. That gap matters because AI systems can chain tools, call APIs, and make changes faster than manual review can keep up. Current guidance suggests governance ownership must sit with the teams that can bind identity, policy, and audit evidence together, not just the team operating network controls.
NHI Management Group has found that the issue is rarely a lack of technical controls alone. It is the absence of an owner who can decide when an AI system should have access, when it should lose it, and how those decisions are proven later. The 2026 Infrastructure Identity Survey reported that 52% of security leaders see AI security decision-making shifting toward platform and infrastructure teams, while only 44% have policies to manage AI agents. That split shows why governance cannot be implied by perimeter tooling.
Frameworks such as the NIST Cybersecurity Framework 2.0 and the NIST AI Risk Management Framework both point toward accountable ownership, not just control deployment. In practice, many security teams encounter delegated AI privilege only after an incident report reveals that no one had explicit authority to constrain it.
How It Works in Practice
Ownership should be split by function, then bound by a single operating model. IAM owns identity lifecycle, issuance, and revocation. Security architecture owns control design, policy enforcement points, and integration with telemetry. Risk or governance teams own acceptable-use rules, escalation thresholds, and evidence requirements. That model is stronger than traffic control alone because it connects the decision to grant access with the proof that access was appropriate.
For AI and agentic workloads, that means governance must follow the identity, not the network path. The most practical pattern is to treat the agent as a workload identity, then issue short-lived credentials only for a specific task. Where possible, use runtime policy evaluation so the system checks context at the moment of action rather than relying on a fixed allowlist. This is consistent with current NIST guidance and with the direction of the NIST AI 600-1 Generative AI Profile, which emphasizes operational controls around AI use rather than abstract approval alone.
Security teams should also anchor governance in lifecycle discipline. NHIMG’s Top 10 NHI Issues and Lifecycle Processes for Managing NHIs both reinforce the same operational point: privileges that are not actively owned, reviewed, and rotated become invisible risk. The control model should therefore include named approvers, time-bound access, logging that captures intent and outcome, and a revocation path that is triggered automatically when the task ends.
These controls tend to break down in highly automated environments where platform teams can deploy agents faster than governance workflows can classify them.
Common Variations and Edge Cases
Tighter ownership often increases operational overhead, requiring organisations to balance speed against accountability. That tradeoff is real, especially where platform engineering teams expect rapid deployment and traditional security review would slow releases. Best practice is evolving, but there is no universal standard yet for whether ai governance should sit inside IAM, security architecture, or a separate AI risk office; the decisive factor is whether the owner can enforce identity policy end to end.
In mature environments, the model may look federated. IAM may own human and machine identity primitives, while platform security owns agent runtime controls and risk owns policy exceptions. In early-stage environments, a single governance council often has to define minimum standards first, then delegate execution. The key edge case is vendor-managed or embedded AI, where traffic control may exist but the organisation does not control the underlying identity issuance. In those cases, governance must focus on contractual evidence, token scoping, and auditability rather than direct administrative control.
Another exception is environments using agents for infrastructure changes. Here, network restrictions alone do not stop misuse because a permitted agent can still execute an unsafe change through an authorised path. That is why the governance question is not whether traffic is filtered, but whether the organisation can prove who approved delegated AI authority and under what conditions. NHIMG’s Regulatory and Audit Perspectives and the NIST AI Risk Management Framework both support that evidence-first approach.
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 | Addresses governance gaps when agents act beyond static traffic controls. |
| CSA MAESTRO | Maps to shared responsibility for agent identity, policy, and oversight. | |
| NIST AI RMF | Supports accountable governance for AI decisions and lifecycle risk. |
Use a federated operating model that binds IAM, platform, and risk into one control plane.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
