AI shared responsibility is lagging behind agentic risk

At a glance

What this is: This analysis argues that AI shared responsibility is lagging behind agentic risk, because accountability is not keeping pace with the security boundaries created by models, tools, data and runtime interactions.

Why it matters: IAM, PAM and AI security teams need a clearer control model for agentic systems because responsibility gaps at tool and runtime layers quickly become governance gaps for identity, privilege and data access.

By the numbers:

• The standard cloud model from Microsoft included 28 control areas, with only six categorized as shared responsibility.
• Some emerging AI shared responsibility models approach 100 control areas, with 30 categorized as shared responsibility.

Context

Shared responsibility fails when control boundaries exist on paper but not in practice. In AI systems, the problem is amplified because models, agents, tools, data and APIs interact dynamically, so a single control owner rarely sees the full path of risk from input to action. For identity teams, that means the real question is not who owns the model, but who governs the privileges, delegation and data access that agents exercise while operating.

Cloud created a slower but clearer division of labor between provider and customer. AI does not. The article's central warning is that waiting for a mature division of responsibility leaves organisations exposed now, especially where human approval is being used as a substitute for enforceable control at runtime.

Key questions

Q: What breaks when AI shared responsibility is not clearly defined?

A: Control gaps appear at the seams between model, tool, data and runtime layers. Security teams may believe another party is handling validation, logging or authorisation, while the actual risk moves into delegated actions, unsafe integrations and ungoverned data flows. The result is fragmented accountability and weak enforcement exactly where AI systems are most dynamic.

Q: Why do AI agents create more accountability risk than ordinary application services?

A: Because the agent can vary its plan, select different tools, and update memory during runtime, so the actor is making decisions that are not fixed by code alone. That means accountability must attach to the decision context, permission scope, and evidence trail, not just to the service that executed the request.

Q: What are the signs that human-in-the-loop controls are being overused?

A: If operators are approving routine actions, alert volumes are rising, or teams are relying on manual review to compensate for weak policy enforcement, the control is being overused. A strong signal is when humans become the default security mechanism for processes that should be governed automatically at runtime.

Q: When should organisations treat a GenAI issue as a governance problem rather than a content problem?

A: When the model can access tools, workflows, or sensitive data, the issue extends beyond unsafe text and becomes a delegated-access problem. At that point, teams need governance for what the system can read, remember, and execute, not only for the language it generates.

Technical breakdown

Why AI shared responsibility is harder than cloud shared responsibility

Cloud shared responsibility was difficult, but the control boundary usually stayed legible because infrastructure, platform and application layers could be separated. AI systems collapse those neat lines. A single request may traverse a model, a prompt layer, an orchestration framework, external tools, retrieval sources and business applications before anything visible reaches the user. That means security responsibility is distributed across components that can each alter the outcome, while none can fully explain the resulting behaviour alone. In practice, the governance problem is not just ownership, but composability. When multiple control planes can influence the same action, responsibility becomes fragmented unless runtime guardrails and explicit policy enforcement sit across the stack.

Practical implication: Map ownership by control point, not by platform name, and require policy enforcement where model output becomes tool action.

How agent autonomy and tool integrations widen the control boundary

Agentic systems add a new security property: they can choose when to act, which tools to call and how to sequence tasks. That turns access into a runtime decision rather than a static configuration problem. If an agent can retrieve data, call APIs or trigger workflows, then the governing control is not only authentication but delegated authorisation, contextual policy and logging of the action chain. Tool integrations matter because they extend the blast radius beyond the model itself. An insecure plugin, overly broad token or weak approval gate can move a harmless prompt into a privileged enterprise action. The security issue is therefore less about intelligence and more about delegated execution with insufficient containment.

Practical implication: Treat every agent tool path as a privileged workflow and scope access by task, context and duration.

MCP and connected application risk show where responsibility deflection starts

The article uses MCP as an example of how protocol-level choices affect security downstream. When a protocol connects models to tools and data sources, the security burden shifts from a single application to an ecosystem of developers, integrators and operators. That is where responsibility deflection begins: one party assumes another has secured input validation, tool boundaries or data exposure, and the gap is left to the customer. For identity governance, this is a familiar pattern. When the delegation chain is ambiguous, controls are often pushed to the edge, where they are least effective. Security must therefore be defined at the protocol and integration layer, not only inside the model boundary.

Practical implication: Require explicit policy, logging and approval controls around protocol connections that can expose or move data.

Threat narrative

Attacker objective: The attacker aims to convert a trusted AI workflow into a delegated execution path that leaks data or performs unauthorised actions.

1. Entry occurs when AI systems accept prompts, connector inputs or agent instructions that can traverse multiple tool and application layers without a single enforcement point.
2. Escalation follows when an agent or connected workflow inherits broad delegated access and uses it to invoke tools, retrieve data or act on behalf of the organisation.
3. Impact appears as prompt injection, data leakage, unsafe external actions or policy bypass across models, APIs and enterprise workflows.

Breaches seen in the wild

• xinference PyPI compromise 2026: Three xinference releases on PyPI carried a stealer for cloud, Kubernetes and registry keys, reportedly via a compromised bot account.
• Microsoft SAS token exposure 2023: An over-permissive Azure SAS token in a Microsoft AI GitHub repo exposed 38TB, including workstation backups and Teams messages, for 3 years.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI shared responsibility is not a governance slogan, it is a control-design problem. The article is right to frame the issue as broader than model security because the security outcome is determined by the interaction of models, tools, data and runtime policy. If those layers are governed separately, accountability becomes fragmented even when responsibility looks well defined on paper. Practitioners should treat AI governance as an enforcement problem, not a documentation exercise.

Human-in-the-loop is an important exception control, not a primary security boundary. Requiring people to approve routine AI actions does not scale when agents are built to automate decisions and execute tasks continuously. That creates a familiar identity lesson: controls that depend on persistent human review will fail when the workload volume is high and the action cadence is short. Practitioners should reserve human approval for genuinely high-risk actions and move routine enforcement into runtime policy.

Delegated AI access behaves like privileged access, even when the subject is a model rather than a user. Once an agent can call tools or external services, the key security question becomes who authorised what, under which context and for how long. That is fundamentally an identity and privilege governance issue, not just an AI safety issue. Practitioners should apply privileged access thinking to agents, connectors and orchestration layers.

Protocol-level ambiguity creates shared responsibility debt. MCP is a useful example because the protocol connects components that were never designed to trust each other blindly, yet the article shows how quickly vendors and implementers can push the security burden sideways. This is the same failure mode seen in many identity programmes where delegation exists but lifecycle accountability does not. Practitioners should define control ownership at the protocol boundary before agents are allowed to operate there.

AI governance debt is now a measurable security risk. The article's wider point is that organisations are accumulating unresolved ownership questions faster than they are creating enforceable control models. That debt grows every time a new model, tool or connector is added without a corresponding security decision. Practitioners should reduce it by standardising control ownership across the AI stack, especially where identity, access and data movement intersect.

From our research library:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
• Only 23% of IT leaders were very confident in their organisation's ability to manage security and governance for GenAI deployments, according to a 2025 Gartner survey of 360 IT leaders.

What this signals

AI governance will increasingly need identity-style control thinking because agentic systems turn access into a runtime decision, not a static entitlement. That means the practical boundary is no longer the model itself, but the delegated tool and data actions it can trigger.

AI governance debt: unresolved ownership across models, connectors and runtime policy becomes a durable security liability as organisations add new agentic workflows faster than they define control boundaries. The organisations that move first will standardise enforcement where prompts become actions, not where models merely generate text.

Security teams should expect shared responsibility language to become more explicit in procurement, assurance and incident response conversations. The right response is to demand auditable control ownership for identity, access and data movement before an agent is allowed to operate in production.

For practitioners

• Define control ownership across the AI stack Map who owns model behaviour, tool access, data flows, logging and runtime enforcement before deployment. Do not accept a single vendor boundary as a substitute for internal accountability.
• Limit human approval to high-risk AI actions Use human-in-the-loop review only where the impact justifies delay and operator fatigue. For routine actions, rely on policy enforcement, telemetry and deterministic guardrails instead of manual checkpoints.
• Treat agent tool access as privileged access Scope tool permissions by task, context and duration, then log every delegated action path. If an agent can act externally, its permissions need the same governance discipline as privileged accounts.
• Enforce policy at runtime across model, tool and data layers Place checks where prompts become actions, not only where content is generated. Runtime controls should block unsafe tool calls, restrict data movement and preserve an auditable decision trail.

Key takeaways

• AI shared responsibility is collapsing under the weight of agentic systems, because model, tool and data boundaries no longer line up with a clean provider-customer split.
• The most dangerous gap is not in model output alone but in delegated execution, where agents can use broad access to move data or trigger enterprise actions.
• Security teams should force runtime enforcement and clear control ownership at the protocol and connector layers before relying on manual oversight.

Key terms

• Shared Responsibility Model: A shared responsibility model divides security duties between the cloud provider and the customer. For NHI governance, the provider supplies the platform controls, but the organisation still owns configuration, privilege review, secret handling, monitoring, and lifecycle management of its identities.
• Human-in-the-Loop (HITL): A governance pattern requiring human approval before an AI agent takes high-impact, irreversible, or out-of-scope actions. HITL is a critical control for agentic AI identity governance.
• Agentic AI: Autonomous AI systems capable of planning, deciding, and taking actions, including calling APIs, writing code, and orchestrating other agents, with minimal human oversight. Agentic AI introduces new NHI risks as agents must authenticate to external services.
• Runtime Enforcement: Runtime enforcement is the practice of blocking malicious behaviour while software is running, rather than only detecting it after the fact. It monitors process activity, network actions, and privilege changes so a live attack can be interrupted at the point of execution.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity and secrets management. It is designed for practitioners who need to govern delegated access and runtime control across modern identity programmes.