TL;DR: AI systems, agents, MCP protocols, and connected applications are creating a shared responsibility problem faster than cloud governance matured, with the result that responsibility is often clearer than accountability, according to AppSOC. The practical issue for security teams is not who owns the theory, but how to enforce controls across model, tool, data, and runtime layers before manual oversight becomes a security bottleneck.
Editorial analysis by NHI Mgmt Group, based on content published by AppSOC: “AI Security Shared Responsibility Debate”.
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.
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.
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.
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.
Practitioner guidance
- Define control ownership across the AI stack Map who owns model behaviour, tool access, data flows, logging and runtime enforcement before deployment.
- Limit human approval to high-risk AI actions Use human-in-the-loop review only where the impact justifies delay and operator fatigue.
- Treat agent tool access as privileged access Scope tool permissions by task, context and duration, then log every delegated action path.
Bottom line: 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.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full 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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: AI shared responsibility is lagging behind agentic risk