Who should own AI agent control when models, data and workflows are connected?

Ownership should sit across IAM, data governance and AI governance, with clear escalation paths for runtime anomalies. No single team can see the full dependency chain on its own, so accountability has to be shared while specific response actions remain assigned to named operators.

Why This Matters for Security Teams

When models, data, and workflows are connected, control ownership is no longer a clean IAM question. The real risk sits in the seams: who approves data access, who sets runtime policy, who investigates anomalous agent behaviour, and who can stop an agent that starts chaining tools in ways no designer expected. Guidance from the NIST AI Risk Management Framework and NHIMG research on AI agents as a new attack surface both point to the same operational reality: ownership must be distributed, but accountability cannot be ambiguous.

This matters because agentic systems do not behave like static applications. They can request new data, call tools, and escalate context at runtime, which means control decisions must be evaluated as the agent acts, not just at provisioning time. The strongest programmes treat this as a governance problem across IAM, data security, and AI oversight, with named responders for failures and policy breaches. In practice, many security teams encounter control drift only after an agent has already accessed something it should not have, rather than through intentional design reviews.

How It Works in Practice

Ownership should be split by function, then stitched together with a single escalation path. IAM teams usually own the identity plane, including workload identity, short-lived credentials, and access enforcement for tools and services. Data governance owns classification, permitted use, retention, and sensitive-data exposure rules. AI governance owns model behaviour, acceptable use, testing, and escalation criteria when the system acts outside expected bounds.

The operating model works best when runtime policy is evaluated at the point of action, not as a one-time approval. That is why current guidance increasingly favours policy-as-code approaches, where decisions are made with full context: who or what the agent is, what it is trying to do, which data it is touching, and whether the request matches its declared task. NHI programmes should also align controls to secrets handling and token lifetime, since agents often depend on ephemeral credentials rather than long-lived static secrets. NHIMG’s research on The State of Secrets in AppSec shows why this matters: leaked or overexposed secrets remain difficult to remediate quickly, and that delay becomes more dangerous when a machine can act continuously.

• IAM defines the trust boundary for the agent’s workload identity and tool access.
• Data governance defines which sources, records, and outputs are in scope.
• AI governance defines acceptable behaviour, testing standards, and runtime intervention thresholds.
• Security operations define containment, revocation, and incident response when the agent deviates.

This control model is strongest when paired with standards such as the OWASP Agentic AI Top 10 and the CSA MAESTRO agentic AI threat modeling framework, because both push teams to think in terms of runtime abuse, privilege chaining, and data exfiltration paths. These controls tend to break down when agent actions are embedded in unmanaged business workflows because no single owner has the full inventory of connected tools, prompts, datasets, and delegated permissions.

Common Variations and Edge Cases

Tighter ownership boundaries often increase coordination overhead, requiring organisations to balance faster delivery against stronger runtime assurance. That tradeoff becomes most visible in low-code automations, multi-agent pipelines, and hybrid human-plus-agent workflows, where responsibility can blur between the platform team, the product owner, and the security function.

Best practice is evolving for these environments. There is no universal standard for how much authority a business owner should retain versus how much should move to central governance. In higher-risk deployments, a central AI governance body often sets policy and review gates, while domain teams own the data and workflow specifics. In lower-risk cases, delegated ownership can work if the escalation path is explicit and revocation is immediate.

Edge cases also appear when the same agent serves multiple business units or when external tools are added after launch. Shared agents need stricter separation of duties, while externally connected workflows need a named control owner for each integration point. NHIMG’s OWASP NHI Top 10 and the Ultimate Guide to NHIs — Standards are useful references when aligning these edge cases to a defensible control model. The model fails fastest in environments where agents can self-discover tools, inherit broad data entitlements, or operate across teams without a single accountable responder.

Related resources from NHI Mgmt Group

• How should security teams govern AI trust signals across models, data, and outputs?
• Why is single-provider AI agent governance not enough for enterprise security?
• Who should own governance when human and AI agent identities share workflows?
• Why does AI data accountability matter once models enter core workflows?