Underestimated Risk: Shared Responsibility

Why availability is not security and what that means in practice for organizations.

The Shared Responsibility Model is the backbone of the information and infrastructure security of modern IT landscapes. It precisely defines which tasks are the responsibility of the provider and which the customer must take on.

The current discussion about Anthropic and its specific, four-stage model for AI agents has brought the topic back into focus. But what does shared responsibility mean in practice and what impact does it have on the IT security strategy of organizations?

Was Is Shared Responsibility?

The Shared Responsibility Model is a framework that defines the responsibilities between a service provider (e.g., Microsoft, AWS, OpenAI) and the user. This is to avoid security gaps that could arise if both sides assume that the other side is responsible for a certain protection aspect (e.g. backups or patching).

A simple rule of thumb is: The provider is responsible for the security of the infrastructure, while the customer is responsible for the security of his data, including configurations, interfaces and identities.

What Do All Models Have In Common?

Despite different services – cloud, SaaS, AI, cybersecurity – there are constants that remain the responsibility of the customer in almost every model:

Data sovereignty: The customer is always responsible for the classification, protection and lawful processing of their data.

Identity and Access Management (IAM): The customer is always responsible for managing users, roles, and permissions, as well as authentication.

Endpoint Security: The protection of the devices used to access the services (laptops, smartphones) is the responsibility of the user – and therefore the customer.

Configuration and Rules: The provider provides the mixing console, but the customer must set the controls correctly.

Differences By Service And Provider

The division shifts depending on the degree of abstraction of the service.

For cloud services, it depends on the service type:

IaaS: The provider takes care of the stability, security and availability of the network, hosts, host OS and the virtualization environment. The customer must patch client operating systems and configure the firewall (Security Groups).

PaaS: The provider is also responsible for things like the client operating system, runtime environment (e.g. Java, .NET, Python), middleware and database engine – including patch management.

Storage: The provider guarantees the physical integrity and availability of the storage. The customer is responsible for the integrity and security of his data, including encryption and key management as well as access and access authorizations.

With SaaS offerings, the vendor handles almost everything down to the application layer. This includes, among other things, the availability of the app, software updates and physical security. Backup as well as information and data protection are always a matter for the customer.

For example, Microsoft secures your email and data against server outages, but not against accidental deletion by users, phishing attacks, or ransomware encryption.

The fact that many organizations still confuse availability with integrity is proven by a recent survey by Hornetsecurity. Daniel Hofmann, CEO of Hornetsecurity by Proofpoint, confirms: "The survey results show that too many organizations in Germany still rely solely on the integrated security features for Microsoft 365. They don't realize that Microsoft has a shared responsibility model that primarily secures the platform itself, while companies are responsible for protecting their email inboxes, data assets, and user accounts. This applies equally to collaboration applications such as Teams, which are increasingly used for business communication and document exchange."

Hofman recommends addressing all potential risks "through consistent optimization of security settings, the use of additional next-generation protection and monitoring mechanisms, and effective management of identities, data, and access rights within the organization. This underscores the importance of ensuring that companies "secure" their M365 platform comprehensively and multi-layeredly across all relevant aspects.

For cybersecurity platforms like Palo Alto Networks', responsibility is particularly tightly intertwined. The manufacturer guarantees that the platform is running, the signatures/threat data are up-to-date, and the sensors are working. The customer is responsible for defining the policy. If the firewall is set to "Allow All," this is a fault of the customer, not the platform. The response to alarms (incident response) is also up to the customer.

In the case of AI, the model is relatively new and specific. In most cases, the responsibility for "model safety" (avoidance of harmful output), the security of the training data and the safeguarding of the API infrastructure lies with the provider. The customer assumes responsibility for the prompts (e.g. inputs must not contain sensitive data) and the validation of the outputs as well as the protection of the API keys.

Agentic AI

While the classic shared responsibility model primarily distinguishes between infrastructure and data, Anthropic goes one step further with AI agents. The manufacturer argues that AI agents that use tools and perform actions on their own require a new way of dividing tasks, and divides responsibility into four levels – the vendor sees a large part of the responsibility with the customer:

Layer 1: The model – The provider is responsible for the availability and function including training of the model, basic security filters (constitutional AI) and resistance to e.g. jailbreaks and prompt injection. However, research shows that no model is 100% immune to prompt injection.

Layer 2: The harness – Things like system prompts, guardrails, and approval workflows that are designed around AI are the responsibility of the customer. Many companies neglect this level. There is also the danger that "human-in-the-loop" (human confirms every action) often degenerates into "human-on-the-side" at high speed – humans only nod off without checking.

Layer 3: The tools – Depending on the use case and contract, the responsibility for interfaces, protocols, services, and plugins that an agent accesses may be shared. This layer offers by far the greatest potential for discussion. Among other things, the following will be discussed: Who is liable if an agent deletes data due to a faulty third-party tool? In this context, Anthropic calls for stricter role and authorization concepts.

Layer 4: The environment – Anthropic clearly sees the sandbox or network in which the agent operates as the responsibility of the customer.

What Does Shared Responsibility Mean In IT practice?

With the shared responsibility model, you buy a secure foundation on which you have to build your own security.

For IT managers, this results in three critical fields of action:

Avoidance of "blind spots": IT managers must carefully examine where the provider's responsibility ends.

Compliance & Audit: During audits, IT leaders must prove that they have fulfilled their share of responsibility. The provider usually only provides SOC 2 reports for its part.

Skill Management: Teams need to be trained on IAM strategies, prompt governance, cloud security posturing, and more.

Introducing an AI Solution in a Regulated Environment

In our scenario, let's say a company uses a large language model (LLM) from a vendor in a cloud environment (e.g., Microsoft Azure OpenAI, Google Vertex AI, or Anthropic via AWS Bedrock) for an internal knowledge base or customer chatbot.

This results in the following responsibilities:

The Infrastructure & Model Level (Responsibility: Provider)

The provider (e.g. Microsoft or Google) guarantees the security of the "black box" and the environment:

Physical Security & Data Center: Protect the servers running the GPU clusters.

Model Integrity: Ensure that the base model is not manipulated by external attacks during operation (model poisoning).

Safety Filters (Base): Implement basic filters that prevent the model from generating guidance for illegal activities or hate speech.

Data Residency: Options that ensure that data does not leave the national territory or the EU (essential for GDPR).

Certifications: Providing proof of compliance such as SOC2, ISO 27001, HIPAA compliance.

The Data & Input Level (Responsibility: Customer / IT Manager)

This is where the greatest risk lies in regulated industries. The provider does not know what data is fed into the model.

Data Classification & Anonymization: Before data is sent to the AI, the customer must ensure that no personally identifiable information (PII) or trade secrets are transferred (unless a specific data processing agreement exists).

RAG safety (Retrieval Augmented Generation): When AI accesses customer-owned documents: Who has access to what? For example, the AI is not allowed to display information from the management's pay slips to a clerk.

Prompt Injection Defense: Protection against malicious inputs that try to bypass AI's security filters.

The Output & Application Level (Responsibility: Customer)

AI models are stochastic – they guess the next word. This often collides with the regulatory requirement for correctness.

Validation & Hallucinations: If the AI gives incorrect legal advice or financial advice, the provider of the service – i.e. the bank or the insurance company – is liable, not the model developer. The customer must establish mechanisms for testing (human-in-the-loop).

Bias monitoring: In regulated environments, it must be ensured that AI does not discriminate against anyone based on origin, age or gender (e.g. in credit decisions). The model training is provided by the provider, but the application of the model to specific groups is supervised by the customer.

Explainability: Regulators (such as BaFin or the ECB) often demand that decisions are comprehensible. The customer must be able to document how the AI solution came to a conclusion.

Governance & Compliance (Shared Responsibility)

The provider offers standard service level agreements (SLAs), logs API calls and system accesses, and provides encryption at rest or in transit.

The customer logs which employee has made which query, manages the encryption keys (BYOK - Bring Your Own Key) and must check specific additional agreements (e.g. for persons subject to professional secrecy).

What This Means In Concrete Terms For The Rollout?

If you are introducing AI in a regulated environment, you as an IT manager must work through the following checklist, as the provider may not take care of these points for you:

Technical assessment: Does the provider use my prompts to train its models? (Usually disabled in Enterprise versions but must be checked explicitly).

Security layers: Installation of a "security gateway" between users and AI that filters sensitive data before it leaves the house.

Technical control: Implement a process where AI outputs are proofread by experts before they reach the end customer.

Documentation: Preparation of a risk analysis according to the new EU AI Act, which strictly assigns responsibility to the "operator" (i.e. you) depending on the risk class of the application.

Conclusion

With AI solutions in a regulated environment, liability and compliance issues are far more complex than with standard IT projects. "Shared responsibility" is virtually synonymous with a "90% risk shift" to the customer. While the provider secures the hardware and the model, the content risk (liability for false statements) lies almost 100% with you.

This article originally appeared on MES Computing’s sister site Computing Deutschland.