Security
Governance you can audit, not governance you hope for.
Stoda exists because “just trust the AI” is not a security posture. Everything on this page follows from three commitments.
Three commitments
The architecture
Your cloud is the boundary.
Your cloud, your SSO
Stoda deploys into your AWS, GCP, or Azure through one cross-account role you create and can revoke. Data never leaves your VPC, and apps sit behind your own SSO.
No standing keys
Cloud access uses workload identity federation, so there are no long-lived keys to leak. Repo tokens are short-lived and read-only; upload credentials are single-use.
Builds in an empty room
Operator-built code is treated as untrusted. Builds run in a sandbox with zero credentials, no database access, no secrets, and hard resource limits on every job.
Isolated per tenant
Artifacts, scan results, state, and infrastructure definitions are scoped per customer, down to the Terraform level. Nothing is shared between tenants.
Every verdict recorded
Each deploy attempt carries telemetry end to end: which commit, which checks, what they found, whether it shipped. A lookup, not an investigation.
Eject anytime
The infrastructure Stoda manages is yours: readable, forkable Terraform in your own account. Leaving means keeping everything and turning the service off.
Deploys fail closed
A fixed set of checks runs identically on every deploy. When one fails, the deploy doesn’t happen – no force-deploy button. The full story is just below.
The cross-account role is scoped to the infrastructure Stoda manages for your operator apps, and nothing else. Destructive permissions are excluded outright, and you read the exact permission policy before you grant anything. It gives no path to your production databases, your product, or your customers’ data – so even if Stoda itself were breached, there is no route from our side to what matters most in yours. Revoke the role and everything ends.
The deploy gate
Deterministic checks.
Fail closed.
The check set is early and focused today. The way it runs is not.
The gate between an operator’s repo and your cloud is not a model’s opinion. It’s a fixed set of checks that run identically on every deploy: static analysis, secret detection, and a dependency audit today, with the set growing. No checks folder in the app repo, no flag that weakens a rule, no force-deploy button. When a check fails, the deploy doesn’t happen. The running app is untouched: the previous version stays live while the why gets fixed. AI helps author checks; it doesn’t get a vote at deploy time.
Same input, same verdict – every time.
After the deploy
Who owns what, explicitly.
Rule enforcement, dependencies, CVEs (known vulnerabilities)
Every deploy is checked against your rules and every app lands behind your SSO automatically – nobody wires that up per app. We track dependencies, flag CVEs, and alert the owner; a critical issue that stays unfixed takes the app down, not your posture.
The app itself
If the app breaks, the operator fixes it – it’s their tool, and that’s the point. It gets fixed faster than the spreadsheet it replaced ever did.
Rule configuration
The rules stay in-house: the cloud, the SSO, who can use an app, what it can reach. Engineering sets them once, Stoda enforces them on everything that ships, and the cross-account role exists only as long as engineering keeps it.
Working with us
Early, and honest about it.
Stoda is young, built by people who ran this exact infrastructure at a regulated fintech. Design partners get direct access to the founders, our current security documentation, and a straight answer on what’s shipped versus roadmap. And if Stoda disappeared tomorrow, your apps keep running on Terraform you own: nothing new ships ungoverned, and you keep everything. Bring the hard questions.
Put your security team in the room.
We’re picking our next design partners now. Bring the hard questions.