Proof, not pitch · verifiable
This site is built by the system it sells.
RingMod sells governed, machine-verified, multi-agent infrastructure delivery. So ringmod.ai is built and continuously deployed by exactly that — AWS CDK in TypeScript, driven by orchestrated agents, with a mandatory production-safety gate before any apply. Unlike the representative scenarios elsewhere on this site, every claim here is checkable against the repository.
Every change passes these gates
Machine-verified, not trusted.
tsc --noEmit Compile-time correctness; CI fails on any error. ESLint Style and footgun checks across all infrastructure code. aws-cdk-lib/assertions 23 tests asserting the synthesized CloudFormation is what we intend. cdk-nag (AwsSolutions) Synth fails on any finding. Current status: 0 non-compliant. cdk diff on every PR A human-reviewable change set before anything is applied. Scoped cfn-exec policy + permissions boundary No path from “deploy this repo” to AWS administrator. GitHub OIDC No long-lived AWS access keys exist anywhere. The production-safety posture
Bootstrap doesn’t grant admin.
The default AWS CDK bootstrap hands its deployment role
AdministratorAccess — the
role CloudFormation assumes to create every resource. We don’t accept
that. The execution role is scoped to this project’s exact service
surface, and it can only create IAM roles that carry a permissions
boundary, applied to every role at synth via a CDK Aspect. So even a
mis-authored stack policy cannot mint admin: there is no path from
“deploy this repo” to administrator.
A real example
The guardrails caught two real issues — and reported exactly how.
Both happened during this build. Both are the failure modes a default AdministratorAccess bootstrap would have waved through silently.
The permissions boundary was too strict
The first foundation deploy failed because the boundary denied iam:CreateOpenIDConnectProvider — which the GitHub OIDC provider legitimately needs. CloudFormation rolled the stack back cleanly; the fix was loosening the boundary, re-verified and re-deployed before anything shipped.
The scoped execution policy was too tight
Updating the CI deploy role’s trust failed with an explicit AccessDenied on iam:UpdateAssumeRolePolicy — scoped to role/RingMod* while the role is named ringmod-github-deploy, and IAM ARN matching is case-sensitive. The pattern was widened to the real name; the stack recovered via continue-update-rollback.
That’s the difference between least-privilege as a slogan and least-privilege that actually constrains.
Don’t take it on faith
Verify it yourself.
- The seven gates above map to real CI steps — see .github/workflows/deploy.yml.
- infra/bootstrap/ holds cfn-exec-policy.json and permissions-boundary.json, which become RingModCdkCfnExecPolicy and RingModPermissionsBoundary.
- Bootstrap runs cdk with --cloudformation-execution-policies pointing at the scoped policy — explicitly not AdministratorAccess.
- The boundary is applied to every role app-wide in infra/bin/ringmod.ts (PermissionsBoundary.of(app).apply).
- cdk-nag AwsSolutions reports live in docs/compliance/ with 0 non-compliant findings, regenerated each synth.
- Three single-responsibility CDK stacks, pinned to us-east-1, with Foundation deployed first (guardrails before anything billable).
- No long-lived AWS keys exist; CI authenticates via the GitHub OIDC provider and assumes a scoped deploy role.