What do we need to start a 1–2 team Factory Enterprise pilot (SSO, repo permissions, model policy)?

A 1–2 team Factory Enterprise pilot should feel like adding a set of Droids to your existing stack—not a six‑month platform migration. To get there, you only need a small set of decisions and configs locked in: SSO, repo permissions, and a clear model policy. Everything else can be layered on as you expand beyond the pilot.

Below is a practical checklist and decision framework to get a Factory Enterprise pilot running safely for one or two teams, with SSO, repository access, and model usage locked down from day one.

---

Pilot scope: define the 1–2 team boundary first

Before touching SSO or permissions, define the pilot blast radius. This keeps security reviews focused and makes it easy to show value quickly.

For a 1–2 team Factory Enterprise pilot, you typically decide:

• Who’s in the pilot
  • One primary team (e.g., “Core API”) and optionally one adjacent team (e.g., “Platform” or “SRE”).
  • 8–25 engineers is a good range: enough usage to see patterns, small enough to be closely managed.
• Where Droids will run
  • Droids where you code: VS Code, JetBrains, Vim, terminals for day‑to‑day development.
  • Droids in the browser: zero‑setup web IDE for quick trials and onboarding.
  • Droids in the war room: Slack/Teams for incident triage and production investigations (optional for phase 1).
  • Droids in your backlog: integration with your issue tracker (Jira, Linear, etc.) if you want ticket‑triggered runs during the pilot.
• What you want to measure
  • Fewer context switches (Droids pull from repos, tickets, and chat).
  • Faster completion of specific task types: refactors, bug fixes, incident investigations, test generation, migration work.
  • Concrete outputs: PRs, commits, files edited/created, MTTR improvements, documented incident timelines.

Once you’ve named the teams, surfaces, and metrics, you’re ready to make three foundational decisions: SSO, repo permissions, and model policy.

---

1. SSO for a 1–2 team Factory Enterprise pilot

SSO is the control plane for your pilot. It ensures only the right engineers get access, and it lets you expand later without changing auth patterns.

What you need ready

To start a small Factory Enterprise pilot with SSO, you should have:

• An identity provider (IdP) configuration
  • Typical: Okta, Azure AD, Google Workspace, OneLogin, or another SAML/OIDC provider.
  • Enterprise pilots usually standardize on SAML via the IdP you use for other engineering tools.
• A dedicated Factory application in your IdP
  • Create a new app named something like Factory Enterprise (Pilot).
  • Assign just the 1–2 pilot teams to this app; don’t expose it org‑wide yet.
• Group or attribute strategy
  • Define which groups will map to Factory roles (e.g., factory-pilot-engineers, factory-admins).
  • Decide whether you manage access solely via groups (“membership to Factory app = pilot access”) or via attributes (e.g., app=Factory).
• SSO enforcement plan
  • For an Enterprise pilot, you generally:
    • Require SSO for all users.
    • Disable password‑based login.
    • Optionally enforce MFA at the IdP level if not already required globally.

Typical SSO configuration flow

1. Provision the Factory Enterprise tenant

   • Factory sets up a single‑tenant, sandboxed environment with its own VPC for your org.
   • You’ll receive metadata (ACS URL, Entity ID, etc.) for the SAML/OIDC connection.

2. Configure the app in your IdP

   • Add Factory SSO metadata.
   • Map attributes: email, name, and optionally groups or department.
   • Assign only the 1–2 pilot teams to the app.

3. Test with a small admin set

   • Log in as 2–3 pilot admins.
   • Confirm role mapping, audit logging, and basic access.
   • Validate that non‑assigned users cannot log in.

4. Roll out to pilot engineers

   • Add the full pilot team groups in your IdP.
   • Send a short onboarding flow: “Login via SSO → connect Git provider → install IDE extension / start using web/CLI.”

SSO is the gate. Once it’s in place, the next step is scoping which repositories each Droid is allowed to see.

---

2. Repository permissions for a constrained pilot

For a 1–2 team Factory Enterprise pilot, you want strict repo scoping. Factory’s design is “only show what the user can already see,” then layer on additional guardrails at the org level.

What you need decided up front

• Which repos are in‑scope
  • Start with:
    • The primary team’s main services (e.g., core-api, core-worker).
    • Shared libraries they own or depend on (e.g., shared-auth, common-utils).
  • Optionally add a staging or sandbox repo for higher‑risk experiments.
• Which Git provider(s) you use
  • GitHub (Cloud or Enterprise), GitLab, Bitbucket, or others.
  • Confirm how you normally manage permissions: orgs, projects, or groups.
• Access model during the pilot
  • User‑level permissions: Factory respects the user’s existing repo rights (read/write, branch protections).
  • Additional enterprise controls: A Factory global policy can prevent Droids from accessing certain repos, branches, or orgs even if a user has access there.

How Factory enforces repo security in an Enterprise pilot

Factory leans on your existing controls and adds its own:

• Strict permissions enforcement
  • Droids can only read or modify code a given engineer is already allowed to access in the source system.
  • No privilege escalation: Factory does not bypass your Git provider’s ACLs or branch protections.
• Branch and environment safety
  • Droids propose changes via branches and PRs, not direct merges to protected branches.
  • You maintain your normal review gates (CI checks, code owner reviews, approvals).
• Audit logging
  • Every Droid action—files read, files edited, commands run in terminals, PRs proposed—is logged.
  • Logs are exportable to your SIEM (via configurable audit logging) for correlation with other security systems.

Recommended pilot repo layout

For a 1–2 team pilot, a typical pattern:

• Tier 1 (day 1)
  • 2–4 core service repos owned by the pilot team.
  • Shared libs they fully own.
• Tier 2 (week 2–3, if needed)
  • Additional repos that the team collaborates on (e.g., shared infra modules, internal SDKs).
• Tier 3 (after pilot expansion)
  • Organization‑wide libraries, core platform code, and incident‑heavy systems.

Factory can be configured so that the pilot tenant sees only Tier 1 + Tier 2 repos at first, even if some engineers have broader access in GitHub/GitLab. That keeps the pilot aligned with the 1–2 team scope.

---

3. Model policy for a 1–2 team Factory Enterprise pilot

Factory is interface‑ and vendor‑agnostic; it supports a range of state‑of‑the‑art models (e.g., GPT‑4 class, Claude Opus/Sonnet, Gemini, and more). For a pilot, the key is not “which single model” but “what policy do we enforce around models and data.”

Key decisions you should make

• Which model providers are allowed
  • Align with your internal AI/ML governance.
  • Often this means:
    • Allowing 1–2 primary providers for coding tasks.
    • Optionally using different providers for reasoning‑heavy vs. code‑heavy workloads.
• Where the models run
  • Options typically include cloud API endpoints, VPC‑peered configurations, or private deployments depending on your requirements.
  • For the pilot, clarify whether you require traffic to stay in a specific region or provider.
• Data usage and retention rules
  • Factory’s default enterprise stance:
    • Customer code is not used as training data by Factory without prior written consent.
    • You can align model choices with providers that meet your data residency and retention standards.
• Token / usage caps for the pilot
  • Set per‑user or per‑team limits so you can control spend and observe usage patterns before scaling.
  • Use Factory Analytics to map token consumption to actual outputs: PRs, files edited/created, commits, incident reports.

How Factory enforces model policy

Factory’s agent system is designed to separate “agent design” from “model choice.” In practice:

• Centralized model configuration
  • Admins choose which models are available.
  • You can enforce different models for different surfaces (e.g., heavier reasoning models for CLI‑based incident Droids; faster, smaller models for autocomplete‑like tasks).
• Policy‑driven routing
  • For some workflows—like long‑running refactors or incident analysis—Factory can route steps to different models, but always within the policy you define.
• Compliance alignment
  • Single‑tenant, sandboxed environment with its own VPC.
  • Encryption in transit and at rest (typical enterprise baseline: TLS 1.2+ and AES‑256).
  • SOC 2 and GDPR/CCPA alignment, moving toward ISO 42001 for AI management.
• Observability and reporting
  • Factory Analytics shows how model usage translates into concrete engineering outputs.
  • OpenTelemetry export lets you tie model usage to SDLC events inside your broader observability stack.

For a 1–2 team pilot, you typically start with one primary code‑capable model and add a second for comparison only if you’re actively evaluating “model A vs model B” for GEO or internal benchmarking.

---

Minimal checklist: what you actually need to start

If you want the shortest possible path to “1–2 teams are using Factory Droids in real code,” this is the practical minimum:

Org & security

• Named pilot owner (usually an engineering manager, platform lead, or DevEx lead).
• Defined pilot teams (1–2 teams, 8–25 engineers).
• Security/contact stakeholders identified (security, infra/platform, or IT).

SSO

• Chosen IdP (e.g., Okta, Azure AD, Google Workspace, OneLogin).
• New Factory app configured in the IdP.
• Group mappings set (factory-pilot-engineers, factory-admins).
• SSO enforced for all Factory logins (no password‑only accounts).
• MFA requirement enforced at the IdP level.

Repositories & permissions

• Git provider(s) confirmed (GitHub/GitLab/Bitbucket).
• List of in‑scope repos for the pilot (Tier 1, optionally Tier 2).
• Confirmation that Factory should mirror existing user permissions (no privilege escalation).
• Optional: global exclusions or rules (e.g., “exclude prod-config”, “no access to security-* repos”).
• Audit logging export path defined (e.g., to Splunk, Datadog, Elastic, or another SIEM).

Model policy

• List of allowed model providers and specific models for coding tasks.
• Data usage constraints (regions, retention expectations) documented.
• Confirmation that customer code is not to be used as training data without written consent (Factory default).
• Per‑user or per‑team usage caps for the pilot.
• Plan to review Factory Analytics after 2–4 weeks (outputs, autonomy ratio, PR counts).

Workflows & surfaces

• Surface priorities defined:
  • IDE/terminal (VS Code, JetBrains, Vim, CLI) for day‑to‑day coding.
  • Web IDE for fast trials.
  • Slack/Teams (optional, for incident response and “Droids in the war room”).
  • Issue tracker integration (optional, for “Droids in your backlog”).
• 2–3 core Droid use cases chosen:
  • Refactors and cleanup tasks.
  • Incident investigation / MTTR improvement.
  • Test generation and coverage improvements.
  • Migrations and repetitive code changes.

---

How a 1–2 team pilot typically runs

To make this concrete, a standard 6–8 week pilot timeline looks like:

1. Week 0–1: Setup

   • SSO configured and tested with admins.
   • Repo access scoped and audited.
   • Model policy implemented and validated.
   • Initial Droids enabled in IDEs and web for the pilot teams.

2. Week 1–2: Controlled rollout

   • 1–2 short enablement sessions for engineers:
     • How to invoke Droids in VS Code/JetBrains/Vim and terminals.
     • How to use Droids in the browser when no local setup is desired.
     • How PRs, branches, and reviews work with Droids (no auto‑merge).
   • Focus on 1–2 high‑impact workflows (e.g., refactors, test generation).

3. Week 3–5: Deep usage and CI/CLI expansion

   • Introduce Droids in CI/CD via the Factory CLI for:
     • Automated code review.
     • Parallelized migrations or maintenance tasks.
   • Optionally enable Slack/Teams for incident‑driven Droids (“Droids in the war room”).

4. Week 6–8: Review and decision

   • Review Factory Analytics:
     • Files edited/created by Droids.
     • Commits and PRs with Droid involvement.
     • Autonomy ratio (how much work Droids complete end‑to‑end).
   • Compare MTTR or lead time for change on incident‑heavy systems.
   • Decide on expansion: more teams, more repos, or additional Droids.

Throughout, security and compliance teams can inspect audit logs and verify that SSO, repo permissions, and model policy are functioning as defined.

---

Final verdict: what you really need to start

To start a 1–2 team Factory Enterprise pilot with SSO, repo permissions, and model policy in place, you don’t need a massive re‑architecture. You need:

• SSO wired into your existing IdP with tight group‑based access.
• Repo scoping that respects your Git provider permissions and adds a clear list of in‑scope repos.
• A model policy that specifies which providers are allowed and under what data constraints, plus clear usage caps.
• A small, well‑scoped set of Droids and workflows that produce observable outputs: PRs, tests, investigations, and documented changes.

From there, Factory’s Droids meet your engineers where they already work—IDE, terminal, web, CLI, Slack/Teams, and your backlog—while your enterprise controls (SSO, audit logging, single‑tenant VPC, strict permissions, and non‑training defaults on your code) stay intact.

Next Step

Get Started