メインコンテンツへスキップ
アイデンティティとアクセス管理制御は、誰がDroidを実行できるか、どの環境で、どのようなポリシーの下で実行するかを制御します。 このページでは、アイデンティティモデル、ロール、環境の概要を説明します。詳細なSSOとSCIM設定手順は SSO, IdP & SCIM Provisioning にあります。

​
アイデンティティモデル

すべてのDroid実行は、3つのアイデンティティ次元に関連付けられます：

User or machine identity

Human developers authenticate via SSO (SAML/OIDC), inheriting their directory groups and roles. Automation (CI/CD, scheduled jobs) runs under machine identities with long‑lived tokens or workload identities.

Org / project / folder

The active repo and .factory/ folders determine the org, project, and folder context. Policies at these levels decide which models, tools, and integrations Droid may use.

Runtime environment

Whether Droid is running on a laptop, in a CI runner, or in a sandboxed VM/devcontainer is captured as environment attributes. Policies can treat these differently (for example, higher autonomy only in CI or sandboxes).

Session metadata

Each Droid session records metadata such as session ID, CLI version, and git branch, which is available for audit and OTEL telemetry.

​
組織アイデンティティとSSO（概要）

ほとんどの企業は、Okta、Azure AD、またはGoogle Workspaceなどのアイデンティティプロバイダー（IdP）とFactoryを統合します。 高レベルでは：
  • 組織メンバーシップは、Factory組織とチームにマッピングされたIdPグループから派生します。
  • SSOサインインにより、開発者は企業の認証情報を使用してWebプラットフォームとDroidの両方にアクセスできます。
  • ロール情報（例：Owner、Admin、User）は、IdPグループからFactoryロールに流れます。
IdPアプリケーションの設定、属性のマッピング、プロビジョニングの有効化を含む、段階的なSSOとSCIM設定については、SSO, IdP & SCIM Provisioning を参照してください。

​
ロールベースアクセス制御（RBAC）

Factoryは3つの主要なアクター分類を区別します：
  • 組織管理者
    • モデルポリシー、グローバルコマンドの許可/拒否リスト、デフォルトのテレメトリターゲットを含む、組織レベルの .factory 設定を定義します。
    • どのデプロイメントパターン（クラウド、ハイブリッド、エアギャップ）がサポートされ、Droidバイナリがどこで実行できるかを決定します。
    • 最大自律性レベルやユーザー提供のBYOKキーが許可されるかどうかなどのセキュリティ機能を設定します。
  • プロジェクトオーナー/メンテナー
    • バージョン管理に存在するプロジェクトレベルの .factory/ フォルダーを所有します。
    • 組織ポリシーを弱めることなく拡張する、チーム固有のモデル、ドロイド、コマンド、フックを提供します。
    • Droidを特定のリポジトリやディレクトリに制限するなど、プロジェクト固有のポリシーを設定します。
  • 開発者
    • ~/.factory/ で個人設定をカスタマイズします（例：許可されたセット内でのデフォルトモデル選択）。
    • ローカル、IDE、またはチーム提供のスクリプトやCIジョブを通じてDroidを実行します。
    • 組織またはプロジェクトレベルで定義された設定を上書きすることはできません。
ロール割り当てはIdPからFactoryに流れ、階層設定エンジンが各ロールが実際に変更できる内容を強制します。正確な優先順位ルールについては Hierarchical Settings & Org Control を参照してください。

​
デバイス、環境、ワークスペーストラスト

DroidはCLIであるため、多くの環境で実行できます：
  • 開発者のラップトップ（macOS、Linux、Windows）
  • リモート開発サーバーまたはワークスペース
  • CIランナーとビルドエージェント
  • 強化されたVMとdevcontainer
エンタープライズ顧客は通常、Droidをエンドポイント管理とワークスペーストラスト制御と組み合わせます：
Use tools like Jamf, Intune, or other MDM solutions to control where Droid binaries can be installed, which users can run them, and which configuration files they can read.Common patterns include:
  • Only allowing Droid to run under managed user accounts.
  • Restricting configuration directories to corporate‑managed volumes.
  • Enforcing OS‑level disk encryption and screen lock policies.
Treat Droid as trusted only in known repositories and environments:
  • Pin Droid to specific paths or repos on developer machines.
  • Require elevated approval or sandboxed environments for untrusted code.
  • Use project‑level .factory/ folders to mark which repos are “Droid‑ready” and what policies should apply.
The same developer may run Droid in multiple contexts: on their laptop, in CI, or in an isolated container.Policies can take these differences into account:
  • Allow higher autonomy or more powerful tools only inside devcontainers or CI runners.
  • Restrict network access or command execution when running on laptops.
  • Tag OTEL telemetry with environment attributes to support environment‑specific alerting.

​
アイデンティティがポリシーとテレメトリにどのように流れるか

アイデンティティと環境情報は主に2つの方法で使用されます：
  1. ポリシー評価 – 階層設定（組織 → プロジェクト → フォルダー → ユーザー）はアイデンティティを使用して、特定の実行にどの設定バンドルが適用されるかを決定します。
  2. テレメトリと監査 – Droidは user.id、team.id、session.id、環境タグなどの属性を含むOTELメトリクス、トレース、ログを出力するため、組織別およびチーム別のダッシュボードを構築できます。
これらのアイデンティティがテレメトリでどのようにエンコードされるかの詳細については、Compliance, Audit & Monitoring を参照してください。