How CloudBooster handles security: BYOA, least privilege, and full audit trail

We design for least privilege: scoped roles, resource boundaries that match what you manage, and no blanket org admin policy as a default. The exact policy is versioned in onboarding. Read to plan and validate, write to apply an approved change, audit through the APIs your account already exposes. You keep control of who creates and rotates the role. Use dedicated roles, add condition keys where they help, and keep non-production and production separate. We avoid the wildcard-across-Org pattern that often appears in a post-mortem.

The JSON below is illustrative. In production, use the onboarding-generated policy, not this snippet. Replace actions and ARNs with the real least-privilege set your deployment needs.

For each ChangeSet you can show who proposed it, which checks passed or failed, who approved, what ran, and what you recorded afterward. That is one coherent chain, not a pile of logs you stitch together. Retention, export, and which roles can read audit data are tiered in the commercial plans; higher tiers add SIEM-style export and longer retention. The product record is the same object for operations and for review.

The history the product records is append-only for what the platform wrote: enough to compare against reality when someone changes things outside the path. Drift work stays meaningful. Read access to audit views is role-gated like approval; a read-only responder role is not a path to apply production change by default.

The sequence is propose, check, approve, then apply. Approval is where you define who can bless which environments and risk classes. In higher tiers the product enforces separation of duties: the proposer and the approver are not the same person for production when your policy says so. That is what makes the control reviewable, not a slide-only claim.

Policies can treat low-risk or sandbox work differently from protected environments. The goal is a legible record on every path, including lighter routes for speed. A break-glass path should still be describable, not a blind bypass of every control. Emergency actions can include extra logging when you allow them under policy.

We are an early product from a small company. We are not going to show a false SOC2 banner. As of 2026, CloudBooster does not have third-party SOC2 Type II attestation. A SOC2 program is on our roadmap with a first target in Q4 2026, subject to scope and resourcing. If your procurement needs an attestation on day one, say so and we can be clear on timelines.

What you can review today is architectural: BYOA, least-privilege integration patterns, a ChangeSet-oriented audit record, and operator practice from the TIDORA team, including EU presence and long client delivery. Many teams get comfortable on architecture and evidence before a formal attestation exists.

The product is aimed at: unreviewed or unapproved change in production, unsafe generated or copy-pasted infrastructure without checks, blast radius from over-broad access, and teams that cannot reconstruct the approved state. The lifecycle, checks, approvals, and recordkeeping are the mitigations, together with BYOA so direct workload exposure sits under your control.

We do not replace network segmentation, incident response, or data classification. Full administrative access in your account can still be abused. The product tightens the common “fast path to prod” and “nobody knew that applied” failures that show up in small teams, including when AI is in the loop.