Notifications
Clear all
Topic starter
15/08/2026 6:08 pm
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.
NHIMG editorial — based on content published by AppSOC: Debating AI Security Shared Responsibility While the House Is On Fire
Questions worth separating out
Q: How should security teams govern AI models that can call tools and access data?
A: Security teams should govern AI models as non-human identities with named owners, limited scope, short-lived credentials, and continuous authorization.
Q: Why do AI systems make shared responsibility harder than cloud security did?
A: Cloud services had clearer boundary lines between infrastructure, platform, and application layers.
Q: What do teams get wrong when they rely on human-in-the-loop controls for AI?
A: Teams often treat human-in-the-loop as a compliance checkbox, but the real test is whether the organisation understood the risk and placed controls around irreversible actions.
Practitioner guidance
- Define control ownership by AI layer Assign a named owner for prompts, models, orchestration, tools, and downstream data handling so no part of the stack is left without accountability.
- Restrict tool access to explicit task scope Limit each MCP-connected tool and workflow to the smallest viable set of actions, data sources, and execution paths for the intended task.
- Replace manual checkpoints with runtime policy Use continuous policy enforcement to inspect prompts, outputs, tool calls, and data movement in real time rather than relying on human review for routine decisions.
What's in the full article
AppSOC's full article covers the operational detail this post intentionally leaves for the source:
- The article expands on the control-area breakdown used to compare cloud and AI shared responsibility.
- It discusses the specific AI risk categories that complicate responsibility, including prompt injection, model drift, agent autonomy, and tool integrations.
- It outlines the security concerns raised by recent incidents involving Salesforce and MCP protocol debates.
- It describes how runtime monitoring and policy enforcement are positioned to reduce reliance on human-in-the-loop controls.
👉 Read AppSOC's analysis of AI shared responsibility for agents, MCP, and connected applications →
AI shared responsibility and agent risk: where do controls belong?
Explore further
15/08/2026 6:16 pm
Shared responsibility is becoming responsibility deflection in AI security. Once vendors, developers, and customers all influence the same agentic workflow, unclear boundaries become an excuse for incomplete control ownership. That pattern looks familiar from cloud history, but AI compresses the timeline and increases the number of interacting trust decisions. The governance lesson is simple: if no party can explain who authorizes an agent’s actions, the control model is already failing.
A question worth separating out:
Q: Who is accountable when an AI agent takes an unsafe action?
A: Accountability should sit with the business owner of the agent, the team that provisioned the access, and the control owners responsible for monitoring and revocation. If no one can answer who approved the identity, the scope, and the oversight model, the governance framework is not complete enough for production.
👉 Read our full editorial: AI shared responsibility is lagging behind agentic risk
