Where the cloud services actually fit

AWS

Policy-as-code — AWS CloudFormation Guard (cfn-guard). An open-source policy-as-code tool and DSL. The CloudFormation best-practices guide states you can “integrate cfn-guard into your CI/CD pipelines to automatically validate templates against your policy rules before deployment”, and the Guard user guide is explicit that it validates “any JSON- or YAML-formatted structured data” — CloudFormation templates, change sets, JSON-based Terraform configuration, or Kubernetes configurations. Layer: infrastructure definitions. It reads your template. It has no concept of a tool manifest.

Posture — AWS Config with conformance packs. A conformance pack bundles Config rules plus remediation actions and deploys across an organisation, producing a percentage compliance score that is emitted to CloudWatch metrics for tracking over time. Custom rules can be written in the Guard DSL, so the same policy language covers preventative and detective checks. Layer: deployed resource configuration.

Vulnerabilities — Amazon Inspector via Amazon ECR enhanced scanning. Enhanced scanning integrates ECR with Inspector and lets you choose which repositories get “automatic, continuous scanning” and which get scan on push, covering both OS and programming-language package vulnerabilities. Get the EventBridge wiring right, because the two events are not the same event: Inspector emits one on initial scan completion (detail-type: "Inspector2 Scan") and, as new vulnerabilities appear against images it has already scanned, one per finding created, updated or closed (detail-type: "Inspector2 Finding"). A rule matching only Inspector2 Scan gets first-scan completions and silently misses every re-scan finding — so a gate built on continuous rediscovery needs the finding event too. Layer: image contents.

Runtime threat detection — Amazon GuardDuty Runtime Monitoring. A managed security agent that adds visibility into runtime behaviour — “file access, process execution, command line arguments, and network connections” — with coverage documented for Amazon EKS, Amazon ECS on AWS Fargate, and Amazon EC2. Layer: workload runtime, at the OS level.

Identity — IAM Access Analyzer custom policy checks. The one closest to an agent-relevant question, and the closest thing on this list to lesson three’s permission diff. Three checks run from the CLI or API and return PASS/FAIL, which is exactly what a pipeline needs: CheckNoNewAccess (does the updated policy grant access the reference policy does not?), CheckAccessNotGranted, and CheckNoPublicAccess. Layer: identity and permissions. Note the boundary carefully: it validates the IAM policy delta, not your agent’s tool inventory — a new tool that calls an already-permitted API is invisible to it.

Agent behaviour — Amazon Bedrock AgentCore Evaluations. The AWS-side answer to the checks a scanner cannot run: on-demand evaluation scores a specific session, optionally against ground truth supplied as ReferenceInputs (expected responses, expected tool trajectories, behavioural assertions), which AWS positions for CI/CD regression testing; online evaluation continuously samples live traffic from a CloudWatch log group. That is the eval-threshold and trajectory-assertion rows of your gate, managed.

Microsoft Azure

Policy-as-code — Azure Policy, deny effect. The mechanism is worth knowing precisely: for a Resource Manager mode, deny “prevents the request before being sent to the Resource Provider” and returns 403 (Forbidden); during evaluation of existing resources, matching resources are marked non-compliant. Layer: control plane / what may exist.

The agent-adjacent case, and it is a good one. Microsoft Foundry ships built-in Azure Policy definitions for model deployments: “Foundry model deployments should only use approved models” (parameters allowedPublishers and allowedAssetIds, effect Deny or Audit) and “Foundry model deployments should meet eligibility requirements” (denyPreviewModels, onlyAllowDirectFromAzure, both defaulting to false). Check the launch stage of the second one yourself before you depend on it: the Foundry how-to page's status table lists both as generally available, while the Azure Policy built-in reference still carries the eligibility definition as “[Preview]” at version 1.0.0-preview. Both are evaluated at deployment time; the model stays visible in the catalog but the Deploy action is disabled with the policy name and assignment id in the message.

Two details with direct consequences for a gate. First, asset IDs are matched as a prefix — azureml://registries/azure-openai/models/gpt-5 without a trailing slash also matches GPT-5.2 and GPT-5.4, so an allow-list that reads as pinned may not be. Second, new assignments “don’t apply instantly”: the docs say to wait at least 15 minutes, and non-compliant existing resources appear within an evaluation cycle typically up to 24 hours. A gate must therefore assert the resolved model id in its own manifest rather than trusting that a platform policy already constrained it. Layer: which model resource may be deployed — not what your agent does with it.

Posture, vulnerabilities and runtime — Microsoft Defender for Cloud / Defender for Containers. Documented as five domains: security posture management (continuous monitoring of cloud APIs, Kubernetes APIs and workloads, with misconfiguration recommendations); agentless vulnerability assessment of container-registry images, running containers and supported Kubernetes nodes, powered by Microsoft Defender Vulnerability Management; run-time threat protection for clusters, nodes and workloads with alerts mapped to MITRE ATT&CK for Containers and investigable in Defender XDR; software supply chain protection, where “you can use gated deployment rules to audit or block deployments when images don’t meet your organization’s vulnerability policy”; and deployment/monitoring of the sensors themselves. Note the capability model: image vulnerability assessment and posture assessment are agentless, while runtime threat detection requires in-cluster components.

That gated-deployment rule is the sharpest illustration of the whole lesson. It is a genuine blocking gate, evaluated on the artifact, enforcing a real policy — about CVEs in an image. It will happily promote a build whose system prompt lost its escalation rule.

Agent behaviour — Foundry evaluation and versioning. Foundry’s observability documentation describes built-in evaluators covering quality, RAG metrics such as groundedness, safety, and agent-specific metrics including tool-call accuracy and task completion; agents are versioned automatically as you iterate, and a published agent’s stable endpoint serves an administrator-selected active version, with REST version_selector rules to pin traffic to one version. Those evaluators are your eval-threshold rows. The versioning is pinning only, not a canary: Microsoft documents traffic splitting between agent versions as unsupported — configure one FixedRatio rule with traffic_percentage set to 100, even though version_selection_rules is an array, and the documented routing policies are “always use latest” and “pinned to a specific version”, both at 100%. So the percentage canary that lesson five's tier 3 assumes is not something this surface hands you; the staged rollout stays yours to build in front of the endpoint.

Google Cloud

Policy-as-code / admission control — Binary Authorization. The clearest deploy-time gate of the three clouds, and conceptually the closest to the artifact-integrity checks in lesson three. It implements supply-chain rules over container images: rules give “specific criteria that an image must satisfy before it can be deployed”, typically verified through attestations — records containing the image’s registry path and digest, signed by a signer’s private key — which certify that the image “was built by a specific build system or continuous integration (CI) pipeline”, or that a named human checked it. Enforcement is a deploy-time enforcer that prevents images that violate the policy from being deployed; a blocked deployment writes a message to Cloud Audit Logs explaining why. Dry-run and breakglass exist as separate documented features, and continuous validation (Preview) periodically re-checks the metadata of images associated with running Pods. Documented platforms include GKE, Cloud Run, Cloud Service Mesh and Google Distributed Cloud. Layer: image identity and provenance.

Read that capability set carefully, because it is tempting to over-read. Binary Authorization can prove this image came from this pipeline and was signed. It cannot express this agent still refuses the injection fixture, and an attestation says nothing about the prompt inside the image.

Vulnerabilities — Artifact Analysis. Described as “a family of services that provide software composition analysis, metadata storage and retrieval” (previously Container Analysis). Scanning “is triggered automatically every time you push a new image to Artifact Registry”, vulnerability information “is continuously updated when new vulnerabilities are discovered”, and coverage extends beyond OS packages to application-language package scanning. Findings aggregate into Security Command Center, and the metadata it produces can feed Binary Authorization policies — which is the useful pattern: scanner produces evidence, admission controller enforces on it. One documented caveat: the manual on-demand scanning alternative is not continual, results last up to 48 hours and are not refreshed. Layer: image contents.

Posture management and runtime threat detection — Security Command Center, the same product the paragraph above sends Artifact Analysis findings to. Its overview lists both categories as capabilities: “Postures and policies: Define and deploy a security posture to monitor the status of your Google Cloud resources” (Security Health Analytics is the built-in source doing the configuration checks) and “Threat detection and mitigation: Detect and respond to active threats such as malware, cryptocurrency miners, container runtime attacks” (built-in detection services include Event Threat Detection, Container Threat Detection, Cloud Run Threat Detection and Virtual Machine Threat Detection). Layers: deployed configuration, and workload runtime.

Two hedges that matter more here than the service name. Capability is tied to service tier — SCC is offered as Standard, Premium and Enterprise, and “each tier determines the features and services that are available to you” — and the Enterprise tier carries a documented shutdown date of 21 May 2027, after which affected organisations move to Premium. So check the current tier matrix, not just the feature list, before you design a gate step around any specific detector.

Identity — Policy Simulator for IAM. The closest GCP analogue to Access Analyzer's custom policy checks, and worth knowing precisely because it is a different shape. It replays real access attempts “from the last 90 days” against a proposed allow policy and reports each difference as an access change, categorised ACCESS_GAINED / ACCESS_REVOKED (plus their MAYBE variants), runnable as gcloud iam simulator replay-recent-access or the replays.create REST API. Two consequences for a pipeline: it answers “who would gain access” from observed traffic, not by statically comparing a candidate policy against a reference policy, so a permission nobody exercised in 90 days produces no signal; and it does not support conditions. Useful, and a weaker gate primitive than a PASS/FAIL check.

Agent behaviour. Same rule, plus an extra reason for care: the agent platform itself has been renamed (the product page for Gemini Enterprise Agent Platform carries “formerly Vertex AI”), so search results and blog posts you find will use at least two names for the same thing. Verify the current evaluation and versioning surfaces in the live docs rather than inheriting them from a tutorial.