セキュリティと導入形態

GembaOS は、AI エージェントを職務権限規程・稟議・監査のもとで運用するための実行基盤です。ポリシーによる権限判定、パラメータに紐づくワンタイム許可証、人の承認記録を、オンプレミスまたはプライベート VPC 上で提供します。当社が提供するのは設計と検証結果であり、評価は貴社の監査の手に委ねます。

GembaOS はどこで動き、何が社外へ出ますか？

GembaOS は、貴社が管理するインフラ（オンプレミスまたはプライベート VPC）上で、専用のデータディレクトリを持つ単一の Linux バイナリとして動きます。貴社が経路を設定しない限り、何もそのネットワークを出ません。

「送出上限」は、テナントごと・プレイブックごとに「どの区分のモデル提供者（自社ホスト、プライベートクラウド、公開 SaaS）に、どの機密区分のデータを渡してよいか」を宣言するものです。プレイブックは、エージェントの役割にかかわらず、上限を超えるデータを送れません。自社ホストモデルと SaaS モデルを、部署ではなくデータの機密度で使い分けるための仕組みです。

エージェントは認証情報を持たずに、どうやって操作するのですか？

GembaOS は業務システムの認証情報を業務機能ゲートウェイに置き、いかなるプロンプトにも渡しません。エージェントが見るのは業務機能の名前と引数のスキーマだけで、すべての呼び出しは同じ順序でゲートウェイを通ります。

エージェントは何を閲覧できますか？データ参照権限とナレッジベースの境界制御

参照も書き込みと同様に、業務機能ゲートウェイによって強制的に統制されます。GembaOS は「データベースの全レコードや社内文書をモデルにそのまま渡し、プロンプトの指示で機密を守らせる」といった楽観的なアプローチをとらず、データがモデルのコンテキストに入る前に物理的な境界を適用します。

• 項目レベルのマスキングと除外（Field-Level Pruning）：権限のない項目（クレジットカード番号、個人識別番号、給与情報、社内評価など）はゲートウェイで物理的に切り落とされ、プロンプトには流入しません。エージェントが受け取るのは、その役割のスキーマで宣言された許可項目のみです。
• 他顧客データの参照遮断：データベース参照は、あらかじめ定義されたパラメータ化クエリや指定項目の読み取り専用ビューに限定され、自由な SQL の組み立ては拒否されます。検索条件は作業票に紐づく顧客・テナント ID に厳密にバインドされ、他の顧客のレコードを横断的に探索・取得することはできません。
• 探針（プロービング）を防ぐ文書検索境界：社内文書を検索する際、エージェントは承認・公開済みの正式版のみを検索できます。未承認の下書きや権限外のフォルダは最初から対象外です。閲覧権限のない機密文書へのアクセスには、実在しない場合と全く同じ「文書が存在しません（Not Found）」を返し、モデルが推測を繰り返して機密の存在を探る行為を防ぎます。
• 代行権限の上限（On-Behalf-Of）：エージェントが社員の名義で動く場合、有効な参照権限は「エージェントの役割権限」と「ログインしている社員本人の閲覧権限」の積集合（両方に認められた範囲）に制限されます。社員本人が見られない機密データは、エージェントも代行して取得できません。
• 拒否された参照の記録：権限外の参照試行はすべてゲートウェイで遮断され、監査証跡として記録されます。不審な試行や異常な読み取りエラーが発生した場合、作業票にリスク印が付与され、管理者に通知されます。

承認済みの操作は、改ざんからどう守られますか？

GembaOS はすべてのワンタイム許可証を承認済み引数のハッシュ（argsHash）に紐づけ、一度だけ発行し、期限を付けます。異なる引数の呼び出しは許可証と一致せず拒否されます。承認済みの呼び出しを実行すると許可証は消費され、二度目も拒否されます。実行の前にガバナンスカーネルは、プレイブックが指定する前提条件を読み直し、稟議書上の事実と照合します。押印の後に状況が変わっていれば、実行せずに起案者へ差し戻します。押印後に変わった注文は、新しい起案です。

プロンプトインジェクションをどう扱いますか？

GembaOS は外部の内容をデータとして扱い、権限の根拠にはしません。メール、チャット、ログ行、文書、画像に埋め込まれた指示文が権限を与えることはありません。操作を許可する判断は、モデルの外側にあるポリシーが行うからです。

• 指示文の混入が疑われる内容は、作業票に不審な入力として印が付きます。印の付いた操作は、エージェントの提案にかかわらず人へ回ります。
• プレイブックに書かれたエスカレーション条件は、モデルの判断に委ねず、ガバナンスカーネルが強制します。
• 添付や画像もデータです。画像がモデルに届くのはプレイブックが許す場合だけで、それについてのモデルの出力もデータのままです。
• 記録済みのレッドチーム事例（プロンプトインジェクション、パラメータ改ざん、権限昇格、認証情報の持ち出し）は、変更のたびにテストとして再生されます。貴社のセキュリティ担当と一緒に一つずつ確認します。

人はどのように押印し、どのように本人確認されますか？

GembaOS は人の押印を、押印する本人が持つパスキー（WebAuthn）に結び付けます。高リスクの経路にはハードウェアキーを必須にできます。社員は貴社の ID プロバイダーに OIDC でサインインし、社員名簿は貴社のエクスポートから取り込みます。名簿を勝手に作ることはありません。このサイトのデモ画面はデモ用のパスキーで押印しています。本番では貴社の社員自身のパスキーを使います。代理人、上申先、稟議を引き取った上長も、それぞれ自分のパスキーで押印し、押印チェーンには誰の代理かが残ります。

監査記録には何が残り、検証できますか？

GembaOS は作業票のすべての事象を、順序どおりにハッシュチェーンで記録します。エージェントの手番、ポリシー判定、業務機能の呼び出し、押印、許可証、実行。ポリシー再判定は記録済みの判定を現行ポリシーで再実行し、同じ経路と規則チェーンを導きます。監査再生の画面がそれを示します。顧客が受け取る正式回答は、社内の稟議記録とは分離して保持されます。マルチテナント構成では、テナントごとに実行基盤とストレージが分かれます。

監査で使われる基準に、どの統制が対応しますか？

GembaOS の仕組みは、監査人がすでに使っている統制項目に対応付けられます。監査人の評価を置き換えるものではありません。

個人情報保護法上、クラウドモデルへの送信は委託先への提供に当たり得ます。送出上限とプレイブックの項目マスキングは、その範囲を貴社が決めるための道具です。

貴社のセキュリティ担当と、何を確認しますか？

1. 導入構成のアーキテクチャ確認: ネットワーク上の位置、TLS またはプロキシ、ID プロバイダー、アダプター。
2. 脅威モデルとレッドチーム事例。実行基盤に対してその場で再生します。
3. 先行導入の最初の 2 週間を経た、貴社業務のゴールデンテスト。
4. 上の表を、貴社の連携先とモデルごとに埋めたデータフロー表。
5. 導入チェックリスト: サービス登録、TLS、リバースプロキシ、データディレクトリのバックアップ。

関連: 先行導入パートナー、よくあるご質問、用語集。