Ownership should be shared but explicit. IAM teams should define identity and access policy, API teams should enforce request controls, and platform teams should manage the runtime boundary and logging. If ownership is split informally, gaps appear exactly where agents cross from one service to another.
Why This Matters for Security Teams
AI agent security cannot be owned by a single team because the risk crosses identity, API enforcement, and runtime execution. IAM teams may set the policy, but agents make decisions at runtime; API teams may gate requests, but agents can chain calls across services; platform teams may secure the container or cluster, but that does not by itself constrain what the agent is authorised to do. NHI Management Group’s research on the AI Agents: The New Attack Surface report shows why this matters: 80% of organisations report agents have already performed actions beyond intended scope, and only 44% have implemented any policies to govern them.
The ownership problem is usually a control problem in disguise. If no one team is accountable for the full agent lifecycle, policy gaps appear at the seams: identity issuance, request validation, tool use, and logging. Guidance from the OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework both point toward shared accountability with explicit control ownership, not informal coordination.
In practice, many security teams encounter agent sprawl and uncontrolled tool access only after an agent has already crossed from one service to another.
How It Works in Practice
The cleanest operating model is shared ownership with named control points. IAM should own the agent’s identity, trust policy, and credential lifecycle. API teams should own request-level enforcement, schema validation, rate limits, and abuse detection. Platform teams should own the runtime boundary, workload isolation, secret delivery, and telemetry. That structure reflects how autonomous systems actually behave, which is why NHI-specific guidance such as the OWASP NHI Top 10 and the State of Non-Human Identity Security emphasise visibility, rotation, and over-privilege reduction.
For agentic systems, static role assignment is not enough. The better pattern is to issue workload identity and evaluate authorisation at request time, using context such as task intent, tool sensitivity, environment, and data classification. That means short-lived credentials, not long-lived secrets; policy-as-code, not tribal knowledge; and audit trails that tie each action back to a specific agent instance. External standards are converging on this model: the NIST AI Risk Management Framework supports governance and measurement, while the CSA MAESTRO agentic AI threat modeling framework focuses on runtime threat modelling for autonomous systems.
- IAM defines who or what the agent is, what it may request, and how long trust lasts.
- API teams enforce per-call controls and reject requests that exceed policy, context, or schema.
- Platform teams constrain execution, isolate workloads, and preserve logs for incident response.
- Security leadership owns the RACI, escalation path, and exception process across all three teams.
Controls tend to break down in highly distributed environments where agents use dozens of tools across microservices, SaaS APIs, and human-approved workflows because no single team sees the entire chain of delegation.
Common Variations and Edge Cases
Tighter control ownership often increases coordination overhead, requiring organisations to balance speed of delivery against auditability and containment. That tradeoff becomes visible when agents are embedded in CI/CD pipelines, customer-support workflows, or developer tooling, where teams are tempted to treat the agent like a normal service account. Best practice is evolving, but current guidance suggests that exceptions should be rare, time-bound, and recorded at the control owner level rather than negotiated ad hoc.
There are a few edge cases worth calling out. In a small organisation, one team may temporarily cover all three areas, but the responsibilities still need to be separated on paper and in controls. In a mature platform, a central security team may define standards while product teams operate the controls, yet the accountability for incidents must still be explicit. For agentic AI, this is especially important because a weak link in one layer can become a privilege escalation path; NHI Management Group’s reporting on Moltbook AI agent keys breach and broader agentic threat research shows how quickly keys, tools, and runtime access can be chained together.
The practical rule is simple: ownership should follow the control surface, not the org chart. If IAM, API, and platform teams each own their slice with shared policy and incident visibility, the organisation can contain agent behaviour without blocking legitimate automation.
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 | A01 | Agentic apps need explicit control ownership across identity, tools, and runtime. |
| CSA MAESTRO | GOV-1 | MAESTRO stresses governance for autonomous agents across teams and execution layers. |
| NIST AI RMF | AI RMF governance is directly relevant to cross-team accountability for agent risk. |
Assign named owners for agent identity, tool access, and runtime controls, then test each boundary.
