持ち込みコードを、使い捨ての中で組み立てる
持ち込まれたコードは Firecracker マイクロVM の中でビルドされます。ビルド環境が本番の資格情報やレジストリへのpush権限を持つことはありません。
AIが生成したアプリのための実行基盤
持ち込んだアプリを、隔離ビルドしてから動かす。
Firecracker マイクロVM でビルドし、fail-closed なスキャンゲートを通し、 Egress既定拒否の制限ランタイムで実行します。利用者向けのログインは SSOゲートウェイの裏側に置かれます。
サインアップしてワークスペースを作れば、その場でデプロイできます。
- 生成されたアプリ — 持ち込まれた未検証のコード
- 隔離ビルド — Firecracker マイクロVM
- fail-closedスキャンゲート — 重大な検出やエラーで停止
- 制限ランタイム — Egress既定拒否・エッジ衛生
- SSOゲートウェイ → 利用者
仕組み
ビルドから実行まで、3段階の隔離を順番に通過します。順序に意味があります。
わからなければ、通さない
ビルド成果物は診断ゲートを通過します。重大な検出、あるいはスキャナ自体のエラーがあれば、そこでデプロイは止まります。成功したふりはしません。
実行はコンテナの外側が締める
Egressは既定で拒否、エッジの衛生設定を強制します。ログインは SSOゲートウェイの裏側に置かれ、利用者はそこを通って初めてアプリに触れます。
できること
持ち込み型のPaaSとして、最低限やるべきことを固く守ります。
隔離
ビルドは常に使い捨ての隔離環境で実行されます。本番レジストリへのpushは、ビルドVMの外側にある信頼された制御プレーンだけの仕事です。
衛生の下限を強制
スキャンゲートは fail-closed。重大な検出でもスキャナのエラーでも、そこで止まります。何も見つからなかったことにはしません。
セルフサーブSSO
サインアップしてワークスペース（テナント）を作れば、その場でアプリを SSOゲートウェイの裏側にデプロイできます。
スコープの話
正直に言います。過大に見せることはしません。
// これは
- 隔離実行 + 既知の残存リスクを前提にした運用です
- ビルド・スキャン・実行それぞれで衛生を強制します（fail-closed、Egress既定拒否、エッジ衛生）
- セルフサーブで SSOゲートウェイの裏側にアプリを置けます
// これではありません
- 「任意の未検証コードに対して安全」ではありません
- アプリ内部の認可（BOLA・RLSなどテナントのデータアクセス制御）を肩代わりするものではありません
- 透過的なレトロフィットやビジネスロジック検査は対象外です