Ownership should sit across IAM, security architecture, and the teams operating the agent platforms, because the problem spans identity, tool access, and runtime enforcement. Treating it as only an AI issue or only a platform issue leaves control gaps between teams and systems.
Why This Matters for Security Teams
Autonomous AI control plane decisions are not a narrow platform setting. They determine which identities exist, which tools an agent can reach, when access is granted, and how quickly privilege is removed. That means ownership must span IAM, security architecture, and the operating teams that run the agent platform. If any one group owns the issue alone, gaps emerge between identity, policy, and runtime enforcement.
This is especially true for agentic systems because static role design rarely matches real behaviour. An agent may chain actions, request new tools, or pivot across workflows in ways that are only visible at execution time. NHI Management Group research on the OWASP NHI Top 10 shows how quickly control failures turn into abuse when identities and access rules are not tied to actual runtime behaviour. Current guidance from the NIST AI Risk Management Framework supports governance that is shared, accountable, and operational, not purely advisory.
In practice, many security teams encounter control-plane weakness only after an agent has already used a legitimate pathway to reach data or tools that nobody intended it to have.
How It Works in Practice
The practical answer is to treat control-plane ownership as a federated operating model. IAM should own identity proofing, workload identity patterns, and credential issuance. Security architecture should own policy design, trust boundaries, and exception handling. Platform and product teams should own the agent runtime, tool integrations, and enforcement hooks. No single team should be allowed to define all three layers without review.
A useful model is: identity tells the system what the agent is, policy decides what it may do right now, and the platform enforces that decision before the tool call happens. That is why workload identity patterns such as SPIFFE, OIDC-based service tokens, and short-lived credentials matter more than static service accounts for autonomous systems. For agentic controls, the best practice is evolving toward runtime, context-aware authorisation rather than pre-defined RBAC alone. The OWASP Agentic AI Top 10 and CSA MAESTRO agentic AI threat modeling framework both point toward the same operational need: controls must be evaluated at request time, with full context.
In NHIMG’s LLMjacking research, the value of fast containment is clear because exposed credentials can be targeted almost immediately. That is why JIT credential provisioning, automatic revocation, and per-task TTLs should sit inside the control plane rather than be bolted on later. Control ownership works best when one team runs the policy engine, another validates the identity source, and a third owns the agent platform’s enforcement path. These controls tend to break down in highly distributed environments where each product team wires its own tool access and no central service can see the full decision chain.
Common Variations and Edge Cases
Tighter control-plane ownership often increases delivery overhead, requiring organisations to balance speed against assurance. That tradeoff becomes sharper when dozens of agents, plugins, or toolchains are deployed across different business units. There is no universal standard for who owns the final approval layer yet, so current guidance suggests using a shared RACI rather than a single owner.
In smaller environments, a central security architect may temporarily own the policy model, but that arrangement should not extend into long-term operations. In regulated environments, the approval path usually needs stronger separation of duties, with security defining guardrails and platform teams handling enforcement. In fast-moving agentic programs, product teams often push for self-service tool onboarding, but that only works if policy-as-code, approval logging, and secret revocation are already embedded.
NHIMG’s analysis of the State of Secrets in AppSec shows how fragmentation creates control drift, and that lesson applies directly to autonomous AI control planes. Ownership should remain joint, but accountability must be explicit: IAM for identity, security architecture for policy, and platform teams for enforcement. The main exception is a narrowly scoped pilot, where one accountable lead can coordinate decisions temporarily. Even then, the pilot should be designed so it can later split cleanly into those three ownership domains.
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, CSA MAESTRO and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST AI RMF and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A2 | Agentic systems need runtime controls for tool use and escalation. |
| CSA MAESTRO | TSM-1 | MAESTRO maps agent roles, trust boundaries, and enforcement ownership. |
| NIST AI RMF | GOVERN | AI RMF requires clear accountability for autonomous AI decisions. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Control plane ownership depends on secure issuance and rotation of non-human credentials. |
| NIST Zero Trust (SP 800-207) | AC-4 | Zero trust supports per-request authorisation for autonomous workloads. |
Define who approves agent actions and enforce request-time policy checks before any tool call.
