Where AI runs - the cloud, from scratch

In the cloud you rent capability instead of owning machines, and every action is an API call gated by an identity - which is exactly why cloud security and AI security are one conversation.

This is the cloud course for someone who is not a cloud person but has to discuss it confidently, and it ends at section 8 with the map of what an AI system actually connects to. Read it once and you can hold your own in any AI-system assessment conversation. The throughline: in the cloud you rent capability instead of owning machines, and everything is an API call gated by an identity - which is exactly why cloud and AI security are the same conversation.

At a glance

• There is no perimeter to defend - everything is reached over the internet through APIs and consoles, so misconfiguration is the breach.
• Almost every cloud and AI-agent breach traces back to IAM (Identity and Access Management): an over-permissive role, a leaked key, or a workload with more access than its task needs. It is the spine.
• The shared responsibility line shifts by service model, yet your data and your identity config stay yours at every layer - and that is where the incidents are.

First, the intuition - what the cloud really is and why everyone uses it

Forget the diagrams for a moment. The cloud is renting computing instead of buying it. Instead of an organization buying servers, racking them in a room, powering and cooling and patching them, it rents exactly what it needs from a provider’s enormous data centers and pays by the hour or by usage. Need a hundred GPUs for a training run this afternoon and zero tomorrow? You rent them for the afternoon. That elasticity - plus not owning the hardware headache - is the whole reason the world moved.

A useful analogy: owning servers is owning a car (you buy it, maintain it, it sits idle most of the day); the cloud is ride-hailing (you summon exactly the capacity you need, when you need it, and it’s someone else’s job to keep the fleet running). For a security tester, the consequence is profound: there is no perimeter you can walk around and no server room you can lock. Everything is reached through APIs and consoles over the internet, and the only thing standing between an attacker and a resource is its configuration and its identity controls. That’s why, in the cloud, misconfiguration is the breach - there’s no firewall-and-moat to fall back on. Hold that intuition; the rest of this course is just detail hung on it.

1 · What “the cloud” actually is

Someone else owns the data center, the servers, the power, and the network; you rent slices of it on demand and pay for what you use. You never see the hardware - you interact with everything through web consoles, command-line tools, and APIs. The three giants: AWS (the largest, broadest service catalog), Microsoft Azure (deepest enterprise/Microsoft integration; hosts OpenAI models via the Azure OpenAI service, though OpenAI also offers its own direct API), and Google Cloud / GCP (strongest AI/ML and data analytics). You’ll meet all three; the concepts below are identical across them, only the names differ.

2 · The five things you rent

Building block	What it is	AWS / Azure / GCP name
Compute	Virtual machines / GPUs that run your code or model	EC2 / Virtual Machines / Compute Engine
Storage	Object storage for files, data, model weights	S3 / Blob Storage / Cloud Storage
Database	Managed relational & NoSQL stores	RDS·DynamoDB / SQL·Cosmos / Cloud SQL·Firestore
Networking	Private virtual networks, load balancers, the perimeter	VPC / VNet / VPC
Identity (IAM)	Who/what can do what - the control plane for everything	IAM / Entra ID / Cloud IAM

Layered by how much you manage: IaaS (you rent raw VMs and run everything on them), PaaS (you deploy code/models onto a managed platform), SaaS (you just use a finished app). Newer layers matter for AI: serverless (functions that run on demand, no server to manage - AWS Lambda) and containers/Kubernetes (packaged apps that scale - where most model-serving lives).

3 · IAM - the one concept to truly understand

If you learn one thing, learn this. Identity and Access Management decides which identity (a user, or a non-human workload like an app or agent) can perform which action on which resource. Its vocabulary: principals (the identity), roles/policies (what they’re allowed), credentials (keys or tokens proving identity), and the principle of least privilege (grant only what’s needed). Almost every cloud breach - and almost every AI-agent breach - is fundamentally an IAM failure: an over-permissive role, a leaked long-lived key, or a workload with far more access than its task requires. For agents this is the non-human-identity problem in IV.6 · Agent identity & access (NHI), and it’s why IAM is the spine of the threat model (VI.3 · Threat modeling for AI systems).

4 · The shared responsibility model

The single most-asked cloud-security question, so know it cold: the provider secures the cloud itself (hardware, the data center, the core infrastructure - “security of the cloud”); you secure what you put in it (your data, your access config, your code, your IAM - “security in the cloud”). The exact line shifts with the service model - with SaaS the provider owns more, with IaaS you own more - but your data and your identity config are always yours. Most cloud incidents are customer-side misconfigurations, not provider failures.

The customer-side misconfigurations that recur, in order of how often they land as findings:

Customer-side misconfigurations that are the breach

1. Public object storage     - S3 bucket / Blob container / GCS bucket world-readable
2. Over-permissive IAM       - wildcard actions ("Action": "*") or admin on a workload role
3. Long-lived keys           - static access keys in code, CI, env vars, or agent memory
4. IMDSv1 reachable          - metadata-service credential theft via SSRF (enforce IMDSv2)
5. Unauthenticated endpoint  - serving API or vector DB exposed with no auth
6. Missing/ignored logs      - CloudTrail off, or no one reading it

Every item is “security in the cloud” - yours, not the provider’s - which is why they show up in V.2 · Cloud security & red-teaming and V.3 · The data layer.

5 · Where AI lives - the cloud AI stack in three layers

Providers package AI at three heights, and knowing which one a client uses tells you the attack surface immediately:

• Foundation-model APIs (top, easiest). Call a hosted model, manage nothing. Amazon Bedrock (multi-model marketplace - Anthropic, Meta, Amazon Nova), Azure OpenAI Service (OpenAI models via Azure), Google Vertex AI (Gemini + others). The surface here is the connections (keys, prompts, data, tools), not the model.
• ML platforms (middle). Build, train, deploy your own models: SageMaker (AWS), Azure ML, Vertex AI. Add MLOps pipelines, feature stores, and the supply-chain surface of I.5 · The model artifact & its supply chain.
• Raw infrastructure (bottom). Rent GPUs/TPUs and run your own serving stack (vLLM, Triton). Custom AI silicon now matters and moves fast - name the current generation: AWS Trainium3 (GA Dec 2025, Trainium4 announced), Google TPU v7 Ironwood, and Azure Maia 200 (Jan 2026). For a tester the relevance is supply chain and tenancy: custom accelerators run bespoke drivers/firmware and multi-tenant scheduling, so the isolation and driver surface differ from stock NVIDIA (I.5 · The model artifact & its supply chain).

2026 additions you should name-drop: provider guardrails (Bedrock Guardrails, Azure AI Content Safety, Vertex AI safety controls) and production agent runtimes - Amazon Bedrock AgentCore (GA October 2025, incl. ap-southeast-1) with A2A agent-to-agent messaging, session isolation, and VPC/PrivateLink; also Azure AI Foundry Agent Service and Vertex AI Agent Engine. These runtimes are themselves an attack surface: the A2A trust boundary, session-isolation escape, and the runtime’s own IAM role - where the agentic-security conversation (IV.1 · Model APIs & the tool-use loop-III.3 · Browser & computer-use agents) meets the cloud.

flowchart TB
  subgraph YOURS["YOU secure - security IN the cloud"]
    APP["Your AI app + agent logic + prompts"]
    DATA2["Your data, RAG corpus, vector DB"]
    CFG["Your IAM config, keys, network rules"]
  end
  subgraph SVC["Service layer (responsibility shifts by model)"]
    FM["Foundation-model API · Bedrock / Azure OpenAI / Vertex"]
    ML["ML platform · SageMaker / Azure ML / Vertex"]
  end
  subgraph PROV["PROVIDER secures - security OF the cloud"]
    INFRA["Physical data center · hardware · core network · hypervisor"]
  end
  APP --> FM --> INFRA
  DATA2 --> ML --> INFRA
  CFG -. gates everything .- APP
  classDef y fill:#1d1708,stroke:#e4a23f,color:#f0d8a8;
  classDef s fill:#0f1a18,stroke:#5bd1c5,color:#bdeee2;
  classDef p fill:#11151a,stroke:#8fb9ff,color:#cdd9f5;
  class APP,DATA2,CFG y; class FM,ML s; class INFRA p;

The amber layer is always your responsibility - your data, your config, your identity. That’s where you focus a test, because that’s where the incidents are.

5b · Hybrid & multi-cloud - the real-world shape

Almost no large organization - and certainly no Singapore government agency - runs on one clean cloud. The real estates are hybrid and multi-cloud, and the seams between environments are where much of the risk lives.

• Hybrid cloud - on-premises data centers connected to public cloud. Common when data residency, legacy systems, or sovereignty rules keep some workloads on-prem while new AI/analytics run in the cloud. The connection (VPN or dedicated link - AWS Direct Connect, Azure ExpressRoute, GCP Interconnect) is itself a trust boundary and an attack path.
• Multi-cloud - using two or more providers at once (e.g. core systems on Azure via the Microsoft relationship, AI/data on GCP, something else on AWS). Driven by best-of-breed choices, resilience, and avoiding lock-in.
• Sovereign / government cloud - providers run isolated regions for government data residency and compliance; in Singapore, agencies consume commercial cloud through GovTech’s central arrangements under the Government on Commercial Cloud (GCC) model. Expect strict residency, segregation, and audit requirements.

Why the seams matter for testing

Hybrid and multi-cloud multiply the surface in specific ways: identity federation (one identity provider trusted across clouds - compromise it once, move everywhere), inconsistent controls (a policy enforced on AWS but forgotten on GCP), the on-prem↔cloud link as a pivot path in either direction, data in transit across provider boundaries, and fragmented visibility (no single audit log - your detection in VII.3 · Detection, IR & forensics for AI has blind spots between clouds). When you scope an engagement, map every environment and especially every connection between them; the forgotten cross-cloud trust is the classic high-impact finding. An AI system frequently spans the seam - model API on one cloud, data lake on another, on-prem source systems feeding the RAG corpus - so its blast radius crosses boundaries too.

6 · The vocabulary that makes you sound fluent

• Region / availability zone - geographic location of resources (matters for data residency / PDPA).
• VPC / subnet / security group - your private network and its firewall rules.
• Public vs private endpoint - whether a service is reachable from the internet (the exposed-endpoint risk in V.2 · Cloud security & red-teaming).
• Managed service - the provider runs it; you configure and consume it.
• Infrastructure as Code (IaC) - Terraform/CloudFormation defining infra as files (so misconfig is reviewable and repeatable).
• Secrets manager - the right place for keys/tokens (never in prompts, code, or agent memory - IV.6 · Agent identity & access (NHI)).
• Egress - outbound traffic; restricting it is how you blunt SSRF (Server-Side Request Forgery) reads of the metadata service and data exfil - the full attack in V.2 · Cloud security & red-teaming.
• Zero trust - never trust by network location; verify every request’s identity (Google BeyondCorp is the canonical example).
• Hybrid / multi-cloud - on-prem + cloud, or several providers at once; the seams between them are prime attack surface.
• Identity federation - one identity provider trusted across environments (SSO/SAML/OIDC); a single high-value target.
• Landing zone - a pre-configured, governed baseline account/subscription structure an org rolls out for consistent security across the estate.

7 · A first assessment starter

You now have the map; here is the minimum toolchain to read a cloud estate you are authorized to test. Nothing below is exotic - it is the standard, still-maintained cloud-assessment stack, plus the single highest-value primitive: enumerating the instance metadata service (IMDS), the mechanism behind most cloud-to-agent credential theft via SSRF.

Cloud posture starter - authorized assessment only

# Read-only posture scan of an account you are authorized to test.
# Prowler: ~600 checks, 44 compliance frameworks, active in 2026.
prowler aws --profile <assessment-profile> \
  --services iam s3 ec2 bedrock sagemaker \
  --output-formats html,json-ocsf --output-directory ./prowler-out

# CloudFox: enumerate exploitable paths (exposed endpoints, role trust, secrets).
cloudfox aws --profile <assessment-profile> all-checks

# The metadata-service angle (IMDS) - how an SSRF in an AI app steals the
# instance/pod role credential. Demonstrate on YOUR OWN test host only:
curl -H "X-aws-ec2-metadata-token: <token>" \
  http://169.254.169.254/latest/meta-data/iam/security-credentials/<role>

Caution

Run these only against accounts and hosts you are explicitly authorized to assess. IMDSv2 (token-required) blocks the naive SSRF read - confirm it is enforced; IMDSv1 being reachable is itself the finding. (ScoutSuite is deliberately omitted here - unmaintained since 2024; prefer Prowler and CloudFox.)

First 15 minutes of any AI-system scoping call

Ask and record, in order:

1. Which layer? Foundation-model API, ML platform, or raw serving (vLLM/Triton on GPUs)?
2. Which provider(s) and regions? One cloud, hybrid, or multi-cloud - and where does data reside (PDPA/residency)?
3. What identity gates the model call? Long-lived key, IAM role, or workload identity/OIDC federation? Where is it stored (secrets manager vs env var vs prompt)?
4. What can the agent reach? Tools/MCP servers, and the scope of each credential behind them (IV.2 · Model Context Protocol (MCP)).
5. Where is the data? Object store, warehouse, vector DB - and is any endpoint public (V.3 · The data layer)?
6. What logs exist across the seams? CloudTrail/Activity Log/Audit Logs - and the blind spots between clouds (VII.3 · Detection, IR & forensics for AI).

The answers hand you the threat model (VI.3 · Threat modeling for AI systems).

How this connects to the rest of the playbook

The cloud isn’t a side topic - it’s the substrate. V.2 · Cloud security & red-teaming tests the infrastructure layer, I.5 · The model artifact & its supply chain the supply chain on it, V.3 · The data layer the data layer (vector DBs, lakes) it holds, IV.6 · Agent identity & access (NHI) the IAM/identity that gates it, and VI.3 · Threat modeling for AI systems puts the whole wiring at the center of the threat model. When a client describes their AI system, your first move is to translate it into this map - which service layer, which data stores, which IAM roles, which network exposure - and the vulnerabilities suggest themselves.

8 · What an AI system actually connects to

Almost every AI system lives in the cloud, and it is the connections between it and cloud services - not the model itself - that carry most of the real risk.

Sections 1 to 7 covered the cloud as a general system. This one narrows to the shape an AI application actually takes, because that is what you assess.

Start from where the model API sits in the three service models from section 2: a managed model API (OpenAI, Anthropic, Bedrock, Vertex) is effectively SaaS or PaaS - you send prompts, you do not run the model. That convenience is exactly why the connections - keys, data flows, tool access - become the surface rather than the model’s internals (V.2 · Cloud security & red-teaming, I.5 · The model artifact & its supply chain, V.3 · The data layer).

flowchart TB
  U["User / client"] --> APP["AI application<br/>(orchestration + agent logic)"]
  APP --> API["Model API / serving<br/>OpenAI · Bedrock · Vertex · self-hosted"]
  APP --> VDB[("Vector DB<br/>RAG store")]
  APP --> DATA[("Data lake / warehouse<br/>S3 · Snowflake · BigQuery")]
  APP --> TOOLS["Tools / MCP servers<br/>APIs · functions"]
  IAM["Cloud IAM<br/>roles · keys · tokens"] -. governs .- APP
  IAM -. governs .- VDB
  IAM -. governs .- DATA
  IAM -. governs .- TOOLS
  class IAM focus;

The AI app is the hub; everything it touches - the model, the vector store, the data lake, the tools - is a cloud connection mediated by IAM (identity and access management). Each arrow is an attack surface, and each is only as safe as the credential behind it.

The pieces it connects to

• Compute & serving - where the model runs or is called from (V.2 · Cloud security & red-teaming).
• Object storage & data lakes/warehouses - S3, Snowflake, BigQuery holding training/RAG data (V.3 · The data layer).
• Vector databases - the RAG retrieval store (V.3 · The data layer).
• Tools & MCP servers - the APIs and functions an agent can call to act (IV.1 · Model APIs & the tool-use loop, IV.2 · Model Context Protocol (MCP)).
• IAM - the identity-and-access layer (roles, keys, short-lived tokens) that gates all of the above. For agents, this is the non-human-identity problem (IV.6 · Agent identity & access (NHI)), and over-broad IAM is a leading way a small AI bug becomes a big breach.

Why this matters for testing

The recurring failure mode isn’t exotic: an exposed serving endpoint or vector DB with no auth, an over-permissive role on the data lake, or an agent holding a standing key far broader than its task needs. When you assess an AI system, map these connections first - the cloud wiring is the threat model’s backbone (VI.3 · Threat modeling for AI systems), and the controls are least-privilege IAM, network segmentation, and scoped short-lived credentials (V.2 · Cloud security & red-teaming, I.5 · The model artifact & its supply chain, IV.6 · Agent identity & access (NHI)).

Machine identity - the gate on “action out”

Humans log in with a password and MFA; machines and agents authenticate with a secret - a long-lived API key, or, better, a short-lived token minted on demand. The modern shape is OAuth 2.x scopes (a token that can do only these actions) and workload identity (a token bound to the running workload - an instance or pod role fetched from the metadata service - so there is no static key to steal). The rule that falls out is the one to remember: an agent’s blast radius equals the identity behind it - the worst an injected instruction can achieve is bounded by that token’s scope and lifetime. That is why “non-human identity” (NHI) is its own discipline (IV.6 · Agent identity & access (NHI)): scope it narrow, expire it fast, and pass the user’s authority on-behalf-of rather than hand the agent a standing super-credential.

9 · Map the connections

The map above is only useful if you can turn it into a check. On an authorized target, the fastest first pass is to ask which arrows are reachable without a credential - an exposed serving endpoint, an unauthenticated vector store, or an over-broad identity behind the app.

Map the connections - is any endpoint exposed? (authorized targets only)

# 1. Public serving / model endpoints an org forgot to lock down.
nuclei -u https://<ai-app-host> \
  -tags exposure,misconfig -severity medium,high,critical

# 2. Vector DB / RAG store reachable without auth (classic finding).
#    Weaviate / Qdrant / Chroma default ports, unauthenticated:
curl -s http://<vector-db-host>:8080/v1/schema        # Weaviate
curl -s http://<vector-db-host>:6333/collections      # Qdrant

# 3. Which identity is behind the app? Enumerate the caller's own perms.
aws sts get-caller-identity --profile <assessment-profile>

Each line maps to one arrow in the diagram: serving endpoint, data/RAG store, IAM. Depth lives in V.2 · Cloud security & red-teaming and V.3 · The data layer.