Compliance Environment Assessor Skill
This skill performs zero-risk, non-mutating compliance discovery, physical telemetry profiling, and data boundary framework recommendation across Google Cloud Folders (folders/{folder_id}) and Projects (projects/{project_id}).
Safety & Execution Tier (CRITICAL)
- Tier R (Strictly Read-Only):
All discovery operations execute read-only queries
(
gcloud asset search-all-resources,
gcloud compliance-manager frameworks list,
gcloud compliance-manager cloud-controls describe, and
gcloud org-policies describe --effective).
You MUST NEVER execute mutating commands (gcloud compliance-manager framework-deployments create,
gcloud org-policies set-policy, or gcloud resource-manager ...).
Grounding Guardrails: Google Cloud & Assured Workloads Precedence (CRITICAL)
To prevent hallucinations, incorrect compliance assessments, and false blockers derived from generic LLM pre-training, the agent is governed by strict Grounding Guardrails:
- Strict Prohibition on Generic LLM Pre-Training Priors:
- You MUST NOT derive compliance rules, API semantics, or deployment constraints from generic web pre-training (e.g., generic NIST/FedRAMP certification audit checklists, AWS/Azure architectures, or legacy on-prem IT auditor mindsets).
- In traditional IT audits, non-compliance is a binary go/no-go gate that
blocks deployment. In Google Cloud Assured Workloads v2, Monitor Mode
deploys detective controls without mutating existing Organization
Policies, allowing continuous observability without halting Day 0
rollout. You MUST NOT confuse these paradigms.
- Authoritative Google Cloud API Contracts & Scope Grounding:
- All API assumptions MUST be grounded in published Google Cloud API contracts:
- Assured Workloads v1 GA API (
assuredworkloads.googleapis.com/v1): Greenfield-only. Contract only creates a brand-new folder (resourceType: CONSUMER_FOLDER). It CANNOT adopt or bind to existing brownfield folders (folders/...) or projects in-place.
- Assured Workloads v2 API (
assuredworkloads.googleapis.com/v2): Brownfield-native. Contract binds directly to existing resource hierarchies (existingFolder, existingProject) and supports non-mutating Monitor Mode (enforcementMode: DETECTIVE).
- Client-Side Org Policy Readiness vs. Server-Side CES Boundary:
- Client-Side Scope: Pre-flight evaluation via
scripts/evaluate_control_rules.py assesses ONLY the 3 high-confidence
Organization Policy parameter sets bound in
Framework.cloudControlDetails[].parameters:
- Resource Locations (
builtin-restrict-resource-locations /
constraints/gcp.resourceLocations)
- Service Usage Restrictions / SUR
(
builtin-enforce-service-usage-restrictions /
constraints/gcp.restrictServiceUsage)
- CMEK Encryption Requirements (
builtin-require-cmek /
constraints/gcp.restrictNonCmekServices)
- Server-Side CES Scope: Complex Continuous Evaluation Service
(
ces_rule) and REST API rules (rest_api_measurement) are evaluated
server-side by the Continuous Evaluation Service (CES) after the
framework is deployed.
- Terminology Invariant: You MUST frame client-side findings as
Pre-Flight Org Policy Readiness Recommendations / Potential Drift
Indicators (
orgPolicyDriftIndicators), NEVER as definitive compliance
"violations" or "deployment blockers" that could contradict an actual
post-deployment CES run.
- Static Built-In Catalog, Session Caching, Support Routing & KAJ Flow:
- Built-in Frameworks (
type: BUILT_IN) returned by
gcloud compliance-manager frameworks list are static configurations
uniform across organizations. Fetch frameworks.json once per session and
reuse the cached file across all candidate evaluations and follow-up
queries.
- Personnel Support Model: A framework requires a Paid
Sovereign/Regulated Support Subscription when
builtin-restrict-technical-support-services is present in its
cloudControlDetails (as reflected in its displayName and
description). Frameworks without
builtin-restrict-technical-support-services (e.g.,
builtin-us-data-boundary, builtin-eu-data-boundary) use Standard
Commercial Support ($0 support uplift).
- Key Access Justifications (KAJ) & EKM: Recommend
-with-access-justifications framework variants only when the customer
explicitly requests KAJ/EKM, or when disambiguating between matching
regional variants in frameworks.json.
- Deterministic Tool Gating:
- You MUST NOT guess compatibility scores ($$S_{\text{composite}}$$) or resource inventories.
- You MUST execute
scripts/evaluate_control_rules.py with --frameworks-file=frameworks.json and scripts/validate_workload_payload.py with --frameworks-file=frameworks.json.
Prerequisites
Before executing environment assessment, ensure your local or Cloud Shell environment meets the following prerequisites:
- Google Cloud SDK:
- Project Setup & Target Selection:
- Region Configuration & Availability:
- Required API Enablement:
- Authentication Setup:
- Billing & Quota Project Setup (Zero Billing Impact):
- Zero-Cost Assessment Guarantee: Running this assessment incurs $0 in
Google Cloud infrastructure and API billing charges. All discovery
operations (
gcloud asset search-all-resources,
gcloud compliance-manager frameworks list, and
gcloud org-policies describe --effective) are free read-only metadata
queries.
- Quota Project Requirement: Google Cloud Service Infrastructure requires an administrative project with an active Cloud Billing account attached to allocate API rate limits and meter service usage (sent via the
X-Goog-User-Project header), even for free APIs.
- Pre-Flight Verification:
# 1. Verify active Cloud Billing account is attached to administrative project
gcloud billing projects describe PROJECT_ID --format="value(billingEnabled)"
# 2. If using a shared project, ensure your user identity has permission to consume project quota
gcloud projects add-iam-policy-binding PROJECT_ID \
--member="user:USER_EMAIL" \
--role="roles/serviceusage.serviceUsageConsumer"
# 3. Synchronize Application Default Credentials quota project
gcloud auth application-default set-quota-project PROJECT_ID
- Commands & Payloads Reference:
Step-by-Step Operating Workflow
Step 1: Ingest Scope & Resolve Organization ID
- Accept or prompt for the target scope (
folders/{folder_id} or projects/{project_id}). If the user provides an open-ended scope without stating a regulatory regime, DO NOT block on broad questionnaires. Proceed immediately to ingest telemetry.
- Automatically resolve the parent Organization ID from the scope to drive downstream catalog queries:
- For Folders:
gcloud resource-manager folders describe FOLDER_ID --format="value(parent)"
(If the parent is another folder, traverse up ancestors until organizations/{org_id} is found)
- For Projects:
gcloud projects get-ancestors PROJECT_ID --format="value(id,type)"
Step 2: Ingest Asset Telemetry & Effective Org Policies via Two-Pass Telescoping Protocol
To guarantee 100% coverage across the scope hierarchy while keeping payloads compact, telemetry ingestion executes in two telescoping passes (see Google Cloud CLI Commands Reference):
-
Pass 1: Macro Footprint & API Enumeration (100% Scope Coverage):
gcloud asset search-all-resources \
--scope="folders/FOLDER_ID" \
--page-size=500 \
--format="json(name,assetType,location)" > macro_telemetry.json
- Pagination & Scope Semantics:
--page-size=500 fetches 500 cloud assets
per HTTP API page (the maximum batch size permitted by Cloud Asset
Inventory), automatically paginating through all assets strictly inside
folders/FOLDER_ID and its descendant projects.
- Full Location & SUR Coverage:
macro_telemetry.json captures 100% of
active location and assetType values required to evaluate both
builtin-restrict-resource-locations (allowedLocations) and
builtin-enforce-service-usage-restrictions (allowedServices / SUR).
- If
PERMISSION_DENIED is returned:
- If the error states
USER_PROJECT_DENIED or references roles/serviceusage.serviceUsageConsumer, the error is on the administrative quota project (it lacks an attached billing account or caller lacks serviceUsageConsumer). Follow the Quota Project Recovery playbook and stop running further commands.
- If the error references the target scope (
folders/... or projects/...), HALT ALL TOOL CALLS IMMEDIATELY (do not run Step 2.2, Step 3, or any further commands) and inform the user they require roles/cloudasset.viewer and roles/orgpolicy.policyViewer on that scope.
- If 0 resources are returned, inform the user the target scope is empty.
-
Inspect Effective Universal Org Policies on Scope (38/38 Frameworks):
gcloud org-policies describe gcp.resourceLocations \
--folder=FOLDER_ID \
--effective \
--format="json(name,spec.rules)" > effective_locations.json
gcloud org-policies describe gcp.restrictServiceUsage \
--folder=FOLDER_ID \
--effective \
--format="json(name,spec.rules)" > effective_services.json
gcloud org-policies describe gcp.restrictTLSVersion \
--folder=FOLDER_ID \
--effective \
--format="json(name,spec.rules)" > effective_tls.json
Step 3: Fetch & Cache Built-In Framework Catalog and Filter by Location + SUR
- Fetch & Cache Built-In Framework Catalog (with Bound Parameters):
if [ ! -s frameworks.json ]; then
gcloud compliance-manager frameworks list \
--organization=ORGANIZATION_ID \
--location=global \
--filter="category:ASSURED_WORKLOADS" \
--format="json(name,majorRevisionId,displayName,description,category,cloudControlDetails)" > frameworks.json
fi
- Session Caching: Because built-in
ASSURED_WORKLOADS frameworks are
static definitions uniform across organizations, cache the output in
frameworks.json and reuse it for all candidate evaluations, payload
validations, and follow-up questions.
- Filter Candidates by Location + SUR Footprint & Clarify Intent:
- Exclude location-less control-plane management metadata
(
cloudresourcemanager.googleapis.com/*, orgpolicy.googleapis.com/*,
cloudasset.googleapis.com/*, accesscontextmanager.googleapis.com/*, and
location: "global" hierarchy nodes) from data-plane location checks.
- Match active data-plane regions (
location) and active service prefixes
(assetType) from macro_telemetry.json against each framework's
builtin-restrict-resource-locations (allowedLocations) and
builtin-enforce-service-usage-restrictions (allowedServices / SUR)
parameters in frameworks.json:
- US-Only Regions (
us-central1, us-east4): Candidates include DoD
IL5 (builtin-il5, adjudicated support), ITAR (builtin-itar, US
persons support), FedRAMP High/Moderate, or US Regional Data Boundary
(builtin-us-data-boundary, standard commercial support).
- EU-Only Regions (
europe-west3, europe-west1): Candidates include
EU Data Boundary and Support (builtin-eu-data-boundary-and-support) vs.
standard EU Regional Boundary (builtin-eu-data-boundary).
- Targeted Disambiguation:
- If multiple frameworks match the physical footprint and user regulatory
intent is unstated (e.g., an open-ended request with no regime specified),
DO NOT finalize a single primary recommendation yet — present the matching
candidate frameworks and STOP to ask the user a targeted clarifying
question about their regulatory intent (e.g., EU Sovereignty, US
FedRAMP/IL5) and personnel support model (Standard Commercial Support vs.
Paid Sovereign/Regulated Support).
- Recommend
-with-access-justifications (KAJ/EKM) framework variants only
if the customer explicitly asks for KAJ/EKM or when disambiguating
between matching regional variants.
- Out-of-Scope / Non-Catalog Compliance Standards (e.g., CMMC, UK
GDPR):
If the user asks to evaluate a compliance standard or legal certification
that is not present as a built-in
ASSURED_WORKLOADS framework in
frameworks.json (such as CMMC, UK GDPR, SOC 2, or PCI-DSS), DO NOT
fabricate or pass non-existent framework IDs (e.g., builtin-cmmc or
builtin-uk-gdpr) to evaluate_control_rules.py or
validate_workload_payload.py. Explicitly state that the requested
standard is not a standalone Assured Workloads Data Boundary framework,
explain the catalog scope boundary (Data Boundary enforces regional data
residency, SUR, CMEK, and sovereign support routing rather than legal
privacy or third-party certification audits), and offer the closest
adjacent ASSURED_WORKLOADS frameworks from frameworks.json that match
their active regional footprint (e.g., builtin-il5 or
builtin-fedramp-high for US defense/CUI workloads, or
builtin-eu-data-boundary-and-support / builtin-eu-data-boundary /
builtin-uk-data-boundary for European/UK regional residency).
Step 4: Conditional Pass 2 CMEK Ingestion & Org Policy Evaluation
- Pass 2: Conditional Targeted Deep Ingestion for CMEK Resource Types:
Derive
TARGET_TYPES (the intersection of active CAI assetTypes in
macro_telemetry.json and CMEK-governed services in builtin-require-cmek
from frameworks.json). Only 6 of the 38 Data Boundary frameworks include
builtin-require-cmek; if TARGET_TYPES is non-empty, fetch kmsKeys:
TARGET_TYPES=$(python3 scripts/evaluate_control_rules.py \
--get-target-asset-types \
--framework=FRAMEWORK_ID \
--telemetry-file=macro_telemetry.json \
--frameworks-file=frameworks.json)
if [ -n "${TARGET_TYPES}" ]; then
gcloud asset search-all-resources \
--scope="folders/FOLDER_ID" \
--asset-types="${TARGET_TYPES}" \
--page-size=500 \
--format="json(name,assetType,location,kmsKeys)" > deep_telemetry.json
fi
- Execute High-Confidence Org Policy Evaluator:
Run
scripts/evaluate_control_rules.py over macro_telemetry.json (and
optional deep_telemetry.json) with frameworks.json to compute the 3
quantitative scores (locationScore, serviceScore, cmekScore,
compositeScore) and orgPolicyDriftIndicators (when cmekRequired is
false, always display the CMEK Readiness column as N/A in the scorecard):
python3 scripts/evaluate_control_rules.py \
--telemetry-file=macro_telemetry.json \
--deep-telemetry-file=deep_telemetry.json \
--framework=FRAMEWORK_ID \
--frameworks-file=frameworks.json
- Evaluate Operational & Governance Impact:
- Review
cloudControlDetails in frameworks.json for parameterized and
operational controls (builtin-restrict-kms-protection-levels,
builtin-enforce-allowed-cmek-crypto-key-projects,
builtin-restrict-cloud-function-generations,
builtin-restrict-cloudstorage-auth-types,
builtin-iam-disable-service-account-key-creation,
builtin-disable-ssh-in-browser, builtin-enable-axt, and
*-regulatory-settings controls like
builtin-cloud-logging-regulatory-settings) and summarize their workflow
impact in the final report.
- Validate Turnkey Assured Workloads Payload:
python3 scripts/validate_workload_payload.py \
--payload-json='{"displayName":"Sovereign-Workload-Enclave","resourceConfig":{"existingFolder":"folders/FOLDER_ID"},"framework":{"framework":"organizations/ORGANIZATION_ID/locations/global/frameworks/FRAMEWORK_ID"}}' \
--org-id=ORGANIZATION_ID \
--frameworks-file=frameworks.json
Step 5: Render Executive Assessment Report (Minto Pyramid Structure)
Present an executive report structured around the Minto Pyramid Principle
(Bottom Line Up Front -> Core Value Pillars -> Supporting Evidence -> Action
Plan):
# Compliance Environment Assessment Report: [Scope URI]
## 1. Executive Conclusion & Recommendation (Bottom Line Up Front)
* **Primary Recommendation**: [Framework Name] (`organizations/{org_id}/locations/global/frameworks/{framework_id}`)
* **Org Policy Readiness Alignment**: [Composite Fit %]
* **Value & Safety Invariant**: In-place brownfield adoption via Assured Workloads v2 in **Monitor Mode** (`enforcementMode: DETECTIVE`).
* **Zero Production Outage Risk**: Mutates zero Organization Policies on Day 0.
* **Continuous Server-Side CES Observability**: Activates real-time Continuous Evaluation Service (CES) monitoring across all framework controls.
* **No Migration Required**: Protects existing resources in-place without provisioning separate folders.
---
## 2. Core Value Drivers: Why Assured Workloads Fits This Scope
1. **Residency & Boundary Alignment (`gcp.resourceLocations`)**: Active regional workloads are evaluated against allowed regions ([e.g. 100% US-contained]).
2. **Service & API Compatibility (`gcp.restrictServiceUsage` / SUR)**: Active service APIs are evaluated against accredited service allowlists ([e.g. 100% approved services]).
3. **Non-Disruptive Posture Hardening**: Enrolling in Monitor Mode provides server-side CES posture evaluation while allowing your team to triage Org Policy readiness safely.
---
## 3. Objective Assessment Scorecard & Org Policy Readiness Triage
### Quantitative Org Policy Readiness Scorecard
| Candidate Framework | Location Residency (`locationScore`) | Service Usage / SUR (`serviceScore`) | CMEK Readiness (`cmekScore`) | Composite Alignment | Personnel Support Model |
| :--- | :--- | :--- | :--- | :--- | :--- |
| **[Framework 1]** | [XX%] | [XX%] | [XX% or N/A] | **[XX%]** | [Support Model] |
| **[Framework 2]** | [XX%] | [XX%] | [XX% or N/A] | **[XX%]** | [Support Model] |
### Active Resource & Effective Org Policy Baseline
* **Discovered Inventory**: [Total Assets count] across [Active resource types and regions].
* **Effective Org Policy Baseline**: [Effective `gcp.resourceLocations`, `gcp.restrictServiceUsage`, and `gcp.restrictTLSVersion` posture].
### Pre-Flight Org Policy Readiness Recommendations (Prior to Enforced Mode)
*Pre-flight drift indicators do NOT block Day 0 deployment in Monitor Mode. Address these prior to enabling preventive policy enforcement (authoritative CES and REST control evaluations run server-side after deployment):*
* **[Priority 1]**: [e.g. Configure CMEK keys on unencrypted resources before toggling `builtin-require-cmek` to `PREVENTIVE`].
* **[Priority 2]**: [e.g. Operational impact of bound controls such as `builtin-restrict-kms-protection-levels` or `builtin-cloud-logging-regulatory-settings`].
---
## 4. Deployment Action Plan & Commercial Advisory
### Deploy via Google Cloud Console (Recommended)
Review and deploy the recommended framework directly in the Google Cloud Console:
👉 **[Open Assured Workloads Console](https://console.cloud.google.com/compliance/assuredworkloads?organizationId=ORGANIZATION_ID)**
*(The Console deployment wizard binds composing controls in Monitor Mode with zero infrastructure mutations).*
### Commercial & Licensing Advisory
* Assured Workloads compliance regimes may carry support routing or licensing entitlements depending on whether `builtin-restrict-technical-support-services` is bound (standard commercial support vs. paid sovereign/regulated support).
* Review full pricing details and entitlement tiers at: https://cloud.google.com/assured-workloads/pricing
Step 6: Handling Customer Follow-Up Questions on Specific Services
When a customer follows up with a specific question about how a recommended or
candidate framework affects a particular Google Cloud service (e.g., Cloud Run,
Cloud Storage, Spanner, GKE, Cloud SQL, Vertex AI, Cloud Logging):
- Inspect Cached
frameworks.json Locally (or Fetch via Step 3 frameworks list if Not Cached):
- If
frameworks.json is not yet present in the current working directory, run the Step 3 gcloud compliance-manager frameworks list command first to populate frameworks.json.
- Check whether
<service>.googleapis.com is permitted in
builtin-enforce-service-usage-restrictions (allowedServices) and
whether CMEK is required in builtin-require-cmek (services).
- Identify all service-specific
cloudControlDetails[].name entries bound in
that framework (e.g., builtin-run-disable-ephemeral-disk,
builtin-restrict-cloudstorage-auth-types,
builtin-disable-spanner-multi-region,
builtin-cloud-logging-regulatory-settings) and any bound parameters.
- Fetch Authoritative Control Details On Demand:
- Because
Framework.cloudControlDetails omits control descriptions,
enforcement modes, and remediation steps, run cloud-controls describe for
the relevant control ID(s):
gcloud compliance-manager cloud-controls describe CONTROL_ID \
--organization=ORGANIZATION_ID \
--location=global \
--format="json(name,displayName,description,supportedEnforcementModes,remediationSteps,parameterSpec)"
- Extract the exact underlying Organization Policy constraint (e.g.,
run.managed.disableEphemeralDisk, storage.restrictAuthTypes),
supportedEnforcementModes (PREVENTIVE vs. DETECTIVE), and
remediationSteps from the response.
- Check Effective Folder/Project Policy If Requested:
Failure Modes & Error Recovery Playbook
| Error Condition | Immediate Action | User Recovery Guidance |
|---|
USER_PROJECT_DENIED or serviceusage.serviceUsageConsumer | HALT discovery. Do not confuse with target scope permissions. Check administrative project billing status and caller quota permissions. | "The administrative project PROJECT_ID cannot be used for API quota. 1) Verify a Cloud Billing account is attached (gcloud billing projects describe PROJECT_ID), 2) Grant roles/serviceusage.serviceUsageConsumer on PROJECT_ID to your identity, or 3) Switch to a project you own: gcloud config set project <PROJECT_ID>." |
PERMISSION_DENIED on CAIS | HALT discovery immediately. Do not speculate or guess resources. | "To analyze this environment, grant roles/cloudasset.viewer on folders/123 to your active identity." |
PERMISSION_DENIED on Org Policies | HALT policy inspection. Do not guess effective constraints. | "To inspect effective organization policies, grant roles/orgpolicy.policyViewer on folders/123." |
| Empty Scope (0 Resources) | HALT evaluation. Inform user the scope contains no active assets. | "No active resources found in folders/123. Provision resources or select an active scope." |
| Conflicting Regulatory Intent | Engage user in focused clarification probe. | Present distinct requirements (e.g. DoD IL5 Adjudicated Support vs. ITAR US Persons) and ask for business requirement. |
| Zero Catalog Match | Detail multi-regional drift indicator. | Explain why single-region sovereign data boundary frameworks were ruled out (e.g. multi-continental resource footprint spanning unapproved regions). |
| Out-of-Scope / Non-Catalog Standard (e.g., CMMC, UK GDPR) | Do not invent framework IDs (builtin-cmmc, builtin-uk-gdpr). Explain catalog boundary and map to adjacent ASSURED_WORKLOADS candidates. | "Assured Workloads does not include a standalone [CMMC / UK GDPR] framework in frameworks.json. However, based on your active resources, we can evaluate an adjacent Assured Workloads Data Boundary framework such as builtin-il5 / builtin-fedramp-high (for US defense/federal workloads) or builtin-eu-data-boundary-and-support / builtin-uk-data-boundary (for European/UK regional residency)." |