Cloud Sandbox and Developer Account Security Guide: Budgets, Expiry, Cleanup and Leaked Keys

Sandbox and developer accounts are created for speed, then forgotten with owner rights, live keys and running resources still inside them. Experiment environments rarely hold production data, but they often hold long-lived access keys, broad permissions and an uncapped bill, which makes them a favourite target for credential theft and cryptomining. This guide covers the lifecycle after an environment is approved: budgets that act rather than warn, expiry and automated cleanup, data rules, and how to contain keys leaked from experiment accounts. It is for platform, cloud security and FinOps teams running sandboxes on AWS, Google Cloud and Microsoft Azure. Platforms are listed alphabetically throughout; order is not a ranking. The request form, guardrail profiles and pre-handover baseline are covered in the Cloud Account Request and Guardrails Checklist, so they are not repeated here.

Key takeaways

• Every sandbox needs an end date and a spend ceiling at birth. Expiry and budget belong in the vending pipeline, recorded as tags or labels, not in a spreadsheet someone checks later.
• Budget alerts are detection, not a cap. Provider guidance treats budget alerts as warnings, and Google Cloud notes a delay between incurring costs and notification; pair alerts with automated actions such as denying new resources, stopping instances or detaching billing.
• Cleanup must be automatic and verified. Recycle or delete accounts at expiry, remove owner access, and quarantine anything the cleanup could not delete.
• Sandbox keys are real keys. A key minted in an experiment account authenticates as well as any other; block long-lived keys by policy and use federation or short-lived credentials instead.
• Isolation and data rules keep a sandbox a sandbox. No peering or gateways to corporate networks, no production or customer data, and audit logs flowing to the central log store even in throwaway accounts.

Why sandboxes are a distinct risk

A sandbox exists so engineers can try things without a change ticket. That freedom produces a recognisable risk profile:

• Broad standing rights: developers usually hold owner or administrator roles in their sandbox, so a stolen sandbox credential can create identities, change policies and spin up compute.
• Long-lived credentials: experiments often start with an access key or service account key pasted into a laptop file, notebook or CI variable. AWS's IAM documentation warns that keys held in the shared credentials file are stored in plaintext and advises against putting keys in application or project files.
• Uncapped spend: the most common sandbox incident is not data theft but resource hijacking, MITRE ATT&CK T1496.001 Compute Hijacking, where stolen credentials run cryptocurrency miners. See MITRE ATT&CK T1496 Resource Hijacking.
• Weak ownership: once the experiment ends or the engineer leaves, no one watches the account, so alerts go unread.

The Storm-1283 OAuth apps abuse shows the pattern: an account holding an ownership role on an Azure subscription was used to register an application, add secrets and run cryptomining virtual machines, with Microsoft reporting compute fees of 10,000 to 1.5 million US dollars for targeted organisations. Ownership rights plus the ability to mint machine credentials are exactly what most sandboxes grant.

Sandbox lifecycle model

Thresholds and timings above are NHI Mgmt Group recommendations. A 30 to 90 day maximum life, renewable once with a fresh approval, keeps most sandboxes short enough that their credentials do not outlive their purpose.

Provider controls for budgets, expiry and cleanup

AWS

• Innovation Sandbox on AWS: an AWS Solution that manages existing accounts (it does not create or close them) as temporary sandboxes. It sets up a sandbox organisational unit structure, attaches service control policies (SCPs) that restrict which services sandbox users can access, monitors sandbox leases against configured budget and duration thresholds, and at the end of use runs AWS Nuke through AWS CodeBuild to delete user-created resources. After cleanup an account returns to the available pool or moves to quarantine for manual investigation.
• AWS Budgets actions: when a cost or usage threshold is reached, a budget action can apply an IAM policy, apply an SCP (from the management account to another account), or target specific Amazon EC2 or Amazon RDS instances in the same account. Actions run automatically or after manual approval, and several actions can share one threshold.
• Guardrails: attach sandbox SCPs at the sandbox organisational unit; see the AWS Organizations and SCPs Guide. Where developers create their own roles, require a permissions boundary so they cannot grant themselves more than the sandbox allows; see the AWS IAM Permissions Boundaries Guide.

Google Cloud

• Budgets with automated billing detachment: Google Cloud documents a pattern in which a project-scoped budget publishes programmatic notifications to a Pub/Sub topic, and a Cloud Run function compares cost with budget and, when exceeded, removes the project's billing account through the Cloud Billing API. The function's service account needs the Billing Account Administrator role on the billing account. Google warns that this shuts down all resources in the project, that resources might be irretrievably deleted, and that re-enabling billing has no guarantee of service recovery, which suits sandboxes but not shared projects.
• Expiry and deletion: record the expiry date as a project label and run scheduled automation that deletes expired projects. Deleted projects are soft-deleted and fully deleted after 30 days, and still count against project quota until then; project IDs are never reused.
• Guardrails: place sandbox projects in a sandbox folder and apply organisation policy constraints there; see the Google Cloud Organization Policy Guide.

Microsoft Azure

• Sandbox management group: the Cloud Adoption Framework gives each sandbox its own subscription, placed in a sandbox management group where sandbox policies are assigned and the activity log policy is inherited for audit logging.
• Budgets: the framework recommends setting the default budget to the maximum cost the organisation approves for a sandbox, applied with the Deploy-Budget policy at the sandbox management group, and notes that the alert alone is just a warning mechanism; at a threshold such as 100 per cent you might cancel or delete the subscription.
• Expiry: tag each subscription with an expiration date, use automation to cancel or delete it when the date is reached, move it to the decommissioned management group, and remove owner role assignments for all sandbox users on cancellation.
• Isolation: the framework names policies that deny virtual network peering across subscriptions and deny creation of ExpressRoute gateways, VPN gateways and Virtual WAN hubs. See the Azure Policy and Management Groups Guide.

Credentials and leaked keys from experiment accounts

Most sandbox compromises start with a credential that left the sandbox: a key in a public repository, a notebook, a container image or a developer's laptop. The TeamTNT worm copied AWS CLI credential files from exposed Docker hosts, including build servers, which is exactly where experiment keys tend to live.

Two rules apply on every platform. First, give sandbox workloads federated or managed identities from the start; see the Workload Identity Federation Guide. Second, run secret scanning on the repositories developers use for experiments, not only production repositories, and triage findings by whether the key still works and what it can reach; see Developer Secret Scanning Triage. When a sandbox key is confirmed leaked, treat it as a cloud credential compromise, not a sandbox nuisance: revoke, review activity in the audit log for the exposure window, and check for new identities, keys and compute. The Cloud Credential Compromise Playbook covers the full response.

Data rules for sandboxes

• No production or customer data: use synthetic or masked data only. Microsoft's framework advises giving users a clear disclaimer not to add sensitive data before assigning them a sandbox, and notes that Microsoft Purview can alert when data the organisation labels as sensitive is added to sandbox environments.
• No production connectivity: deny peering, VPN and dedicated interconnect creation in the sandbox container on every platform.
• No shared secrets: sandboxes never receive production secrets, database connection strings or signing keys, even read only.
• Logs survive the sandbox: audit logs go to the central log store outside the sandbox, so evidence remains after the account is cleaned or deleted.

Implementation plan

1. Inventory existing sandboxes. List every account, project and subscription tagged or named as sandbox, development or personal, with owner, last activity, spend and credential count. Expect to find orphans.
2. Create the sandbox container and policies. Build the sandbox organisational unit, folder or management group with guardrails in audit or dry-run mode first, where the platform offers it, and review what would have been denied for two weeks.
3. Attach budgets and actions. Start with notification-only actions or manual approval, then switch to automatic once owners trust the thresholds.
4. Pilot expiry and cleanup with one team. Run cleanup on a test account first and compare before-and-after resource lists. AWS Nuke filters and Google Cloud billing functions both support testing before enforcement: Google's sample function defaults to a simulation mode.
5. Enforce credential restrictions. Turn on key creation restrictions in the sandbox container, with a documented exception route for experiments that genuinely need a key.
6. Migrate existing sandboxes. Move them into the container, assign expiry dates no more than 90 days out, and notify owners.
7. Rollback. Keep policy assignments versioned in infrastructure as code. If a guardrail or action breaks legitimate work, revert the assignment through the pipeline, not by hand, and record the exception with an expiry.

Small versus large organisations: a small team can run sandboxes as labelled projects or subscriptions with budgets and a weekly scheduled cleanup job. Large organisations benefit from a pooled, leased model such as Innovation Sandbox on AWS or an equivalent internal vending service, where accounts are recycled rather than created and closed, and from per-team budgets that roll up to FinOps reporting. Shared team sandboxes are cheaper but blur ownership; personal sandboxes are easier to expire but multiply credentials.

Detection and metrics

Watch for: new access keys, service account keys or application secrets in sandbox containers; compute created by machine identities rather than people; GPU or large instance types; activity in unapproved regions; and spend spikes. See Cloud Cost Anomalies as Security Signals for turning billing data into detections.

• Expiry coverage: percentage of sandboxes with an owner and an expiry date under 90 days. Target 100 per cent.
• Overdue sandboxes: count of sandboxes past expiry and still active. Target zero.
• Long-lived keys: number of active user access keys, service account keys or application password secrets in sandbox containers, trending to zero.
• Cleanup success rate: percentage of cleanup runs that end without quarantine.
• Budget action latency: time from threshold breach to enforcement action.
• Leaked key exposure time: time from a secret scanning alert on a sandbox key to revocation.

Framework mapping

Common failure patterns

• Alert-only budgets: a budget email to a departed engineer stops nothing; every sandbox budget needs an automated action.
• Expiry without credential revocation: deleting resources but leaving users, keys or application secrets behind keeps the door open, as the Storm-1283 case shows for application secrets.
• Sandbox exempt from logging: skipping audit logs to save cost leaves no evidence when a sandbox key is abused.
• "Temporary" production data: copying a production extract into a sandbox for a quick test turns the sandbox into an unprotected copy of regulated data.
• Silent cleanup failures: cleanup jobs that fail on protected or dependent resources leave partial accounts recycled to the next user; quarantine and review them.
• Keys on build hosts: experiment keys stored in credential files on shared build or container hosts, as in the TeamTNT case, are taken by any malware that lands there.

Practitioner checklist

• Every sandbox sits in a dedicated sandbox organisational unit, folder or management group.
• Owner, cost centre and expiry date are recorded as tags or labels at creation.
• Budgets have automated actions, not only alerts, tested on a pilot account.
• Expiry automation deletes or recycles the environment, removes owner access and revokes credentials.
• Cleanup failures go to quarantine with a ticket.
• Long-lived key creation is blocked or restricted in sandboxes, with a documented exception route.
• Leaked-key auto-response is enabled where the platform offers it, and secret scanning covers experiment repositories.
• Peering, VPN and interconnect creation are denied; no production data or secrets are allowed.
• Audit logs from sandboxes reach the central log store and outlive the sandbox.
• Expiry coverage, overdue sandboxes and long-lived key counts are reported monthly.

Standards and references

• AWS: Innovation Sandbox on AWS solution overview
• AWS: Configuring budget actions
• AWS: Manage access keys for IAM users
• Google Cloud: Disable billing usage with notifications
• Google Cloud: Best practices for managing service account keys
• Microsoft: Landing zone sandbox environments (Cloud Adoption Framework)
• Microsoft: Configure app management policies
• MITRE ATT&CK: T1496.001 Compute Hijacking

Related NHI Mgmt Group resources: Cloud Account Request and Guardrails Checklist · AWS Security Guide · Google Cloud Security Guide · Microsoft Azure Security Guide · Preventive Cloud Guardrails Guide