/assuredworkloads-environment-assessor

name: assuredworkloads-environment-assessor
metadata:
  version: "1.0.0"
  category: SecurityAndCompliance
description: >-
  Discover Google Cloud resource telemetry and effective Org Policies, evaluate brownfield workloads against
  sovereign data boundary and compliance standards (EU Data Boundary with Support, FedRAMP Moderate/High, DoD IL4/IL5,
  ITAR, CJIS, US/EU Regional Data Boundaries), and recommend the optimal Assured Workloads Framework. Use
  when asked to: "assess my environment for compliance", "which Assured Workloads framework
  should I use?", "check if my folder is ready for EU sovereignty", "evaluate compliance
  posture for folders/123 or projects/xyz", or "discover compliance gaps before deployment".
  Do NOT use for live mutating policy deployments, generating deep audit reports via Cloud Audit Manager,
  generating remediation scripts, or authoring custom Assured Workloads frameworks.

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**:

1. **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. 2. **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`).

3. **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`: 1. Resource Locations (`builtin-restrict-resource-locations` / `constraints/gcp.resourceLocations`) 2. Service Usage Restrictions / SUR (`builtin-enforce-service-usage-restrictions` / `constraints/gcp.restrictServiceUsage`) 3. 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. 4. **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`. 5. **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 e