Security Controls designed
Security review should start from control evidence, not from a claim that "we have process." GPUaaS has documented controls, release-blocking checks, and gaps that need enforcement separation as the platform matures.
Control Families
| Family | Examples |
|---|---|
| Auth and authorization | OIDC, short-lived access tokens, role/tenant/project enforcement |
| Secrets and transport | Secret manager, TLS, internal transport security, cert lifecycle |
| Runtime access | No persistent private-key storage, public-key access, terminal token/session binding |
| Terminal security | Single-use tokens, session TTL, signed terminal tasks, least-privilege shell boundary |
| Payments and billing | Stripe raw-body verification, webhook idempotency, immutable ledger |
| Audit and evidence | Privileged mutation audit, release evidence, residual risk, correlation IDs |
| Abuse controls | WAF, rate limits, bot controls, negative tests |
For details, see Terminal Session Security and Node Lifecycle.
Release-Blocking Checks
Review Posture
- Controls should be tied to tests, scans, config validation, or runbook drills.
- Release-blocking controls fail closed.
- Exceptions need owner, reason, expiry, and residual-risk approval.
- Repeated manual checks should become report-only guards, then warning, then blocking gates.