Identity teams own the privileges, connected accounts, and review process, while cloud teams own exposure, reachability, and workload context. Neither view is sufficient alone. Shared responsibility means validated AI findings must flow into the same governance records used for access decisions, so exposure, privilege, and evidence stay aligned.
Why This Matters for Security Teams
agentic ai risk sits at the overlap of identity, cloud exposure, and runtime behaviour, so neither team can own it end to end. Identity teams typically control privileges, service accounts, and review evidence, while cloud teams see network reachability, compute paths, and workload context. That split becomes dangerous when an agent can chain tools, request new access, or move through cloud services faster than periodic reviews can detect.
Current guidance from the NIST AI Risk Management Framework and the OWASP Top 10 for Agentic Applications 2026 points toward shared accountability for design-time and runtime controls, not siloed ownership. NHIMG’s Ultimate Guide to NHIs shows why this matters: 97% of NHIs carry excessive privileges, and 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.
In practice, many security teams encounter agent abuse only after a connected account has already been used to expand access or reach sensitive cloud resources.
How It Works in Practice
Shared responsibility works best when both teams operate from the same evidence chain. Identity owns the entitlement model, connected account lifecycle, token issuance, and review workflow. Cloud owns the execution surface, workload identity bindings, trust boundaries, and telemetry that prove what the agent actually touched. The point is not to duplicate controls, but to make sure validated AI findings update the same governance record that drives access decisions.
For agentic systems, static role assignment is often too blunt. An autonomous agent does not follow one fixed access pattern, so permissions should be scoped by task, context, and duration. That is where CSA MAESTRO agentic AI threat modeling framework and NIST IR 8596 Cyber AI Profile are useful: they both reinforce the need to evaluate AI risk in context, not just by account label.
- Use workload identity for agents so the system proves what the agent is, not just what secret it holds.
- Issue just-in-time credentials for a single task, then revoke them when the task completes.
- Send cloud detections, secret exposure, and agent action logs into the same case record used by IAM reviews.
- Require runtime policy evaluation for sensitive actions instead of relying only on pre-approved roles.
NHIMG’s OWASP NHI Top 10 is especially relevant when agent permissions are mediated through service accounts, API keys, or delegated cloud tokens. These controls tend to break down in fast-moving multi-account cloud environments because telemetry, entitlement data, and revocation workflows are often owned by different teams.
Common Variations and Edge Cases
Tighter agent control often increases operational overhead, requiring organisations to balance stronger containment against slower delivery and more complex incident handling. Best practice is still evolving, especially for organisations that run many agents across multiple cloud accounts, because there is no universal standard for how often agent context should be re-evaluated.
One common edge case is delegated automation in CI/CD or support workflows. If an agent only ever runs inside a narrow pipeline, identity teams may be tempted to treat it like a normal service account. That can fail when the agent later receives broader tool access, connects to a new SaaS integration, or inherits permissions from a parent workload. Another case is cross-functional governance: cloud teams may see the attack path while identity teams see the credential, but neither alone can determine whether the agent’s behaviour actually exceeded its intended scope.
For that reason, current guidance suggests using joint review triggers for any event that changes both exposure and privilege, such as new connectors, secret rotation failures, unusual lateral movement, or a new external tool reaching the agent. The strongest program is the one that treats each of those as a shared control failure, not a handoff problem.
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 | A2 | Agentic systems need runtime controls because static roles miss autonomous behaviour. |
| CSA MAESTRO | M2 | MAESTRO covers shared threat modeling for agents across identity and cloud boundaries. |
| NIST AI RMF | GOVERN | AIRMF governance fits cross-team accountability for agentic AI risk decisions. |
Assign joint ownership for agent risk, approval, and monitoring under a single governance process.
Related resources from NHI Mgmt Group
- How should security teams govern machine identity credentials in agentic AI environments?
- Why do AI agents create new risk in non-human identity management?
- Why do AI agents increase non-human identity risk in existing IAM programmes?
- When does just-in-time access reduce risk for agentic AI, and when does it fall short?
