# Cloud & infrastructure: enterprise AI policy pack Allow investigation, planning and bounded operational work without granting an agent unilateral control over production infrastructure or organisation-wide security controls. Implementation guidance, not executable Tracelet configuration or legal advice. Tool names identify places where the control may apply; they do not claim shipped connector coverage. Confirm actual tool/action coverage and enforce destination permissions. Replace example thresholds, IDs and approval windows with your approved values. ## Control scope - Protected assets: Cloud estates, Kubernetes clusters, networks, workloads, logging and encryption keys - Consequential actions: Deletion, destructive plans, public exposure, guardrail changes and service shutdown - Applicable systems: AWS, Azure, Google Cloud, Kubernetes, Terraform, Pulumi and Cloudflare - Context to resolve: Resolve the principal, tenant/account/project, region, resource graph, environment tags, change ticket, maintenance window and blast radius. - Enforcement boundary: Use organisation policy, cloud IAM/RBAC, resource locks, admission controls and controlled deployment identities. Agent interception complements these controls; it does not replace them. ## Owners Cloud platform owner + infrastructure security ## Configure first - Production accounts, subscriptions, projects, clusters, regions and critical resources - Approved infrastructure pipelines, plan formats, maintenance windows and service owners - Protected logging, security, network and encryption controls with separate break-glass custody ## Shared decision baseline ### Resolve the real target Decide on immutable IDs and effective context: principal, tenant/account, environment, resource, data classification and destination. Names and local profiles are hints, not authority. ### Fail closed on consequential ambiguity If the target, blast radius, tenant or data classification cannot be resolved, hold the action. Do not treat missing metadata as non-production or low risk. ### Bind approval to the exact action An approval covers the actor, operation, target set, content or artifact digest, value and expiry. Material changes invalidate it; the requester cannot approve their own action. ### Keep an evidence-grade decision record Record resolved context, policy version, matched rule, decision, approver and downstream result. Minimise captured sensitive content and protect the record from the acting identity. ## Policies ### CI-01: Block deletion of production estates and critical resource containers - Severity: Critical - Decision: Block - Owner: Cloud platform owner #### Policy statement Deny deletion, closure or organisation departure for production accounts, subscriptions, projects, resource groups and equivalent containers that own critical workloads. #### Covered operations - Close cloud account or remove it from the organisation - Delete project, subscription, resource group or folder - Remove the native lock, lien or organisation policy protecting that scope #### Evaluation rules - Resolve immutable organisation, account, subscription and project identifiers plus inherited environment tags. - Expand the resource graph and block when the container owns production resources, security controls, billing or shared networking. - Treat guardrail removal and subsequent deletion as a correlated sequence across tools and sessions. #### Example decisions (illustrative; do not run against live systems) - **Google Cloud:** `Delete project payments-prod`. Block. - **Azure:** `Delete resource group rg-prod-core`. Block even if the group name was supplied by the agent. #### Applicable tools and systems - AWS Organizations - Azure Resource Manager - Google Cloud Resource Manager - Terraform - Pulumi - CloudFormation #### Enforcement Apply organisation-level denies, resource locks or liens and keep their removal permissions out of agent roles. Alert both the platform owner and security operations on attempted bypass. #### Exception / approval Only a formal estate-decommission process with dependency evidence and independent authorisation; never a reusable chat approval. #### Test fixtures - Should remain permitted: Read inventory or delete an explicitly ephemeral sandbox container with no protected descendants. - Should be blocked or held: Delete a production scope, remove its protection or move/rename it to evade classification. #### Implementation references - [AWS · Service control policies](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) - [Google Cloud · IAM deny policies](https://cloud.google.com/iam/docs/deny-overview) - [Microsoft · Lock Azure resources](https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/lock-resources) ### CI-02: Approve the exact production infrastructure plan - Severity: Critical - Decision: Require approval - Owner: Platform change owner #### Policy statement Require approval for a saved production infrastructure plan containing create, update, replace or delete actions. Approval applies to the plan digest, not to a generic apply command. #### Covered operations - terraform apply / destroy - pulumi up / destroy - CloudFormation, ARM/Bicep or deployment-manager changes - Equivalent provider API changes generated from infrastructure code #### Evaluation rules - Resolve workspace, backend, cloud identity, commit and environment from authoritative metadata. - Present creates, in-place updates, replacements, deletions and sensitive outputs separately to the approver. - Reject unsaved plans, auto-approved plans and any apply whose digest differs from the reviewed plan. - Require additional service-owner approval when the plan changes critical data, networking, identity or recovery controls. #### Example decisions (illustrative; do not run against live systems) - **Terraform:** `Apply saved plan sha256:… to prod-eu`. Hold until the exact plan and workspace are approved. - **Pulumi:** `Destroy stack payments/prod`. Hold and route to the decommission path. #### Applicable tools and systems - Terraform - Pulumi - AWS CloudFormation / CDK - Azure Bicep / ARM - Google Cloud infrastructure tooling - Atlantis / Spacelift #### Enforcement Run production applies through a controlled CI identity that accepts only an approved plan artefact. Keep direct provider write credentials out of developer agents. #### Exception / approval Emergency plan requires incident reference, exact digest, short expiry and an independent approver with authority over the affected services. #### Test fixtures - Should remain permitted: Generate a plan with a read/planning identity and apply the unchanged approved plan in the configured window. - Should be blocked or held: Use auto-approve, apply without a saved plan, change variables after approval or apply to another workspace. #### Implementation references - [HashiCorp · Terraform apply](https://developer.hashicorp.com/terraform/cli/commands/apply) ### CI-03: Block production cluster and service destruction - Severity: Critical - Decision: Block - Owner: Kubernetes platform owner #### Policy statement Deny agent-initiated deletion of production clusters, namespaces, persistent storage and shared ingress, and deny scaling a critical service to zero outside an approved incident or deployment workflow. #### Covered operations - Delete cluster, namespace, persistent volume or shared ingress - Delete all workloads by selector or manifest - Scale a protected production workload or node pool to zero #### Evaluation rules - Resolve cluster UID and namespace from kubeconfig plus flags; context names are not authoritative. - Expand --all, selectors, files, kustomize and Helm actions to the exact resource set and owner. - Block protected platform resources and unknown scope. Routine rollouts may use the approved deploy identity and availability constraints. #### Example decisions (illustrative; do not run against live systems) - **kubectl:** `delete namespace payments-prod`. Block. - **Kubernetes API:** `DeleteCollection deployments where app=checkout`. Block when expansion includes all production replicas. #### Applicable tools and systems - Kubernetes / kubectl - Helm - Argo CD - Flux - AWS EKS - Azure AKS - Google GKE - OpenShift #### Enforcement Use least-privilege Kubernetes RBAC, admission policy, protected GitOps paths and disruption/availability controls. Keep cluster-admin and namespace-delete permissions out of routine agents. #### Exception / approval A separate incident or decommission workflow with the cluster owner; the agent does not receive standing cluster-admin credentials. #### Test fixtures - Should remain permitted: Read workload status or restart one permitted deployment through the approved rollout path. - Should be blocked or held: Delete a namespace, expand a selector to all workloads, delete persistent data or target an unresolved cluster context. #### Implementation references - [Kubernetes · RBAC good practices](https://kubernetes.io/docs/concepts/security/rbac-good-practices/) ### CI-04: Review changes that create public network exposure - Severity: Critical - Decision: Require approval - Owner: Network security owner #### Policy statement Hold network changes that make a previously private production service publicly reachable or materially broaden ingress to administrative, database or control-plane ports. #### Covered operations - Add 0.0.0.0/0 or ::/0 ingress - Create public IP, public load balancer or internet gateway route - Disable private endpoint, WAF, mTLS or network policy protection #### Evaluation rules - Evaluate the resulting reachable graph, not just the edited rule; include inherited groups, peerings, routes and load balancers. - Classify destination port and asset criticality, and identify compensating authentication and edge controls. - Aggregate staged changes that together create exposure. Approval binds to the final diff, source ranges, ports, duration and owner. #### Example decisions (illustrative; do not run against live systems) - **AWS EC2:** `Authorize 0.0.0.0/0 to tcp/5432 on a production security group`. Hold for network security approval. - **Cloudflare:** `Disable access policy on admin.example.com`. Hold because it creates a public admin path. #### Applicable tools and systems - AWS VPC / EC2 - Azure Network Security Groups - Google Cloud VPC - Kubernetes NetworkPolicy - Cloudflare - Terraform / Pulumi #### Enforcement Use provider policy, policy-as-code and network admission controls to prevent unreviewed exposure. Re-evaluate reachability after apply and automatically expire temporary rules. #### Exception / approval Approval covers exact asset, source, port, compensating controls and expiry. Material changes or extensions require new approval. #### Test fixtures - Should remain permitted: Narrow an existing ingress rule or add a time-bound internal source range to a non-critical service. - Should be blocked or held: Open a database/admin port globally, remove the private endpoint or split a public path across multiple changes. #### Implementation references - [Microsoft · Lock Azure resources](https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/lock-resources) ### CI-05: Block disabling security telemetry and preventive controls - Severity: Critical - Decision: Block - Owner: Security operations #### Policy statement Deny agent changes that stop, delete or materially reduce required audit logging, threat detection, security scanning, WAF, endpoint protection or policy enforcement in production. #### Covered operations - Stop or delete organisation audit trails and log sinks - Disable security services, policy engines, alert routes or tamper protection - Reduce required log retention or exclude protected event categories #### Evaluation rules - Maintain an authoritative list of required controls and their minimum configuration per account and environment. - Compare resulting state with the baseline and correlate sequences such as exclude-events then disable sink. - Do not grant the monitored agent identity authority to change the independent control or its audit destination. #### Example decisions (illustrative; do not run against live systems) - **AWS CloudTrail:** `StopLogging on the organisation trail`. Block. - **Google Cloud:** `Delete the central audit log sink`. Block. #### Applicable tools and systems - AWS CloudTrail / GuardDuty / Security Hub - Microsoft Defender for Cloud - Google Cloud Audit Logs / SCC - Cloudflare WAF - Kubernetes admission policy - EDR platforms #### Enforcement Use organisation-level deny policy and a security-owned logging account/project. Generate a high-priority event on attempted tampering and retain the decision outside the affected scope. #### Exception / approval No routine exception. Vendor-directed emergency maintenance uses a security-owned identity and dual control with compensating telemetry. #### Test fixtures - Should remain permitted: Add a new log sink or increase retention without weakening required coverage. - Should be blocked or held: Stop logging, delete the central trail, add an exclusion for privileged changes or disable a required detector. #### Implementation references - [AWS · Service control policies](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) ### CI-06: Block destruction or uncontrolled export of production encryption keys - Severity: Critical - Decision: Block - Owner: Cryptographic key owner #### Policy statement Deny scheduling deletion, disabling, exporting or weakening access policy for production encryption and signing keys used by critical services or protected data. #### Covered operations - Schedule/delete/disable key or vault - Export key material or make it broadly accessible - Change rotation, key policy or recovery protection below baseline #### Evaluation rules - Resolve key ARN/ID, aliases, owning vault/project, downstream encrypted resources and signing consumers. - Treat alias changes and key replacement as consequential when they redirect a protected workload. - Block self-grants and any policy change that gives the agent or a public principal decrypt, sign, export or administration rights. #### Example decisions (illustrative; do not run against live systems) - **AWS KMS:** `ScheduleKeyDeletion on the production payments key`. Block. - **Azure Key Vault:** `Purge a soft-deleted production vault`. Block. #### Applicable tools and systems - AWS KMS / CloudHSM - Azure Key Vault / Managed HSM - Google Cloud KMS - HashiCorp Vault - Thales / HSM platforms #### Enforcement Use key policies, separation of duties, purge protection and independent key-administrator identities. The workload and agent identities should consume keys without administering them. #### Exception / approval Key retirement follows a cryptographic lifecycle process with dependency proof, recovery/escrow checks and two authorised custodians. #### Test fixtures - Should remain permitted: Read key metadata or perform an authorised encrypt/decrypt operation through the workload role. - Should be blocked or held: Schedule deletion, purge the vault, export key material or add the agent as key administrator. #### Implementation references - [NIST SP 800-207 · Zero Trust Architecture](https://csrc.nist.gov/pubs/sp/800/207/final) ## Rollout checklist - [ ] Inventory authoritative resource IDs, environments, classifications and owners. - [ ] Map every entry point: IDE, agent, CLI, MCP, API, browser and direct console. - [ ] Put the hard deny or least-privilege boundary in the destination system. - [ ] Test permitted, held and denied fixtures using synthetic data in a sandbox. - [ ] Test aliases, APIs, batch operations, changed approvals, retries and unknown scope. - [ ] Observe matches, tune false positives and then enforce a bounded production scope. Coverage: https://tracelet.ai/platform#coverage