Cloud Security, Privacy and Responsible AI

Introduction

Cloud computing has become the operational foundation for many artificial-intelligence and machine-learning (AI/ML) systems. Training data may be stored in object repositories, models may be trained on elastic GPU clusters, inference may be exposed through managed APIs, and monitoring data may be distributed across several regions and providers. This architecture creates significant advantages—scalability, rapid experimentation and access to specialised services—but it also enlarges the security, privacy and governance boundary.

A secure cloud AI system must protect confidentiality, integrity and availability while also addressing properties particularly important to AI: data provenance, model integrity, reproducibility, explainability, robustness and accountability. Security is therefore not an isolated technical function. It is a lifecycle discipline spanning data collection, development, deployment, operation and retirement.

This chapter develops practical foundations for identity and access management, zero-trust architecture, encryption, key and secrets management, network security, software supply-chain security, threat modelling, privacy engineering and responsible-AI controls.

Learning Objectives

After studying this chapter, students should be able to:

1. Explain the security and privacy risks of cloud-based AI systems.

2. Design basic identity, access-control and zero-trust controls.

3. Select appropriate encryption, key-management and secrets-management practices.

4. Apply network segmentation and secure software-supply-chain principles.

5. Construct a threat model for an AI workload.

6. Explain privacy-engineering techniques and their limitations.

7. Recommend responsible-AI controls for fairness, transparency, safety and accountability.

8. Evaluate a cloud AI architecture against technical, ethical and regulatory requirements.

1. The Security Context of Cloud AI

Traditional applications usually have a relatively stable perimeter. Cloud AI systems do not. A single workflow may include a developer laptop, source-code repository, CI/CD pipeline, data lake, feature store, training cluster, model registry, endpoint, logging platform and external users. Each component may use a different identity system and may be operated by a different organisation.

The shared-responsibility model is fundamental. A cloud provider generally secures the physical facilities, hardware and core platform, while the customer remains responsible for configuration, identities, data, workloads and often operating-system components. The exact boundary differs between infrastructure-as-a-service, platform-as-a-service and software-as-a-service offerings. Misunderstanding this boundary is a common cause of exposed storage, excessive permissions and unprotected interfaces.

AI introduces additional attack surfaces:

• Training-data poisoning: malicious or low-quality records influence model behaviour.
• Data exfiltration: sensitive training or inference data is disclosed through storage, logs, prompts or model outputs.
• Model theft: repeated queries or unauthorised access allow reconstruction or copying of a model.
• Prompt injection: untrusted instructions manipulate a generative-AI system or connected tools.
• Adversarial inputs: carefully crafted inputs cause incorrect predictions.
• Supply-chain compromise: a vulnerable dependency, container image, dataset or pretrained model enters the pipeline.
• Inference attacks: membership-inference or model-inversion techniques reveal information about training data.

Security goals should be translated into explicit requirements. For example, “protect customer data” may become: only approved service identities can read a specified dataset; all access is logged; data is encrypted in transit and at rest; retention is limited; and a tested recovery process exists.

2. Identity, Access Management and Zero Trust

2.1 Identity and access management

Identity and access management (IAM) establishes who or what may perform an action on a resource. Subjects include human users, service accounts, workloads, devices and external partners. Resources include datasets, notebooks, model registries, secrets, GPU clusters and inference endpoints.

A useful access decision can be expressed conceptually as:

Permit or deny = policy(subject, action, resource, context).

Context can include location, device posture, time, authentication strength, data classification and risk signals. This is a policy model rather than a numerical formula; it reminds designers that authorisation should not depend only on a username.

The principal design principles are:

• Least privilege: grant only the permissions necessary for an approved task.
• Separation of duties: divide sensitive activities, such as developing, approving and deploying a model.
• Need to know: restrict access to data according to legitimate purpose.
• Explicit accountability: use individual identities where possible; avoid shared accounts.
• Lifecycle management: provision, review and revoke access as roles change.
• Strong authentication: use multifactor authentication for privileged human access and robust workload identity for services.

Role-based access control assigns permissions to roles, such as data scientist or deployment operator. Attribute-based access control evaluates attributes such as project, data sensitivity, geography and employment status. Roles are easy to administer initially, whereas attributes can express fine-grained and dynamic policies. Poorly designed roles, however, can accumulate permissions and create privilege creep.

Service identities deserve particular attention. A training job should receive temporary permission to read its approved training data and write its output model; it should not possess administrative credentials or unrestricted access to the entire account. Short-lived tokens and workload identity federation reduce the need to embed long-lived credentials in code or images.

2.2 Zero-trust architecture

Zero trust rejects the assumption that network location establishes trust. Every request is authenticated, authorised and evaluated using relevant context, regardless of whether it originates inside a corporate network. Important practices include:

1. Verify explicitly.

2. Apply least-privilege access.

3. Assume breach and limit blast radius.

4. Continuously monitor and reassess.

For an AI platform, this may mean private endpoints for model services, identity-aware access to notebooks, separate environments for development and production, and approval before a model can access sensitive datasets. Zero trust is not simply “put everything behind a firewall”; it is a combination of identity, policy, segmentation, telemetry and response.

3. Encryption, Keys and Secrets

Encryption transforms readable plaintext into ciphertext using a key. Symmetric encryption uses the same secret key for encryption and decryption and is efficient for large datasets. Public-key cryptography uses a public/private key pair and is useful for authentication, key exchange and digital signatures. In practice, cloud systems commonly use public-key mechanisms to establish trust and symmetric mechanisms to protect bulk data.

Encryption should be considered in three states:

• At rest: databases, object stores, disks, snapshots, backups and model artefacts.
• In transit: connections between users, services, regions and providers, typically protected with TLS.
• In use: data while being processed in memory; specialised confidential-computing technologies can reduce exposure but may introduce performance and platform constraints.

Encryption does not solve every problem. An authorised application can decrypt data, a compromised endpoint can misuse plaintext, and poor key control can make encrypted data effectively unprotected.

Key-management lifecycle

A key-management service or hardware security module can generate, store and use cryptographic keys while restricting direct extraction. A sound lifecycle includes generation, activation, controlled use, rotation, backup, revocation, destruction and audit. Key rotation limits the amount of data protected by one key, but rotation does not automatically re-encrypt historical data or repair a compromised application.

A common envelope-encryption pattern uses a data-encryption key (DEK) to encrypt data and a key-encryption key (KEK) to encrypt the DEK. The ciphertext and encrypted DEK are stored together, while the KEK remains under central key-management control. This improves scalability because large data objects are encrypted with efficient symmetric cryptography, while access to the DEK is governed by the KEK policy.

Secrets include passwords, API tokens, certificates, database credentials and signing keys. They should not be placed in source code, notebooks, container images, tickets or ordinary configuration files. Use a managed secrets vault, restrict retrieval by workload identity, rotate automatically where possible, and prevent secrets from appearing in logs. Secret scanning in repositories is useful but is not a substitute for revocation and redesign after exposure.

4. Network and Workload Security

Cloud network security combines logical boundaries, traffic controls and monitoring. A practical AI environment may separate development, testing and production into different accounts or projects. Within an environment, subnets and security groups can restrict which services communicate.

Important controls include:

• private connectivity to storage, registries and managed services;
• ingress filtering that allows only required inbound traffic;
• egress controls to prevent unrestricted data exfiltration;
• web application firewalls and API gateways for public interfaces;
• denial-of-service protection and rate limiting;
• network-flow logging and anomaly detection;
• hardened images, patching and vulnerability scanning;
• container isolation and restricted runtime privileges.

Segmentation should reflect trust and data sensitivity. A production inference service should not automatically reach a development database. Administrative interfaces should be separated from public endpoints. Network controls must be tested because an overly permissive rule can silently defeat an otherwise strong IAM design.

Availability is also a security concern. Capacity limits, autoscaling policies, queue controls and graceful degradation help defend against denial-of-service and runaway model-inference costs. Safety controls for generative-AI tools should restrict which external systems an agent can call and require confirmation for high-impact actions.

5. Secure Software and Model Supply Chains

An AI supply chain includes operating systems, libraries, container images, infrastructure-as-code modules, datasets, pretrained models, notebooks, build tools and deployment services. A secure lifecycle establishes provenance and verifies integrity at each stage.

Recommended practices include:

• maintain a software bill of materials (SBOM);
• pin and review dependency versions;
• scan dependencies and images for known vulnerabilities;
• use signed commits, artefacts and container images where feasible;
• build in isolated, reproducible environments;
• protect CI/CD identities and restrict pipeline permissions;
• separate build, approval and deployment roles;
• scan datasets and models for malware, licensing restrictions and suspicious content;
• record dataset versions, transformations, hyperparameters and model lineage;
• test models for quality, security, bias and performance before release.

A vulnerability scanner may report a known vulnerable library, but risk depends on exploitability, exposure, privileges and compensating controls. Conversely, an unreported vulnerability may still exist. Software composition analysis therefore needs patch governance and human review.

Model registries should enforce stages such as experimental, approved and production. Promotion should require evidence, an accountable approver and a rollback plan. For high-impact systems, cryptographic signing and tamper-evident audit records can help establish that the deployed model is the approved artefact.

6. Threat Modelling for Cloud AI

Threat modelling is a structured method for anticipating abuse before deployment. It is most effective when repeated throughout the lifecycle rather than performed as a one-time document exercise.

A practical process is:

1. Define scope, assets, users and trust boundaries.

2. Draw data-flow diagrams showing stores, processes, flows and external actors.

3. Identify threats using categories such as spoofing, tampering, repudiation, information disclosure, denial of service and elevation of privilege.

4. Estimate risk using likelihood and impact.

5. Select preventive, detective and corrective controls.

6. Assign owners, test controls and revisit assumptions.

A qualitative risk matrix is often sufficient at bachelor level. For example, classify likelihood and impact as low, medium or high, then prioritise high-likelihood/high-impact threats. Numerical scores can support consistency, but they are not objective measurements unless definitions and evidence are clear.

For AI systems, ask additional questions: Can training data be altered? Can prompts cause unauthorised tool use? Can outputs reveal sensitive records? Can an attacker extract the model? What happens if the model is unavailable or confidently wrong? Which human decision-maker remains accountable?

7. Privacy Engineering

Security protects systems against unauthorised actions; privacy governs the appropriate collection, use, disclosure and retention of information about people. A dataset can be securely stored and still be used unfairly or for an undisclosed purpose.

Privacy engineering begins with purpose specification and data minimisation. Collect only what is needed, retain it for a justified period, and separate identifying fields from analytical data where practical. Maintain data inventories, classification labels, lineage and records of processing. Conduct privacy impact assessments for high-risk processing.

Important techniques include:

• Pseudonymisation: replacing direct identifiers with tokens. It reduces casual exposure but remains personal data if re-identification is possible.
• Anonymisation: transforming data so that individuals are not reasonably identifiable under the relevant context. It is difficult to guarantee, especially when datasets can be joined.
• Aggregation: reporting groups rather than individual records, while guarding against small-cell disclosure.
• Access controls and purpose limitation: ensuring that authorised access is still limited to the stated purpose.
• Differential privacy: adding calibrated randomness so that the presence or absence of one person has limited effect on published results. Stronger privacy generally reduces utility, and privacy parameters must be selected and documented.
• Federated learning: training across distributed data without centralising raw records. It does not eliminate privacy risk because updates may leak information and participants may be compromised.
• Confidential computing: protecting data during processing in hardware-supported trusted execution environments, subject to implementation and side-channel limitations.

Privacy rights and obligations depend on jurisdiction and context. Common requirements include lawful and transparent processing, data-subject rights, security safeguards, breach response, purpose limitation, retention controls and restrictions on international transfers. Organisations must obtain qualified legal guidance rather than treating a technical control as proof of compliance.

8. Responsible AI Controls

Responsible AI extends security and privacy to the effects of automated systems on people and institutions. Core dimensions include fairness, transparency, explainability, safety, robustness, human oversight, accountability and environmental responsibility.

Controls should be connected to the risk of the use case. A recommendation engine and an automated loan-decision system do not require identical governance. A high-impact system may require documented intended use, prohibited uses, representative evaluation data, subgroup performance analysis, human review, appeal mechanisms and continuous monitoring.

Fairness analysis must examine the relevant population and decision context. Accuracy alone can hide unequal error rates. However, many fairness criteria cannot all be satisfied simultaneously when group base rates and error structures differ. Therefore, teams must justify the selected measures and involve affected stakeholders rather than claiming that one metric proves fairness.

Transparency includes communicating that AI is being used, describing its purpose and limitations, and documenting data and model provenance. Explainability techniques can support debugging and communication, but an explanation generated after the fact does not guarantee that the model used valid reasoning. Human oversight must be meaningful: reviewers need authority, information, time and training to challenge or stop the system.

Operational controls include model cards, dataset documentation, incident reporting, red-team testing, content filters, confidence thresholds, fallback procedures, audit logs and post-deployment monitoring. Generative-AI systems additionally require prompt and output testing, protection against prompt injection, retrieval-source controls, safeguards against sensitive-data disclosure and clear boundaries on autonomous actions.

9. Worked Application: A Cloud-Based Clinical Risk Service

The following is an illustrative case, not a description of a real organisation.

Background and problem

A hospital network plans a cloud service that predicts whether a recently admitted patient may require intensive monitoring. It uses electronic health records, laboratory results and clinical notes. The service must support rapid decisions while protecting highly sensitive health information.

Analysis

Assets include patient data, trained models, clinician identities, prediction outputs, audit records and the availability of the service. Threats include stolen credentials, excessive analyst access, poisoned training data, insecure vendor connections, model extraction, ransomware and biased performance across demographic groups. Trust boundaries exist between hospital systems, the cloud environment, the model endpoint and clinicians’ devices.

Approach and solution

The design uses federated identity with multifactor authentication for clinicians and short-lived workload identities for services. A service account can read only the approved feature set and write only to its designated output location. Development and production are separate projects, and production data is inaccessible from development.

Data is encrypted in transit and at rest using managed keys with restricted administrative access and audited use. Secrets are held in a vault. Private service connectivity, egress filtering and API rate limits reduce exposure. The CI/CD pipeline produces signed containers, records an SBOM and requires independent approval before production deployment. Dataset versions and model lineage are stored in the registry.

A privacy assessment establishes the purpose, retention period and access process. Direct identifiers are separated from modelling features where possible. Access logs are reviewed, and a tested process handles data-subject requests and incidents. Model evaluation reports sensitivity, specificity and calibration across clinically relevant groups; clinicians retain final decision authority. The interface displays limitations and requires review rather than presenting a prediction as a diagnosis.

Outcome

The service has a smaller blast radius, clearer accountability and evidence for security and governance review. Monitoring detects unusual access, data drift and subgroup performance degradation. If the endpoint fails, clinicians use an established manual procedure. The design does not eliminate risk: clinical data can still be misinterpreted, models can drift and privacy may be threatened by linkage with other data. These residual risks are documented and periodically reassessed.

Learning points

Security controls must be aligned with the workflow, not added after deployment. Privacy, safety and fairness are system properties involving people and processes. Least privilege, provenance, human oversight and recovery planning are as important as encryption.

10. Challenges, Limitations and Professional Practice

Cloud security is difficult because convenience encourages broad permissions, managed services obscure technical details and rapid AI experimentation outpaces governance. Excessive compliance checklists can produce documentation without real assurance. Conversely, rigid controls can prevent legitimate research or encourage teams to bypass approved platforms.

Controls also have trade-offs. Strong encryption can complicate search and recovery; aggressive data minimisation may reduce model performance; privacy noise can reduce statistical utility; continuous monitoring generates cost and may itself collect sensitive information. Fairness metrics can conflict, and explainability methods may be unstable. Security testing cannot prove the absence of all vulnerabilities.

Professionals should adopt defence in depth, automate repeatable checks, document assumptions, test failure modes and involve security, privacy, legal, domain and affected-user stakeholders. They should distinguish compliance evidence from actual risk reduction. Incident response plans must include containment, credential revocation, model rollback, notification decisions, forensic preservation and communication with users.

11. Contemporary Developments

Current cloud AI practice is increasingly shaped by confidential computing, identity-aware service meshes, policy-as-code, software and model attestations, privacy-preserving analytics, AI red teaming and automated governance evidence. Generative-AI agents create particular concern because they combine untrusted language input with tools that can alter data or take external actions. Least privilege, explicit tool permissions, sandboxing, output validation and human confirmation are therefore essential.

Regulatory frameworks and standards increasingly emphasise risk management, documentation, transparency, security and accountability. Organisations should map controls to applicable laws, contractual commitments and recognised frameworks, while recognising that standards support—not replace—professional judgement.

Chapter Summary

Cloud AI security is a lifecycle responsibility governed by the shared-responsibility model. IAM should use least privilege, strong authentication, separation of duties and short-lived workload identities. Zero trust verifies each request and limits blast radius rather than trusting network location. Encryption protects data at rest, in transit and, with specialised technologies, in use; effective key and secrets management is equally important.

Network segmentation, private connectivity, egress control, monitoring and resilient operations reduce exposure. Secure supply chains require dependency control, provenance, signing, SBOMs, protected CI/CD and model lineage. Threat modelling identifies assets, trust boundaries, attack paths and appropriate controls. Privacy engineering applies minimisation, purpose limitation, retention, access governance and techniques such as pseudonymisation and differential privacy, while recognising their limitations.

Responsible AI requires context-sensitive controls for fairness, transparency, robustness, safety, human oversight and accountability. High-impact systems need documented purposes, subgroup evaluation, monitoring, appeal and fallback procedures. The strongest designs integrate technical controls with governance, professional judgement and continuous reassessment.

Key Terms

IAM: Identity and access management; controls identities and permissions.

Least privilege: Granting only the access necessary for an approved task.

Zero trust: Security model that verifies every request rather than trusting network location.

Workload identity: An identity assigned to an application, service or computational job.

Encryption at rest: Protection of stored data using cryptography.

Envelope encryption: Encrypting data with a DEK and protecting that DEK with a KEK.

Key-management service: Managed system for controlling cryptographic keys.

Secrets management: Secure storage, retrieval, rotation and auditing of credentials and tokens.

Network segmentation: Dividing a network to restrict movement between components.

Supply chain: Components and processes used to build and operate software or models.

SBOM: Software bill of materials listing software components and dependencies.

Threat modelling: Structured identification and treatment of security threats.

Trust boundary: A point where data or control crosses between different trust levels.

Pseudonymisation: Replacing identifiers with tokens while retaining possible reversibility.

Differential privacy: Privacy framework limiting the effect of one person’s data on results.

Model inversion: Attempt to infer sensitive training information from model behaviour.

Data poisoning: Manipulating training data to influence model behaviour.

Responsible AI: Development and operation of AI consistent with safety, fairness, transparency and accountability.

Model drift: Change in data or relationships that reduces deployed-model performance.

Review Questions

Short Answer Questions

1. What is the shared-responsibility model in cloud security?

2. State two principles of zero-trust architecture.

3. Distinguish encryption at rest from encryption in transit.

4. Why should secrets not be stored in source code?

5. What is the purpose of an SBOM?

Long Answer Questions

1. Explain how IAM and zero trust can be combined in a cloud-based ML platform.

2. Describe the lifecycle of cryptographic keys and the role of envelope encryption.

3. Discuss the major stages of threat modelling for an AI workload.

4. Compare pseudonymisation, anonymisation and differential privacy.

5. Explain how responsible-AI controls should be adapted to high-impact applications.

Analytical / Application Questions

1. Design security controls for a cloud pipeline that moves sensitive data from storage through training to a public inference endpoint. Justify each control.

2. A model performs well overall but has substantially higher false-negative rates for one demographic group. Analyse possible causes and propose technical and governance responses.

3. A generative-AI agent can read internal documents and call a ticketing system. Construct a threat model and recommend controls that prevent prompt injection from causing unauthorised changes.

Multiple Choice Questions with Answers

Question 1

Which principle requires an AI training job to receive only the permissions needed for its specific task?

A. Least privilege

B. Network neutrality

C. Data duplication

D. Open federation

Correct Answer: A. Least privilege

Question 2

What is the primary purpose of a key-encryption key in envelope encryption?

A. To replace all authentication mechanisms

B. To encrypt the data-encryption key

C. To compress the plaintext dataset

D. To make network traffic anonymous

Correct Answer: B. To encrypt the data-encryption key

Question 3

Which statement best describes zero trust?

A. Internal network traffic is always trusted

B. Only external users must authenticate

C. Every request is evaluated using identity, policy and context

D. Encryption is unnecessary inside a private network

Correct Answer: C. Every request is evaluated using identity, policy and context

Question 4

Which artefact lists software components and dependencies in a build?

A. Model card

B. SBOM

C. Risk matrix

D. Data-retention schedule

Correct Answer: B. SBOM

Question 5

Why is pseudonymised data not necessarily anonymous?

A. It cannot be encrypted

B. The original person may be re-identified using additional information

C. It always contains passwords

D. It cannot be stored in the cloud

Correct Answer: B. The original person may be re-identified using additional information

Question 6

Which is an example of training-data poisoning?

A. Rotating a database key

B. Adding malicious records intended to alter model behaviour

C. Segmenting a virtual network

D. Signing a container image

Correct Answer: B. Adding malicious records intended to alter model behaviour

Question 7

Which control most directly limits an AI agent’s unauthorised external actions?

A. Unlimited tool permissions

B. Explicit tool permissions and human confirmation for high-impact actions

C. Removing all audit logs

D. Disabling identity verification

Correct Answer: B. Explicit tool permissions and human confirmation for high-impact actions

Question 8

What does an SBOM primarily support?

A. Dependency visibility and vulnerability management

B. Automatic fairness certification

C. Guaranteed model accuracy

D. Physical building security

Correct Answer: A. Dependency visibility and vulnerability management

Question 9

Which statement about differential privacy is correct?

A. It guarantees perfect anonymity in every context

B. It adds calibrated randomness and may reduce utility

C. It eliminates the need for access control

D. It applies only to network packets

Correct Answer: B. It adds calibrated randomness and may reduce utility

Question 10

What is a key feature of a responsible-AI control for a high-impact system?

A. No human review under any circumstances

B. Documented purpose, subgroup evaluation and an appeal or fallback process

C. Unrestricted collection of all available data

D. Deployment without monitoring

Correct Answer: B. Documented purpose, subgroup evaluation and an appeal or fallback process