Who should own AI governance when agents connect to production systems?

Why This Matters for Security Teams

When agents connect to production systems, the ownership question is really about who can approve, constrain, observe, and revoke machine action before it becomes business action. That is why current guidance is shifting away from “who owns the bot” toward who owns the workflow, the data, and the blast radius. The risk is not just access, but autonomous execution with tool use, secrets, and the ability to chain actions across systems. NIST’s NIST AI Risk Management Framework and the OWASP Top 10 for Agentic Applications 2026 both point toward governance, not just authentication, as the control plane for autonomous systems. NHIMG research shows why this matters: in the The 2026 Infrastructure Identity Survey, 70% of organisations grant AI systems more access than a human employee doing the same job, and least-privileged AI access correlates with far fewer incidents. In practice, many security teams encounter agent overreach only after a production change, data exposure, or failed rollback has already occurred, rather than through intentional governance.

How It Works in Practice

The practical ownership model is shared, but not diffuse. The business or platform team that depends on the agent should own the use case, while IAM, security architecture, and the application owner jointly define the controls that bound it. That means a named owner for every agent, a defined approval path for every production permission, and a revocation path that works without waiting for the model to “stop using” access. For autonomous workloads, static role-based access is usually too blunt. An agent’s actions are goal-driven and context-dependent, so the better pattern is intent-based authorisation at request time, with policy evaluated against the task, the target system, the time window, and the confidence or risk level of the action. The emerging best practice is to combine CSA MAESTRO agentic AI threat modeling framework with NIST Cybersecurity Framework 2.0 so the organisation can map owner, control, and monitoring responsibilities to a real system boundary. Typical controls include:

• Workload identity for the agent, not shared human credentials
• JIT credentials with short TTLs for each task or session
• Ephemeral secrets instead of long-lived static tokens
• Policy-as-code for real-time allow, deny, or step-up decisions
• Action logging that records who approved the scope and who can revoke it

NHIMG’s OWASP NHI Top 10 is useful here because agent governance fails fast when secrets, tool permissions, and identity lifecycle controls are treated as separate problems. These controls tend to break down when agents are allowed to self-select tools across multiple production systems because no single owner has end-to-end visibility over the resulting action chain.

Common Variations and Edge Cases

Tighter governance often increases delivery overhead, requiring organisations to balance faster agent iteration against slower approval paths and narrower access windows. That tradeoff is real, especially when the agent supports incident response, DevOps, or customer-facing automation. One common edge case is the “shared service agent” used by multiple teams. Best practice is evolving, but there is no universal standard yet: the safest model is still to split identities by use case or environment, because shared ownership often becomes shared ambiguity. Another edge case is delegated admin for autonomous remediation. In that model, a platform team may own the identity, but the application owner still owns the impact of the action. If the agent can mutate production state, the business owner must approve the scope even when IAM issues the credential. Another gap appears when teams rely on static credentials because the agent runs too often to make JIT feel practical. NHIMG’s AI LLM hijack breach and DeepSeek breach coverage show why long-lived secrets are a poor fit for agentic systems: once exposed, they create standing access that outlives the task. For implementation details, teams should align with the NIST AI Risk Management Framework and the OWASP Agentic AI Top 10, then translate that into explicit owner, approver, and revoker roles. The model breaks down most sharply in highly autonomous environments where the agent can act faster than human review can keep up.

Related resources from NHI Mgmt Group

• How should organizations approach the governance of AI agents?
• What makes agentic AI an NHI governance issue?
• Why is NHI governance critical in the age of AI attacks?
• Why is single-provider AI agent governance not enough for enterprise security?