03 / セキュリティと導入
セキュリティと導入形態
GembaOS は、AI エージェントを職務権限規程・稟議・監査のもとで運用するための実行基盤です。ポリシーによる権限判定、パラメータに紐づく一次性許可証、人の承認記録を、オンプレミスまたはプライベート VPC 上で提供します。このページは 2026 年 9 月時点（v0.2）の事実を書いています。取得していない認証は書きません。同時点で GembaOS は SOC 2、ISO 27001 その他の第三者認証を取得していません。当社が提供するのは設計と検証結果であり、評価は貴社の監査の手に委ねます。
GembaOS はどこで動き、何が社外へ出ますか？
GembaOS は、貴社が管理するインフラ（オンプレミスまたはプライベート VPC）上で、専用のデータディレクトリを持つ単一の Linux バイナリとして動きます。貴社が経路を設定しない限り、何もそのネットワークを出ません。
| 構成要素 | 動く場所 | 社外へ出るもの |
|---|---|---|
| 実行基盤、ポリシーエンジン、能力ゲートウェイ | 貴社のサーバー | なし |
| 承認者・運用者向けコンソール | 同じバイナリ。自前の証明書による TLS、または貴社のリバースプロキシ配下 | なし |
| モデル | 自社ホスト、または貴社が選ぶクラウド事業者 | 自社ホスト: なし。クラウド: プレイブックが許すプロンプト内容のみ。下記の上限に従う |
| 業務システム | 貴社ネットワーク内から呼ぶアダプター: REST、ファイル、SQL、相互 TLS 経由のワーカー | 承認された一回の呼び出し |
| チャネル（メール、Teams、Slack、電話、Web ウィジェット） | 貴社の認証情報で設定した接続 | そのチャネルのメッセージ内容 |
「送出上限」は、テナントごと・プレイブックごとに「どの区分のモデル提供者（自社ホスト、プライベートクラウド、公開 SaaS）に、どの機密区分のデータを渡してよいか」を宣言するものです。プレイブックは、エージェントの役割にかかわらず、上限を超えるデータを送れません。自社ホストモデルと SaaS モデルを、部署ではなくデータの機密度で使い分けるための仕組みです。
エージェントは認証情報を持たずに、どうやって操作するのですか？
GembaOS は業務システムの認証情報を能力ゲートウェイに置き、いかなるプロンプトにも渡しません。エージェントが見るのは能力の名前と引数のスキーマだけで、すべての呼び出しは同じ順序でゲートウェイを通ります。
| 段階 | 誰が | 何を照合するか |
|---|---|---|
| 1. 起案 | 社員の名義で動くエージェント | 能力が存在し、引数がスキーマに合うこと |
| 2. ポリシー | ホスト | 職務権限規程、経路、前提条件、作業票のリスク印 |
| 3. 押印 | 委ねられた確認はエージェント、経路が求める段階はパスキーを持つ人 | 表示された稟議書そのもの: 事実、引数、理由 |
| 4. 許可証 | ホスト | 承認済み引数のハッシュに紐づく一回限りの一次性許可証 |
| 5. 実行 | ホストとアダプター | 前提条件を読み直し、承認者が見た内容と照合する。変わっていれば実行せず差し戻す |
| 6. 記録 | ホスト | 作業票上のハッシュチェーン事象 |
参照もゲートウェイを通ります。項目単位の閲覧規則により、エージェントは役割が見てよい項目だけを見ます。拒否された参照も、記録される事実の一つです。
承認済みの操作は、改ざんからどう守られますか？
GembaOS はすべての一次性許可証を承認済み引数のハッシュ（argsHash）に紐づけ、一度だけ発行し、期限を付けます。異なる引数の呼び出しは許可証と一致せず拒否されます。承認済みの呼び出しを実行すると許可証は消費され、二度目も拒否されます。実行の前にホストは、プレイブックが指定する前提条件を読み直し、稟議書上の事実と照合します。押印の後に状況が変わっていれば、実行せずに起案者へ差し戻します。押印後に変わった注文は、新しい起案です。
プロンプトインジェクションをどう扱いますか？
GembaOS は外部の内容をデータとして扱い、権限の根拠にはしません。メール、チャット、ログ行、文書、画像に埋め込まれた指示文が能力を与えることはありません。操作を許可する判断は、モデルの外側にあるポリシーが行うからです。
- 指示文の混入が疑われる内容は、作業票に型付きの懸念として記録されます。ホストはそれをリスクの印に変え、印の付いた操作はエージェントの提案にかかわらず人へ回ります。
- プレイブックに書かれたエスカレーション条件は、モデルの判断に委ねず、ホストが強制します。
- 画像は取り込み時に再エンコードされます。画素がモデルに届くのは境界の段階だけで、プレイブックとモデル設定の両方が許す場合に限られ、モデルの出力はデータのままです。
- 記録済みのレッドチーム事例（プロンプトインジェクション、パラメータ改ざん、権限昇格、認証情報の持ち出し）は、変更のたびにテストとして再生されます。貴社のセキュリティ担当と一緒に一つずつ確認します。
人はどのように押印し、どのように本人確認されますか？
GembaOS は人の押印を、押印する本人が持つパスキー（WebAuthn）に結び付けます。テナントの押印ポリシーで、高リスクの経路にハードウェアキー等級を要求できます。社員は貴社の ID プロバイダーに OIDC でサインインし、社員名簿は貴社のエクスポートから取り込みます。名簿を勝手に作ることはありません。このサイトのデモ画面に見えるモックのパスキーは、公開姿勢の構成では拒否されます。
監査記録には何が残り、検証できますか？
GembaOS は作業票のすべての事象を、順序どおりにハッシュチェーンで記録します。エージェントの手番、ポリシー判定、能力呼び出し、押印、許可証、実行。ポリシー再判定は記録済みの判定を現行ポリシーで再実行し、同じ経路と規則チェーンを導きます。監査再生の画面がそれを示します。顧客が受け取る正式回答は、社内の稟議記録とは分離して保持されます。マルチテナント構成では、テナントごとに実行基盤とストレージが分かれ、すべての参照は要求したセッションの範囲に限られます。
監査で使われる基準に、どの統制が対応しますか？
GembaOS の仕組みは、監査人がすでに使っている統制項目に対応付けられます。監査人の評価を置き換えるものではありません。
| 監査で問われる統制 | GembaOS の仕組み |
|---|---|
| 最小権限、必要時のみのアクセス | 操作ごとの一回限りの一次性許可証。エージェントに常設の認証情報を持たせない |
| 職務分掌、二人承認 | 経路が人に留保する段階を含む押印チェーン。本人権限の範囲内の代理実行 |
| 変更管理（CAB） | サンドボックスで起案した変更セットを、承認を通してのみ適用 |
| ログの完全性と否認防止 | ハッシュチェーン事象、パスキーに結び付いた押印、確定的な再判定 |
| データの所在（FISC 安全対策基準、個人情報保護法の安全管理措置） | 自社インフラ上の単一バイナリ。プレイブックとテナントごとの送出上限 |
| モデルリスク管理 | モデル変更が本番に届く前のシャドー再実行とゴールデンテスト |
個人情報保護法上、クラウドモデルへの送信は委託先への提供に当たり得ます。送出上限とプレイブックの項目マスキングは、その範囲を貴社が決めるための道具です。
貴社のセキュリティ担当と、何を確認しますか？
- 導入構成のアーキテクチャ確認: ネットワーク上の位置、TLS またはプロキシ、ID プロバイダー、アダプター。
- 脅威モデルとレッドチーム事例。実行基盤に対してその場で再生します。
- 先行導入の最初の 2 週間を経た、貴社業務のゴールデンテスト。
- 上の表を、貴社の連携先とモデルごとに埋めたデータフロー表。
- 導入チェックリスト: systemd ユニット、TLS、HSTS、プロキシ配下のヘッダー、データディレクトリのバックアップ。
最終更新: · GembaOS v0.2