bbyoc anywhere
V
commandment V

The End Customer Makes the Rules

The customer sets the privilege envelope for every cell, and your platform must discover it and operate correctly at whatever level it is granted.

 the ceiling, the ratchet, and a fleet that adapts
THE CEILING: THE CUSTOMER'S HARD CAPpermissions boundaryunremovable upper boundrole policypath-scoped role creationtag-gated actionsper-instance resourceseffective power = policy ∩ boundaryTHE RATCHET: IT TURNS AT RUNTIMEbootstraprevocable after cell is upprovisioningrevocable once instances runruntimethe posture that persiststighten tonight · re-grant tomorrow · no redeployONE FLEET, MANY RULES: VARYING AND DYNAMICcustomer aagent runs infra + servicesagent ✓customer bplatform team owns infraservices onlycustomer cair-gapped, no agentartifacts onlyprivileges vary per customer and change at runtime; the platform adapts, never assumeshuman access: minted on demand · reader by default · expires on schedule

In BYOC, the customer decides how much your platform may do inside their account, and every customer decides differently. One grants your agent full run of infrastructure and services. Another keeps infrastructure with their own platform team and cedes only the service layer. A third runs air-gapped with no agent at all. The same customer moves along that spectrum over time. An architecture that hard-codes a single privilege posture is a hosted product that happens to run in the customer's account. Build the platform to be parameterized by privilege: your control plane discovers what each cell allows, plans within that envelope, and operates correctly at every level.

The customer's first instrument is the ceiling: an IAM permissions boundary attached to every role your platform creates in the account. A role's effective permissions are the intersection of its policy and the boundary, so even if a bug grants a role :, the boundary caps what it can do. The platform can never mint a role above its ceiling and can never remove the ceiling itself. Beneath the boundary, scoping is mechanical: gate role creation on management tags, scope resources per instance, keep IAM access read-only, and cap session lifetimes. Every one of these controls lives in the customer's account as policy documents their security team can read, diff, and tighten. Enforcement belongs entirely to the customer account; the control plane reads the envelope and plans against it.

The customer's second instrument is the ratchet, and it turns at runtime. Phase your grants with independent lifecycles: a bootstrap role builds the cell and can be deleted as soon as bootstrap completes, an infrastructure-provisioning policy can go once instances are stable, and the minimal runtime path remains. Revocation runs in both directions. The customer can tighten today, re-grant tomorrow for an upgrade window, expand for a new region, then shrink again. Treat reduced privilege as a first-class operating state: the agent detects what it can no longer do, degrades those functions gracefully, reports the constraint honestly, and resumes when the grant returns, with no redeploy and no support ticket.

Fleet operations inherit the rules. One control plane operates cells at different privilege levels at the same time: full-agent, services-only, air-gapped. Compute every rollout against each cell's local envelope: batch to bound blast radius, schedule inside per-customer maintenance windows, pause automatically on failure, and skip the steps a given cell's grants exclude. Never let fleet tooling assume uniform permissions, because no such uniformity exists across customers.

Humans follow the same discipline. Mint operator access on demand, scoped to a single cell, read-only by default, and expiring on a fixed schedule. Elevation to admin is a distinct, visible, logged event, and the customer's rules can require approval before it happens. When an engineer changes teams, the credential has already expired and there is nothing left to revoke.