メインコンテンツへスキップ
Factory は LLM を強力であるが信頼できないコンポーネントとして扱います。Droid のセーフティモデルは決定論的制御、プログラマブルフック、およびサンドボックスランタイムを組み合わせることで、最先端のモデルでも高セキュリティ環境で安全に動作できるようにします。

​
2層のセーフティ

我々は以下を区別しています：
  1. 決定論的制御 – モデルの動作に依存しない厳格な境界。
  2. LLM ステアリング – 保証を提供することなく、モデルをより良い動作へと導くプロンプトとコンテキスト。
エンタープライズセキュリティは主に決定論的制御上に構築されるべきです。ステアリングは利便性向上のためのものです。

Deterministic controls

  • Command risk classification
  • Global and project‑level allow/deny lists
  • File and repo protection
  • Droid Shield secret scanning
  • Hooks for enforcement and logging
  • Sandboxed VMs and containers

LLM steering

  • Project and org‑level rules and instructions
  • Standardized commands and workflows
  • Context selection and enrichment via MCP
  • Model choice and reasoning effort defaults

​
コマンドリスク分類

Droid が提案するすべてのシェルコマンドは、パターンとコンテキストに基づいて（例：ファイル削除、ネットワークアクセス、パッケージインストール、データベースアクセス）リスクレベルに分類されます。 典型的なレベルには以下が含まれます：
  • 低リスク – 読み取り専用コマンドとローカル診断（例：ls、cat、git status）。
  • 中リスク – コードを変更したり依存関係をインストールするコマンド（例：npm install、go test ./...）。
  • 高リスク – データを削除したり、システム設定を変更したり、機密リソースとやり取りするコマンド（例：rm -rf、kubectl delete、本番環境に対する psql）。
組織およびプロジェクトポリシーは、リスクレベルを動作にマッピングできます：
  • 低リスクコマンドを常に許可する。
  • 中リスクコマンドにはユーザー承認を要求する。
  • 高リスクコマンドを完全にブロックするか、特定の環境（例：隔離されたdevcontainer）でのみ許可する。
リスク情報はOTEL経由でも出力されるため、セキュリティチームは高リスクコマンドが提案または実行される頻度を監視できます。

​
コマンドの許可リストと拒否リスト

管理者は階層設定でグローバルおよびプロジェクト固有の許可/拒否リストを定義できます：
  • 拒否リスト – 決して許可されないコマンドのパターン（例：rm -rf、sudo *、curl *://sensitive-endpoint）。
  • 許可リスト – 特定の環境で追加の承認なしに実行できる特定のコマンドまたはパターン。
設定は拡張のみであるため：
  • 組織レベルの拒否と許可はプロジェクトやユーザーによって削除することはできません。
  • プロジェクトはリポジトリ内で追加の許可や拒否を加えることができます。
  • ユーザーはポリシーを弱めることはできません。より厳格な個人デフォルトを選択するのみです。
これにより、数千台のマシン間でコマンドポリシーの一貫性を保ちながら、ローカルな特殊化も可能になります。

​
Droid Shield：シークレットスキャンとDLP

Droid Shield はシークレットと機密コンテンツのための専用保護層を追加します。 有効にした場合、Droid Shield は以下ができます：
  • ファイルが読み取りまたは編集される前にファイルをスキャンする。
  • モデルに送信される前にプロンプトをスキャンする。
  • 実行される前にコマンドをスキャンする。
以下のようなパターンを検出します：
  • API トークンとアクセスキー。
  • パスワードとデータベース接続文字列。
  • 秘密鍵と証明書。
  • 組織固有の識別子（設定可能なパターン）。
ポリシーに基づいて、Droid Shield は以下ができます：
  • 操作を完全にブロックする。
  • 継続する前に機密部分を編集する。
  • セキュリティレビューのためにOTELイベントとログを出力する。
  • より深い分析のためにフック経由で顧客DLPサービスを呼び出す。
組織管理者は組織およびプロジェクトレベルでDroid Shieldを設定します。ユーザーは強制される場所でそれを無効にできません。

​
強制とログのためのフック

フックは Droid のプログラマブルなセーフティと可観測性インターフェースです。エージェントループの重要なポイントで独自のコードを実行できます。 一般的なフックポイントには以下があります：
  • プロンプト送信前 – シークレット、PII、またはポリシー違反についてプロンプトを検査。
  • ファイル読み取りまたは書き込み前 – 機密ファイルへのアクセスをブロックまたは編集。
  • コマンド実行前 – 承認ワークフローを強制または危険なコマンドをブロック。
  • git操作前 – 未承認の git push または制限されたブランチとのやり取りを防止。
  • コード生成または編集後 – リンター、セキュリティスキャナー、または内部コンプライアンスチェックを実行。
典型的なエンタープライズユースケース：
Require all code changes to flow through your existing tooling by blocking git push in Droid sessions and instructing developers to use internal CL/PR tooling instead.
Forward prompts and file snippets to your DLP or CASB APIs before they reach LLMs; deny or redact operations that violate policy.
Allow certain tools and commands only in CI or sandboxed environments, based on environment tags emitted by Droid.
実装詳細と例については Hooks Guide と Hooks Reference をご覧ください。

​
コンテナとVMによるサンドボックス化

サンドボックス化されたdevcontainerとVMでDroidを実行することで、本番システムを公開することなく、有用な場所でより多くの自律性を安全に付与できます。 推奨パターン：
  • 制限されたファイルシステムマウントとネットワーク出力を持つDocker/PodmanのdevcontainerOSを使用する。
  • 本番データベースやシークレットに直接アクセスできないコンテナやVM内でのみ、より高い自律性でDroidを実行する。
  • サンドボックス環境と本番隣接環境で別々の認証情報と環境変数を使用する。
OTELテレメトリでは、環境別のダッシュボードとアラートを構築するために、環境でセッションにタグ付けできます（例：environment.type=local|ci|sandbox）。

​
モデルを安全な動作に向けてステアリング

決定論的制御が基盤である一方、LLM ステアリングは品質を向上させ、危険なアクションが提案される頻度を減らします。 組織およびプロジェクト設定では以下を定義できます：
  • ルールと指示 – すべてのリクエストに適用されるセキュリティガイドライン、コーディング標準、および組織固有の指示。
  • 標準化されたコマンドとワークフロー – 安全なパターンを組み込んだ共有コマンド（例：/security-review、/migrate-service）。
  • コンテキストエンリッチメント – モデルが推測ではなく正確な情報を持てるように、ドキュメント、ランブック、内部APIを公開するMCPサーバー。
これらは指示であって強制ではないため、上述の厳格な境界を置き換えるのではなく補完します。