How Does AI Change the Shared Responsibility Model?
BLOG
5 min.
Organizations across every industry are racing to adopt AI (Artificial Intelligence) and the cloud is where most of that adoption is happening.
Whether you are deploying large language models (LLMs), training custom machine learning models, building agentic workflows or embedding AI into existing applications, the major cloud service providers (CSP) have rolled out dedicated platforms to make it easier than ever to get started.
That speed comes with a familiar risk: the assumption that the cloud provider “handles security.”
TL;DR – The shared responsibility model still applies in a post-AI world. Knowing where cloud provider security ends and your organizational responsibilities begin is fundamental to…
- AI adoption has expanded the customer’s side of the shared responsibility model to include prompt policies, agent IAM roles, data classification, MCP tool permissions and MLOps pipeline security.
- Agentic AI raises the stakes. Over-permissioned agents, unaudited tool invocations and missing human-in-the-loop controls all increase risk.
- Cloud-native security services and third-party vendor tools are complementary, not interchangeable. The right stack of tools depends heavily on the organization’s cloud environment and AI usage.
The shared responsibility model that has governed cloud security for over a decade has not gone away. If anything, AI adoption has expanded the customer’s side of that ledger in ways that many organizations have not yet accounted for.
What Comes in a Cloud-hosted AI Platform?
Each major cloud provider now offers an AI hosting platform that bundles the infrastructure required to build, train, deploy and serve AI models. These platforms typically include:
- LLM Gateways: Model access, policy enforcement, guardrails and cost controls
- MCP (Model Context Protocol) Gateways: Tool authorization, trust boundaries and connection auditing
- Agent Orchestration: Multi-step planning, memory management, tool routing and workflow coordination for autonomous and semi-autonomous AI agents
- API Gateways: Agent identity, rate limits, network controls and authentication
- GPU/Compute: Resources for training and inference
- Model Weights: Hosted and managed by the provider
- Network Backbone and Physical Infrastructure: Underpinning the service
Below the shared responsibility boundary, the CSP owns the heavy lifting: the physical data centers, the network backbone, the model weights for first-party models and the GPU compute fleet.
Above that boundary, the responsibility shifts squarely to the organizations that run them, as it always has.
Machine Learning and MLOps in the Cloud
Before generative AI captured the spotlight, organizations were already running machine learning workloads in the cloud. Custom model training, feature engineering and inference pipelines have been part of the cloud AI landscape for years.
What has changed is the scale and the operational maturity expected around these workloads.
MLOps (Machine Learning Operations) brings software engineering discipline to the ML (Machine Learning) lifecycle. It covers version control for models and datasets, automated training pipelines, model registries, deployment orchestration and continuous monitoring for drift and degradation. Each CSP now provides managed MLOps tooling as part of their AI platforms.
From a security perspective, MLOps introduces its own set of responsibilities on the customer side:
- Training Data Governance: Ensuring that datasets used for model training are classified, access-controlled and free of unauthorized PII or sensitive content
- Model Registry Access Control: Restricting who can publish, promote or deploy model versions
- Pipeline Security: Securing CI/CD pipelines that automate training and deployment, including secrets management and artifact integrity
- Inference Endpoint Protection: Applying network controls, authentication and rate limiting to model serving endpoints
- Drift and Anomaly Monitoring: Detecting when model behavior deviates from expected baselines, which could indicate data poisoning or adversarial manipulation
The CSPs provide the platform and the tooling. You own the policies, the access controls and the monitoring configuration that make those tools effective.
Agentic AI and Agentic Platforms
The newest evolution in cloud AI is the rise of agentic systems. Unlike a traditional LLM interaction where a user sends a prompt and receives a response, an AI agent can reason, plan, use tools and take actions autonomously or semi-autonomously on behalf of a user or a system.
Agentic platforms provide the orchestration layer for building these systems. They handle tool routing, memory management, multi-step planning and integration with external services via protocols like MCP. Every major CSP now offers an agentic development framework within their AI platform.
This is where the shared responsibility model gets especially important. An AI agent is not just reading data. It is acting. It can call APIs, modify records, send communications and trigger workflows. That means the blast radius of a misconfigured agent is significantly larger than a misconfigured chatbot.
Security considerations specific to agentic AI include:
- Agent Identity and Least Privilege: Every agent should operate under a scoped identity with only the permissions it needs to accomplish its task. Over-permissioned agents are the new over-permissioned service accounts.
- Tool Authorization and Trust Boundaries: MCP gateways and tool registries must enforce which tools an agent can access. An agent should not be able to discover or invoke tools outside its authorized scope.
- Action Auditing: Every action an agent takes must be logged with sufficient detail to reconstruct what happened and why. This includes the reasoning chain, the tools invoked and the data accessed.
- Human-in-the-Loop Controls: For high-risk actions (financial transactions, data deletion, external communications), agentic platforms should enforce approval gates where a human must authorize the action before it executes.
- Prompt Injection and Manipulation Resistance: Agents that process external input are vulnerable to prompt injection attacks that could cause them to take unauthorized actions. Guardrails and input validation are critical.
The agentic era does not remove the shared responsibility model. It amplifies it. The more autonomy an organization grants its AI systems, the more critical it becomes to define, enforce and monitor the boundaries of that autonomy using the cloud-native tools the provider offers.
The Shared Responsibility Boundary with AI
The shared responsibility model in AI can be broken into three columns:
What You Own (Organization Side)
- Prompt Policies: Defining what an organization’s models can and cannot say and enforcing those boundaries
- Agent IAM Roles: Granting least-privilege access to AI agents that act on behalf of users
- Data Residency, Sovereignty, & Classification: Knowing what data flows into and out of an organization’s AI workloads
- MCP Tool Permissions: Controlling which tools and external systems any agents can invoke
- API Gateway Authorization: Managing who and what can call AI endpoints
- Logging and Monitoring: Maintaining visibility into model behavior, usage and anomalies
The Platform Under AI (Shared)
This middle layer contains the gateways and orchestration services (LLM Gateway, MCP Gateway, API Gateway) that both you and the provider have a hand in. The provider delivers the platform, but the organization configures the policies, permissions and guardrails that govern how it operates.
Embedded AI Services (CSP Side)
The providers deliver managed AI services that abstract the underlying infrastructure. These are the platforms themselves and each provider has branded their offering differently.
Cloud AI Platforms at a Glance
Every major CSP now offers a managed AI platform. The table below provides a vendor-objective comparison so you can evaluate the landscape regardless of which cloud(s) you operate in.
|
Cloud Provider
|
AI Platform / Service Name
|
Description
|
|---|---|---|
|
Microsoft Azure |
Microsoft Foundry, Copilot Studio
|
Microsoft Foundry provides a pro-code environment for building, deploying and managing AI models and agents. Copilot Studio offers a low-code/no-code platform for building conversational AI agents with enterprise governance. |
|
Amazon Web Services |
Amazon Bedrock, Amazon Q
|
Amazon Bedrock is a fully managed service to build and scale generative AI applications with foundation models, guardrails and agent capabilities. Amazon Q provides an AI assistant for business and developer use cases with enterprise integration. |
|
Google Cloud |
Gemini Enterprise (Agent Platform) |
End-to-end enterprise AI platform (evolved from Vertex AI) for agent development, model access, tuning, deployment and governance with access to 200+ models.
|
|
Oracle Cloud (OCI) |
OCI Generative AI |
Managed generative AI service and agent platform providing access to large language models with dedicated GPU clusters, enterprise AI agents and integration with OCI services.
|
Each of these platforms provides the foundational AI infrastructure (compute, model hosting, APIs) while expecting the customer to configure security policies, access controls and governance on top.
Why Cloud-native and Vendor Security Work Better Together
Cloud-hosted AI solutions, native cloud security services and third-party vendor security tools are better together. No single layer secures AI workloads in isolation.
The CSP provides the AI platform and its native security controls. Third-party vendor tools extend visibility, governance and enforcement across multiple clouds and into areas the native tooling may not yet cover. When combined, it creates a defense-in-depth posture that is greater than the sum of its parts.
Here is the critical point: the same way an organization would never deploy a virtual machine in the cloud without configuring security groups, identity policies and logging, it should never deploy an AI workload without the equivalent controls.
The “better together” advantage means you are not choosing between cloud-native or third-party. They’re being layered. Native services give you tight integration with the platform. Vendor tools provide cross-cloud consistency, specialized capabilities and a single pane of glass for security teams managing AI workloads across multiple CSP environments.
Each CSP provides native security services designed to integrate directly with their AI platforms. They are purpose-built tools that understand the APIs, identity models and data flows of the AI services they protect. The platform and its security controls are better together because they share context, telemetry and policy enforcement at every layer.
Third-party vendor solutions complement this by providing a unified view across multiple CSP-hosted AI platforms, giving security teams and AI innovators a critical single pane of glass to monitor, govern and secure AI workloads regardless of where they run.
Benefits of Layering Cloud-native and Third-party Security
1. Deep Platform Integration Combined with Richer Analytical Depth
Cloud-native security services operate within the same control plane, identity fabric and API surface as the AI platform itself. There are no translation gaps, no blind spots at the boundary and no lag between a security event and its detection.
Third-party vendor tools build on this foundation by adding feature-rich analytical layers: behavioral baselines, cross-workload correlation and AI-specific threat models that turn raw platform signals into prioritized, actionable intelligence.
The native layer captures everything; the vendor layer makes sense of it at scale. They are better together because each amplifies what the other provides.
2. Two-Pronged Policy Enforcement That Preserves Business Velocity
Native services enforce policies inline at the point of execution. They block unauthorized model access, redact sensitive data before it reaches a model and restrict agent tool invocations in real time. This is the critical first line of defense.
Vendor tools complement this with post-processing inspection, deeper content analysis and policy refinement that catches nuanced violations without introducing latency into the production path.
The combination delivers rigorous security at the front door and intelligent reviews behind the scenes, maintaining the speed of innovation while keeping risk within acceptable bounds.
3. Unified Logging and Auditability Across the Full AI Estate
Cloud-native services write to the same audit and monitoring systems security operations team already watches. AI activity surfaces alongside existing workload telemetry in a familiar interface.
Vendor tools extend this by correlating logs across multiple CSP environments, enriching events with threat intelligence and providing a consolidated audit trail that gives compliance teams and security analysts a complete picture regardless of where the AI workload runs.
4. Scalability Without Operational Overhead
Managed security services scale automatically with the platform. As AI adoption grows from pilot to production, the native controls grow with it.
Vendor tools follow the same model, scaling their analytical and governance capabilities elastically, so the security team does not need to stand up, tune and maintain additional infrastructure every time a new model or agent is deployed.
5. Cross-cloud Governance and Operational Consistency
Most enterprises do not run AI on a single cloud. They have workloads distributed across providers based on model availability, cost optimization or existing platform investments.
Third-party vendor solutions serve as the connective tissue across these environments. They normalize security policies so a guardrail defined once applies everywhere, aggregate telemetry into a single operational view and deliver consistent governance regardless of whether the underlying workload runs on Azure, AWS, Google Cloud, OCI or Alibaba Cloud.
This cross-cloud consistency is what transforms isolated platform security into an enterprise-wide AI governance program.
6. Shared Responsibility Alignment with Full-stack Confidence
Using the provider’s native security tools ensures you are addressing the organization’s side of the shared responsibility model with the mechanisms the CSP designed for that purpose.
Layering vendor solutions on top ensures you are not limited to any single provider ships today. You get the prescribed approach from the platform plus specialized, continuously evolving capabilities from the broader security ecosystem.
Together, they close the gap between what the provider secures and what remains the organization’s responsibility to protect.
Benefits of Layering Cloud-native and Third-party Security
The following table outlines key security capabilities and the corresponding native service each CSP offers.
|
Capability
|
Microsoft Azure
|
AWS
|
Google Cloud
|
OCI
|
Alibaba Cloud
|
|---|---|---|---|---|---|
|
AI Guardrails |
Azure AI Content Safety |
Amazon Bedrock Guardrails
|
Gemini Enterprise Safety Filters & Model Armor
|
OCI Generative AI Guardrails
|
AI Guardrails
|
|
Identity & Access |
Microsoft Entra ID |
AWS IAM & IAM Identity Center |
Google Cloud IAM
|
OCI IAM
|
Alibaba Cloud RAM
|
|
Data Loss Prevention |
Microsoft Purview |
Amazon Macie |
Google Cloud DLP
|
OCI Data Safe
|
Data Security Center
|
|
Logging & Monitoring |
Defender for Cloud |
CloudTrail & CloudWatch |
Audit Logs & SCC
|
OCI Audit & Logging
|
ActionTrail & Monitor
|
|
Network Security |
Azure Private Link & NSGs |
AWS PrivateLink & Security Groups |
VPC Service Controls
|
OCI Network Security Groups
|
PrivateLink & Security Groups
|
|
Threat Detection |
Defender for AI
|
Amazon GuardDuty
|
Security Command Center
|
OCI Cloud Guard
|
Security Center
|
Securing Your Side of the AI Shared Responsibility Model
AI adoption adds to an organization’s side of the shared responsibility ledger.
The platforms AI runs on are only as secure as the policies, permissions and controls you configure on top of them. Whether you are running ML training pipelines, deploying inference endpoints or orchestrating autonomous agents, the CSPs have given you the infrastructure and the native tools to do this correctly.
The question is whether your organization is treating AI security with the same rigor it applies to traditional cloud workloads.
If you are deploying AI in the cloud today, ask yourself:
- Have you defined prompt policies and enforced them programmatically?
- Are AI agents operating under least-privilege IAM roles?
- Do you know what data is flowing into and out of models?
- Are MCP tool permissions and API gateway authorizations locked down?
- Are MLOps pipelines secured with proper access controls and artifact integrity checks?
- Do agentic systems have human-in-the-loop gates for high-risk actions?
- Is logging and monitoring capturing AI-specific activity?
If any of those answers are uncertain, the shared responsibility model is working exactly as designed. The cloud provider secured their side. The open question is whether you have secured yours.
What Should You Do Next?
If your organization is deploying AI in the cloud and you are not confident in the answers to the questions above, now is the time to act.
For a Secure Cloud Platform AI Healthcheck Assessment of your environment, including a review of the shared responsibility posture across AI workloads, agentic configurations and MLOps pipelines, reach out to the Cloud Security Practice at GuidePoint Security. Our team specializes in assessing, securing and operationalizing AI platforms across AWS, Azure, Google Cloud, OCI and multi-cloud environments.
To learn more about vendor security solutions for AI workloads, including third-party tools that provide cross-cloud governance, unified visibility and specialized AI security capabilities, contact GuidePoint. Our solution architects evaluate, recommend and implement best-fit security technologies on a vendor-agnostic basis, ensuring the tooling stack complements an organization’s cloud-native controls.
FAQs
Who owns AI security in the shared responsibility model?
The cloud provider secures the infrastructure, model weights and compute fleet. The customer owns everything above that boundary, including prompt policies, agent IAM roles, data classification and monitoring configuration.
What is the biggest security risk with agentic AI?
Over-permissioned agents. An agent with broad access can call APIs, modify records and trigger workflows beyond its intended scope. Scoping every agent to least-privilege permissions is the most critical control.
Does the shared responsibility model change in a multi-cloud AI environment?
The model itself does not change, but the complexity multiplies. Each CSP defines its shared responsibility boundary differently. Organizations running AI across multiple clouds need cross-cloud governance to enforce consistent policies.
What happens if you don't update your shared responsibility model for AI?
Gaps form between what the cloud provider secures and what your team assumes is covered. Those gaps are where misconfigurations, over-permissioned agents and unmonitored AI workloads create exposure that traditional cloud security controls were never designed to catch.
Matt Popa is a Practice Director at GuidePoint Security on the Cloud Security Practice, where he leads delivery of cloud, AI and automation security services across Microsoft, Automation and AI. He is part of GuidePoint’s Cloud Security practice, which helps organizations adopt cloud and AI securely and with confidence.
Matt has 20 years of experience in the cybersecurity and IT industry, including more than 6 years in the public sector and about 8 years supporting federal civilian, aviation, defense and intelligence agencies. He has extensive experience in Platform, Cloud, Automation, AppSec and AI security.
