Subscribe to the Non-Human & AI Identity Journal
Home FAQ Agentic AI & Autonomous Identity How do identity and cloud teams share responsibility…
Agentic AI & Autonomous Identity

How do identity and cloud teams share responsibility for agentic AI risk?

← Back to all FAQ
By NHI Mgmt Group Editorial Team Updated June 9, 2026 Domain: Agentic AI & Autonomous Identity

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.

FrameworkControl / ReferenceRelevance
OWASP Agentic AI Top 10A2Agentic systems need runtime controls because static roles miss autonomous behaviour.
CSA MAESTROM2MAESTRO covers shared threat modeling for agents across identity and cloud boundaries.
NIST AI RMFGOVERNAIRMF governance fits cross-team accountability for agentic AI risk decisions.

Assign joint ownership for agent risk, approval, and monitoring under a single governance process.

NHIMG Editorial Note
Reviewed and updated by the NHIMG editorial team on June 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org