Learn / Securing model and agent workloads on cloud platforms

Securing model and agent workloads on cloud platforms

Applying cloud security controls, identity boundaries and monitoring to model and agent workloads on AWS, Azure and GCP.

28 of 48postings ask for it (58%)

AI Security Consultant80%of 5 AI Security Architect71%of 7 AI Security Engineer69%of 16 AI Red Teamer44%of 9 AI Governance and Risk Lead43%of 7 AI Security Researcher25%of 4

Researched on 2026-09-26 with AI assistance. Links and summaries can change; verify details with the original source. Not yet reviewed by a person.

What it is

It is the work of putting normal cloud security controls (identity and access management, data protection, network isolation, logging, threat modelling) around model endpoints, training jobs, retrieval stores and agent runtimes. AWS makes the point that a generative AI workload is still a data-driven cloud workload and inherits the same security regimen, with extra model-specific risks on top.¹

The first step is scoping: deciding whether you consume a third-party app, call a managed model API, fine-tune a hosted model, or train your own, because each option shifts how much of the stack you are responsible for securing.¹

Concretely it means service-level decisions you can point at in a console: private endpoints and disabled public network access, platform identity instead of API keys, and policy-based compliance monitoring, as set out in the Azure security baseline for Azure OpenAI.²

Google's SAIF frames the same idea as extending existing security foundations to AI, pulling AI into detection and response, and harmonising platform-level controls so protection is consistent across the estate rather than per project.³

Why postings ask for it

28 of 48 postings (58%) ask for it, and it is heaviest where someone owns a running system: AI/Agent Security Engineer 69% of 16 postings, AI Security Architect 71% of 7, Consulting 80% of 5.^P

Agentic deployments add attack surface, privilege creep and obscure event records, so employers need people who can scope agent permissions narrowly, start with low-risk use cases, and fold agents into the existing security model.^P⁵

Even the lower-demand clusters (Red Team 44% of 9 postings, GRC 43% of 7) touch it, because red teamers need cloud identity paths to show real impact and GRC leads must evidence controls against frameworks such as the CSA AI Controls Matrix, which maps to ISO 42001 and ISO 27001.^P⁷

Concepts you should be able to explain

If you can say each of these out loud in two minutes, with an example, you are ready for the technical part of an interview on this skill.

Scoping and shared responsibility

Before choosing controls, classify the workload: consumer app, enterprise app with AI features, managed model API, fine-tuned model, or self-trained model. AWS built its Generative AI Security Scoping Matrix around this because the provider takes more of the management burden at one end and you take almost all of it at the other. Scope determines who owns model weights, training data and the host operating system.¹

Identity boundary for model endpoints

Model endpoints accept either platform identity or long-lived keys. The Azure OpenAI baseline notes that Entra ID authentication for data plane access is on by default, while local key authentication is also supported and is the customer's responsibility to disable. Removing keys in favour of managed identities kills the most common credential-leak path and gives you per-caller audit trails.²

Network isolation of AI services

The Azure OpenAI baseline states the service can be deployed into a customer virtual network, supports Private Link and supports disabling public network access, but none of these are enabled by default. The stated pattern is deny all traffic first, then allow specific subnets or IP ranges. The same shape applies on other clouds: an inference endpoint reachable from the internet is a different risk than one reachable from one subnet.²

Tenant isolation and untrusted model code

Models are code. Wiz Research uploaded a malicious model to a shared inference service and used container escape to break out of its own tenant, and separately found a shared CI/CD takeover path; pickle-format models can carry remote code execution payloads. Wiz argues AI services are especially exposed to tenant isolation bugs because they exist to run user-supplied models. If you host models for others, or pull models from a hub, treat the artefact as untrusted input.⁹¹⁰

Agent permissions and privilege creep

CISA and international partners list expanded attack surface, privilege creep, behavioural misalignment and obscure event records as the core risks of agentic AI. Their recommendations are to avoid broad or unrestricted access to sensitive data and critical systems, begin with low-risk use cases, and account for agentic AI in the organisation's security model and risk posture. In cloud terms that means one narrow role per agent action, not one role that can do everything the agent might ever need.⁵

Indirect prompt injection as a trust boundary problem

Greshake and colleagues showed that when an LLM application retrieves content (web pages, documents, emails), an attacker can plant instructions in that content and override the application's own instructions without ever prompting the model directly. For cloud work this means retrieved data is untrusted input that crosses into a component holding cloud credentials and tool access. Mitigation is architectural: separate the identity used to read data from the identity used to act.¹¹

Tool and protocol surface (MCP, A2A)

Agent workloads now connect tools and other agents through protocols such as the Model Context Protocol and Agent-to-Agent, which standardise integration but were designed for interoperability first. A 2026 preprint reports scanning roughly 2,000 MCP servers and finding none verified agent identity, and argues neither MCP nor A2A verifies identity by itself. Authentication, egress control and audit therefore have to come from the surrounding cloud platform.¹⁴¹⁶

Model extraction against exposed APIs

Tramer and colleagues showed that black-box query access to a prediction API is enough to extract near-equivalent copies of hosted models, and a later survey catalogues the attack families and defences for machine-learning-as-a-service. Practically, an unauthenticated or unmetered inference endpoint is an intellectual property and privacy exposure, so quotas, per-principal rate limits and query logging are security controls, not just cost controls.¹²¹³

Use fictional data and authorised sandboxes. Remove employer details and secrets from any portfolio write-up. Time estimates exclude setup. Check model and cloud costs before running tests, set spending limits, and delete lab resources afterwards.

Three exercises

In order of difficulty. Free tools. Keep what you build; it is evidence.

1Scope and baseline one model workloadabout 3 h

A one-page control sheet that states the scope of a chosen AI workload and the identity and network settings you would change from default, with a citation for each.¹²³

Pick a real or plausible workload and place it in the AWS Generative AI Security Scoping Matrix, writing down what the provider owns and what you own.
Read the Azure OpenAI baseline sections on network security and identity management and list every feature marked as customer responsibility.
Decide, for your workload, whether local key authentication stays on and whether public network access stays on, and write the reason.
Add the SAIF element 'extend detection and response' as a row: name the logs you would send to your SIEM.
Finish with three open questions you would put to the platform team.

Tools: text editor, provider documentation

2Threat model an agent that holds cloud credentialsabout 6 h

A threat model showing how untrusted retrieved content reaches a component with cloud permissions, plus the specific permission and logging changes that break the chain.⁵⁶⁷¹¹

Sketch an agent that reads documents from object storage and calls two tools, and mark every trust boundary.
Use the indirect prompt injection paper to write two abuse cases where planted content redirects the agent's actions.
Apply the CISA agentic guidance recommendations: remove broad access, split roles per action, and name the event records that are currently missing.
Cross-check your mitigations against the OWASP Securing Agentic Applications Guide and note anything you missed.
Select the control objectives from the CSA AI Controls Matrix that an auditor would ask you to evidence, using the AI Customer role view.

Tools: text editor, diagram tool, CSA AICM spreadsheet download

3Run a cloud privilege-escalation scenario and retell it as an AI incidentabout 10 h

A walkthrough where you escalate privileges in a deliberately vulnerable AWS environment, then explain the same path as an attack on a model or agent workload.⁸⁹¹²¹⁵

Install CloudGoat with Terraform and the AWS CLI in a throwaway account, following the repository warnings about never deploying next to sensitive resources.
Run an easy scenario such as iam_enum_basic, record each enumeration and escalation step, then destroy the scenario.
Rewrite the path assuming the compromised role was attached to an inference endpoint or an agent runtime, and state what the attacker reaches.
Add the model-specific outcomes from the Wiz research (malicious model artefact, container escape, shared CI/CD) and from the model extraction work (query-based copying of the hosted model).
Name the detections and permission changes you would ship, and map each to the NIST AI 100-2 attack category it addresses.

Tools: CloudGoat, Terraform, AWS CLI, jq

Practice questions

Written from the concepts above, not collected from a named employer. Open one, answer it out loud, then tick the points you covered; the score stays in this browser.

A team wants to ship a chat feature on a managed model API next month. How do you scope your security work?Scoping and shared responsibility