carlos / platform Public

Production infrastructure needs scoped approval (Paul's rule, 2026-09-15)

Before creating, changing, or deleting infrastructure resources or records in production or shared accounts, or under a real company or customer domain, get explicit user approval for the scoped work. This includes temporary experiments and applies through every interface: DNS, SES identities, configuration and tenants, IAM users, roles, policies and credentials, queues, topics, buckets, compute, and related resources.

Prepare a concrete plan before asking for approval. State the account and region, domains, exact resource changes, purpose, permissions and traffic effects, expected cost, duration, and cleanup and verification steps. One explicit approval covers the complete scoped experiment and its cleanup; do not ask repeatedly for each API call. Existing explicit scoped authorization and routine, preauthorized deployment workflows remain valid. Ask again if the work materially expands the approved account, region, domain, resource type, permissions, traffic, cost, or duration.

Read-only investigation and local mocks may proceed without approval. Live tests may run unattended within an explicitly designated sandbox scope with restricted permissions and automatic expiry. A sandbox domain alone does not authorize IAM or other account-level changes in a production or shared account; those still need scoped approval. A name beginning with spike-, a planned cleanup, working credentials, or a generic instruction to implement or test does not constitute approval or designate a sandbox.

This rule supplements the AWS access rule above and applies to subagents. Pass the approved scope to delegates so they can check their work against it.

The rationale is concrete: on September 15, an SES spike created spike.teamtito.com, DNS records, IAM credentials, and messaging in Tito's production account. It was removed minutes later, but cleanup does not substitute for approval.