AI shared responsibility is lagging behind agentic risk

At a glance

What this is: This analysis argues that AI security is outpacing any stable shared responsibility model, especially once agents, MCP, and connected applications are involved.

Why it matters: It matters because IAM, PAM, and security teams need to decide where identity, privilege, and runtime controls sit when AI behaviour spans multiple owners and control planes.

By the numbers:

• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.

👉 Read AppSOC's analysis of AI shared responsibility for agents, MCP, and connected applications

Context

AI shared responsibility is the governance gap that appears when multiple parties can influence the same security outcome but no one owns the full control path. In agentic environments, that gap expands because identity, privilege, data access, tool use, and runtime behaviour all intersect. The primary issue is not whether AI creates new risk, but whether existing operating models can assign accountable control boundaries at machine speed.

Cloud security eventually settled into a shared responsibility model because infrastructure boundaries were comparatively stable. AI systems are more dynamic: prompts, model responses, agent decisions, external tools, and connected data sources all contribute to risk, which makes responsibility harder to partition cleanly. That is why the article’s central claim is typical of the current market rather than an outlier; many organisations are still trying to govern a moving target.

Key questions

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. The critical shift is to treat every tool call, data read, and update path as a privileged action that can be logged, revalidated, and revoked. Without that discipline, model risk becomes identity risk.

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. AI systems mix prompts, models, agents, tools, and data sources in a way that blurs those lines, so multiple parties can influence one outcome without one party controlling the full control path. That creates accountability gaps unless ownership is defined by function and runtime responsibility.

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. A human review step helps only when it is tied to ownership, evidence, and a clear boundary for what the agent may do.

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.

Technical breakdown

Why AI shared responsibility breaks down across layers

AI systems do not behave like single products. A model may generate output, an application may pass prompts, an agent may decide when to call tools, and external services may return data that changes the next decision. That means security ownership spans model behaviour, application logic, orchestration, and data governance at the same time. Traditional control boundaries assume a clear separation between provider and customer, but AI stacks are compositional and frequently cross administrative domains. In practice, that creates gaps where no team fully owns prompt validation, tool authorization, or post-action monitoring.

Practical implication: map AI control ownership by layer, not by vendor, and require a named owner for prompts, tools, data, and agent actions.

MCP and tool integration create new privilege pathways

MCP, or Model Context Protocol, connects AI agents to tools and data sources, which is useful operationally but also introduces a privilege transfer problem. Once an agent can invoke tools, the security question is no longer only what the model can say, but what the surrounding system allows it to do. Tool access can become an indirect form of identity and authorization, especially when agents inherit credentials or act on behalf of users or workloads. Without strict scoping, the protocol layer becomes a bridge from reasoning to execution, and that bridge can be abused through prompt injection, tool misuse, or over-broad delegation.

Practical implication: treat MCP-connected tools as privileged resources and enforce explicit authorization, scoping, and logging for every callable action.

The shared responsibility model needs runtime enforcement, not manual checks

The article is right to challenge human-in-the-loop controls as a primary security mechanism. Manual review can help in edge cases, but AI systems are built for speed and volume, which means security has to operate continuously at runtime. That is especially true where agents can sequence actions across multiple systems without waiting for approval. Governance based on after-the-fact review cannot prevent rapid misuse, data leakage, or unintended side effects. The control pattern that matters is continuous policy enforcement across prompts, outputs, tool calls, and data exposure, with auditability built in from the start.

Practical implication: move from review-based governance to runtime policy enforcement with continuous monitoring and immutable audit trails.

Threat narrative

Attacker objective: The attacker wants to convert AI trust into unauthorized execution, data exposure, or downstream system abuse.

1. Entry begins when an attacker manipulates prompts or abuses an over-trusted AI integration to influence agent behaviour.
2. Escalation follows when the agent inherits or reaches tool and data privileges that were not tightly scoped to the task.
3. Impact occurs when the agent leaks sensitive data, executes unsafe actions, or propagates compromise across connected systems.

NHI Mgmt Group analysis

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.

AI agents are a non-human identity problem as much as an AI problem. When agents receive credentials, invoke tools, or act across systems, they behave like machine identities that need lifecycle, scope, and accountability controls. That makes the identity bridge explicit for IAM and PAM teams, because delegation without durable governance turns an agent into an unbounded access path. The practitioner conclusion is that agent identity must be governed like any other privileged workload, not treated as a user convenience layer.

Policy at runtime is the named concept this market needs more than another policy document. The article shows why static responsibility charts do not stop prompt injection, unsafe tool calls, or data leakage during execution. Runtime policy is the point where governance becomes enforceable, because it can evaluate context, scope, and data sensitivity at the moment of action. Security teams should treat runtime policy as the control plane for AI behaviour, not a supplementary feature.

Shared fate is the more realistic operating model for AI ecosystems. Providers may define interfaces, but customers still inherit the security consequences of how models, tools, and data are combined. That means the market is moving away from clean handoffs and toward distributed accountability with stronger defaults, better telemetry, and tighter authorization design. The practical conclusion is that organisations must assume they own the risk even when the responsibility statement says otherwise.

AI governance will increasingly converge with identity governance. The same control questions reappear across human, workload, and agent identities: who can act, for how long, with what scope, and under which review model. That convergence will pressure IAM, PAM, and AI security teams to align on shared policy and event evidence. Practitioners should prepare for AI governance to become an identity governance workload, not a separate programme.

What this signals

AI governance is now converging with identity governance, because agents increasingly behave like privileged non-human identities that need lifecycle control, scope limits, and revocation. The control question is no longer only whether a model is safe, but whether every action path has a named owner and enforceable policy.

Policy at runtime: this is the operational boundary that will separate usable AI systems from governable ones. Teams that rely on manual approval will accumulate latency and blind spots, while teams that instrument prompts, tool calls, and data flows will have evidence to defend decisions and limit blast radius.

For identity teams, the practical signal is delegation pressure. Once agents can invoke tools or inherit credentials, IAM and PAM must decide whether the agent is a service account, a workload identity, or a new governance class entirely, and then align controls accordingly.

For practitioners

• 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.
• Treat AI agents as privileged machine identities Apply lifecycle, authorization, and logging controls to agents the same way you would for other high-trust non-human identities, including revocation when a workflow changes.

Key takeaways

• AI shared responsibility fails when no one owns the runtime control path across prompts, tools, data, and execution.
• Agentic systems turn identity governance into an operational requirement because delegated actions can carry real privilege.
• Runtime policy enforcement and continuous auditability matter more than manual review when AI systems act at machine speed.

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.
• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
• Runtime Policy Enforcement: Runtime policy enforcement evaluates a request at the moment it is executed instead of relying only on preconfigured permissions. For AI agents, this allows decisions to reflect current context, target sensitivity, and behavioural signals rather than static assumptions.
• Agent Identity: An agent identity is the set of attributes, credentials and permissions assigned to an autonomous software entity. It is treated as a non-human identity because it can authenticate, act on systems and accumulate access over time, which creates governance, audit and lifecycle obligations similar to other production identities.

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.

👉 AppSOC's full post expands the responsibility model debate into practical control gaps, runtime governance, and AI stack ownership.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management for practitioners who need to govern delegated access. It helps identity and security teams align policy, ownership, and lifecycle controls across human and non-human access models.