# 10 enterprise AI SDLC platforms. Where does control live? Compare ten enterprise AI software delivery platforms, including Factory, Claude Code, GitHub Copilot, Kiro, and SprintLoop, with primary sources and a practical governance evaluation protocol. Canonical: https://aisdlc.ai/enterprise-ai-sdlc-platforms Sources reviewed: 2026-09-17 ## Publisher disclosure and evidence AISDLC.ai is published by LockedIn Labs, which owns SprintLoop. SprintLoop is included as a publisher-affiliated product under the same documentation and evaluation criteria. This is a source-based shortlist, not an independent ranking or a completed hands-on benchmark. Products are alphabetical, not ranked. Documented capability is not verified enforcement. No platform has been run through this protocol. ## The platform shortlist Ten products spanning coding environments, agent execution, and delivery governance. Selected for relevant public enterprise documentation and coverage of these different layers; listed alphabetically, with no rank implied. This is a documentation review, not an exhaustive market survey. Product tiers, versions, deployment modes, and configured permissions change the result. Claude Code is the product; Anthropic’s AI-native SDLC playbook is a separate methodology reference. ### Claude Code Coding environment Claude Code is a coding agent that can be configured for an enterprise deployment. Anthropic's AI-native SDLC playbook is a methodology and course, not a separately evaluated enterprise control-plane product. **Documented controls:** Team and Enterprise organizations can distribute server-managed settings, while endpoint management can protect device policies at the operating-system level. Managed permissions and sandbox settings govern supported agent actions; policy reach and failure behavior differ between local, cloud and third-party-provider sessions. **What to validate:** Can an unmanaged device, alternate provider or modified client reach enterprise repositories and deployment credentials without passing an external policy gate? **Availability and evidence limits:** Documentation review only. Anthropic explicitly describes server-managed settings as client-side controls rather than a security boundary. Direct provider routing can skip server-managed delivery; endpoint management or an appropriate gateway is needed for those cases. The Bash sandbox supports macOS, Linux and WSL2, not native Windows, and does not itself isolate all other tool surfaces. Sources reviewed 2026-09-17: - [Configure server-managed settings]() - [Configure the sandboxed Bash tool]() - [The AI-native SDLC playbook — Introduction]() ### Cursor Coding environment Cursor offers editor, CLI and Cloud Agent workflows with enterprise identity, device management and administration options. **Documented controls:** Enterprise documentation describes centrally enforced sandbox, model, repository, BYOK and network controls, with SSO/SCIM and managed device policies. Enterprise audit logs cover authentication and administrative actions; hooks and OpenTelemetry provide separate paths for development-activity evidence. **What to validate:** Which centrally enforced settings cover the editor, CLI and Cloud Agents, and can the organization reconstruct every material agent action rather than only administrative events? **Availability and evidence limits:** Documentation review only. Many controls require the Enterprise plan. Local Run Modes do not govern Cloud Agents. Rules are non-deterministic steering, and standard audit logs do not include agent responses or generated code; configure and validate the additional activity evidence pipeline. Sources reviewed 2026-09-17: - [Enterprise]() - [Security and Privacy Hardening]() - [Compliance and Monitoring]() ### Devin Enterprise Agent platform Cognition's engineering agent executes in a Devbox; current deployment documentation offers Enterprise Cloud and Customer Dedicated Deployment. Its reasoning service remains in Cognition's cloud in both models. **Documented controls:** Documented account- and organization-level custom roles cover repository permissions, integrations, sessions, secrets, MCP servers and audit-log access. Customer Dedicated Deployment uses a Cognition-managed, customer-isolated VPC with AWS PrivateLink or an IPSec tunnel to enterprise resources. Enterprise controls for Devin Desktop and CLI can constrain models, permissions, MCP/ACP and networking above local user/project configuration. Organization overrides replace root values; policy updates may take up to 15 minutes. **What to validate:** Can a representative agent identity reach an unapproved repository or deployment credential, and can an organization override weaken the enterprise baseline without a separately authorized decision? **Availability and evidence limits:** Dedicated deployment and Enterprise Assured with customer-managed keys require a commercial discussion. Current canonical docs do not list the customer-hosted VPC option still appearing in older search results. Local controls are distinct from cloud Devbox deployment controls. Sources reviewed 2026-09-17: - [Enterprise Deployment]() - [Custom Roles & RBAC]() - [Local Agent Controls]() ### Factory (Droid) Agent platform Factory documents Droid as a local agent runtime for developer machines, CI runners and controlled enterprise environments, with cloud, hybrid and airgapped deployment patterns. **Documented controls:** Organization-managed settings define model and MCP allowlists, autonomy ceilings, command controls, hooks and sandbox policy. Documented sandbox modes cover individual commands or the whole Droid process; organization deny rules cannot be removed through lower-level configuration. **What to validate:** What blocks execution if the managed policy is missing, invalid or stale, and which controls still apply when a developer uses an older client or another coding tool? **Availability and evidence limits:** Documentation review only. Factory says a malformed system-managed settings file resolves to an empty policy and logs the failure; validate this before relying on fail-closed enforcement. Sandbox reads allow all paths unless explicitly denied, and permitted network destinations can still receive data. Confirm enterprise entitlement and the selected deployment architecture with Factory. Sources reviewed 2026-09-17: - [Factory for Enterprise]() - [Enterprise Controls & Managed Settings]() - [Sandbox]() ### GitHub Copilot Coding environment GitHub Copilot combines developer assistance with a cloud agent integrated into repositories and pull-request workflows. Its enterprise value includes controls at the source-control boundary as well as coding-client policy. **Documented controls:** Enterprise and organization policies control feature and model access on supported surfaces. Copilot cloud agent is constrained by branch protections and required checks, cannot approve or merge its own pull requests, and provides attributable commits, session logs and administrative audit events. **What to validate:** Do repository rules, approval requirements and deployment gates still reject an unauthorized change if it arrives through a different user, bot, client or automation? **Availability and evidence limits:** Documentation review only. Copilot policies generally follow the assigned license and do not all cover every client surface. Cloud-agent firewall configuration and validation tools can be changed by administrators; document which settings are locked and test the actual runner/network setup. Sources reviewed 2026-09-17: - [GitHub Copilot policies for enterprises and organizations]() - [Risks and mitigations for GitHub Copilot cloud agent]() - [Customizing or disabling the firewall for GitHub Copilot]() ### GitLab Duo Agent Platform Delivery platform Agents and flows operate inside GitLab's development lifecycle, with GitLab.com, Self-Managed and Dedicated offerings. The platform is generally available from GitLab 18.8; individual features have separate maturity and licensing requirements. **Documented controls:** Documented tool governance supports allow, ask and deny decisions at execution time, with project rules constrained to be at least as strict as group rules. Governance is marked beta; background-flow and MCP enforcement have version and feature-flag dependencies. MCP server blocking for UI chat does not control IDE/CLI local server configuration. Self-hosted model deployment uses a self-hosted AI Gateway. Online licenses still require billing connectivity; offline deployment has a separate add-on and agreement. **What to validate:** Does the same denied operation fail through UI chat, IDE/CLI and background runners on the installed version, including an MCP route to the same resource? **Availability and evidence limits:** Do not conflate the generally available platform with beta governance. Check the installed GitLab version, credits, plan, feature flags and execution surface; some docs describe 19.4 capabilities. GitLab Duo Enterprise add-on compatibility requires 18.10 or later. Runner rules support Allow or Deny, not Ask; a tool without a configured runner rule defaults to Allow. The aggregate MCP search tool needs its own explicit rule because narrower search-tool rules do not apply to it. Sources reviewed 2026-09-17: - [GitLab Duo Agent Platform]() - [Agent tool governance]() - [Self-hosted models]() ### Harness Software Delivery Agent Delivery platform Harness positions Software Delivery Agent within its autonomous SDLC platform for CI/CD and infrastructure delivery. Worker Agents are configured as pipeline steps rather than standalone coding IDEs. **Documented controls:** Worker Agent documentation defines instructions, a model-provider connector and executable pipeline configuration; enterprise delivery controls must be assessed around those executed steps. The product describes pipeline RBAC, Open Policy Agent policies, deployment freezes and audit trails governing agent-driven delivery. Security-test policy documentation distinguishes warning-and-continue from error-and-exit, with policy sets evaluated after configured scan steps. A configured warning is not a release block. **What to validate:** Can an agent or human deploy the same artifact outside the governed pipeline, and do production credentials, policy administration and emergency overrides preserve an attributable approval boundary? **Availability and evidence limits:** Worker Agents are documented, but deployment mode, enabled modules, connectors and commercial entitlements must be checked for the actual tenant. No hands-on enterprise rollout or claim of all-path enforcement is established by this review. Sources reviewed 2026-09-17: - [Software Delivery Agent — AI Agent for CI/CD & IaC]() - [Harness Agents reference]() - [Policy as Code for Security Tests]() ### Kiro Coding environment Kiro provides spec-driven development agents across IDE, CLI and cloud surfaces, with enterprise identity and administration. **Documented controls:** Administrators can deploy permission policies to OS-protected paths used by local IDE and CLI clients; restrictive admin rules take precedence over personal permissions. The documentation specifies fail-closed behavior for malformed policy documents and separate governance controls for models, MCP and web tools. **What to validate:** Which exact policies apply to local, web and headless sessions, and what prevents users with local administrator rights or alternative credentials from operating outside them? **Availability and evidence limits:** Documentation review only. Local policies require a restart; unknown capabilities are skipped with a warning, so fleet version compatibility matters. A device policy does not by itself establish identical cloud enforcement. Enterprise authentication, region support and required versions must be verified for the deployment. Sources reviewed 2026-09-17: - [Permission policies]() - [Authentication]() - [Permissions]() ### OpenAI Codex Agent platform Codex combines local coding clients and hosted coding tasks. Enterprise administration distinguishes workspace access, local runtime requirements, cloud environments and permissions in connected systems. **Documented controls:** Managed requirements can restrict supported local clients' approvals, permission profiles, filesystem/network access and feature availability; configuration defaults are a separate, overridable mechanism. Requirements can be delivered through cloud configuration, system configuration and supported device management. Login-method and approved-workspace restrictions must be managed locally. Cloud tasks use hosted environments and repository connections; workspace membership alone does not authorize repository or connected-system actions. **What to validate:** Can the enterprise demonstrate effective policy for CLI, IDE and hosted runs, including alternate authentication methods, and prove that repository and production deployment authorization remains enforced outside the agent? **Availability and evidence limits:** Policy keys depend on supported client versions and plans. Cloud refresh can affect a later start rather than the running process. Do not treat local requirements as universal cloud or organization-wide deployment authorization. Current enterprise documentation redirects from developers.openai.com to OpenAI's learn.chatgpt.com documentation. Sources reviewed 2026-09-17: - [Admin rollout guide]() - [Managed configuration]() - [Codex cloud]() ### SprintLoop Delivery platform · Publisher-affiliated product SprintLoop describes a portfolio record connecting plans, agent-run records, model approvals, policies and named acceptance. It belongs to LockedIn Labs, the publisher of this comparison; it has not been independently benchmarked here. **Documented controls:** The public site describes approved-model registers, recorded agent stages and commits, advisory or blocking policy dispositions and named human acceptance. The security page describes database-enforced tenant isolation, append-only verdicts and permission checks at the workspace MCP endpoint. These are vendor-described controls, not runtime findings from this review. The homepage explicitly positions SprintLoop as the register and acceptance desk for external harnesses, not an agent execution engine; it says it does not execute builds or dispatch lanes. **What to validate:** Which decisions actually block execution in SprintLoop's own endpoints versus an external harness, and can a demonstrated end-to-end run prove that rejected model, tool and acceptance actions cannot proceed through another credential path? **Availability and evidence limits:** Public-site review only. No tenant, authentication, enforcement, benchmark or deployment test was performed. Product pages describe US-hosted customer records. The homepage says SprintLoop does not hold model keys or run agents, while the security page discusses runtime credential resolution and model-boundary enforcement; buyers should reconcile that scope in a demonstration. Sources reviewed 2026-09-17: - [SprintLoop — Project portfolio management (PPM) software]() - [Security and tenant isolation]() ## The enterprise owns the enforcement boundary A governed harness needs controls in the systems that grant access and release software. Validate the authorized paths, failure modes, and exceptions in your actual deployment. ### Authorize the actor Identity & platform teams Bind each task to an enterprise identity, repository, data boundary, and short-lived permissions. Restrict alternative credentials and unmanaged access paths. ### Constrain the execution Runtime & security teams Enforce tool authorization, sandbox boundaries, and network policy outside the agent’s editable instructions. Deny consequential actions when policy cannot be evaluated. ### Verify the candidate Engineering & assurance teams Run protected tests and evaluations under a separate identity. Bind the results to the exact artifact, policy version, and relevant configuration. ### Control the release Release & operations teams Only the release service receives deployment credentials. It validates the evidence and authorized decision, records the deployment, and supports revocation and recovery. **Test a defined threat model.** “Cannot be circumvented” is too broad without naming actors and access paths. Assess ordinary users, agents, administrators, alternate credentials, and emergency routes separately. Privileged exceptions require independent approval, scope, expiry, and an audit record. A reference diagram does not establish that a vendor implements these controls. ## Evaluation protocol — not yet run Use a versioned representative task pack, an existing-workflow baseline, the same acceptance rules, and comparable compute/time budgets. Record product tier, deployment mode, model/harness versions, effective policy, task difficulty, repeats, and exceptions. Randomize task order; separate pilot tuning tasks from held-out evaluation. Report failures, sample sizes, uncertainty, and limits before any ranking. ### Change the rules Test: Have the authoring identity attempt to weaken a required gate or edit its protected policy. Expected control: The unauthorized change is refused; a policy change needs a separately authorized review. Evidence to retain: Effective permissions, rejected action, protected policy revision, and review record. ### Go around the client Test: Attempt the same restricted operation through an unmanaged CLI, direct API, or alternative provider credential in a test environment. Expected control: The downstream identity or network boundary still refuses the action. Evidence to retain: Actor, route, target, enforcement decision, and corresponding downstream audit event. ### Impersonate the verifier Test: Submit a passing status from an identity that is not the approved verifier. Expected control: The merge or release service rejects the untrusted status producer. Evidence to retain: Status identity, required-check configuration, and rejection at the actual gate. ### Swap the approved artifact Test: Approve candidate A, then try to promote candidate B using A’s evidence. Expected control: The release is held until valid evidence and authorization cover B. Evidence to retain: Both artifact digests, evidence bindings, decision scope, and denied promotion. ### Cross the data boundary Test: Use synthetic secrets and a controlled destination to attempt prohibited network transfer from an agent tool. Expected control: Transfer is blocked at the configured boundary without placing real secrets in the test. Evidence to retain: Egress rule, tool identity, denied connection, and destination-side observation. ### Reach another workspace Test: Attempt to read or modify a synthetic resource in another test tenant with the first tenant’s identity. Expected control: Server-side authorization refuses access and preserves tenant isolation. Evidence to retain: Tenant and resource identities, authorization decision, and audit correlation. ### Lose the policy service Test: Make policy unavailable or invalid before a consequential action, then recover the service. Expected control: The action fails closed; recovery does not silently replay an unauthorized action. Evidence to retain: Failure mode, denied action, recovery sequence, and retry or idempotency record. ### Expire an exception Test: Exercise an explicitly authorized, time-limited exception, then repeat after expiry or revocation. Expected control: Only the approved scope succeeds; expired or revoked authority is rejected. Evidence to retain: Independent approver, scope, expiry, revocation, and both execution outcomes. ## Delivery metrics - **Accepted task rate:** Tasks accepted by the predefined checks and reviewer divided by all assigned tasks. Include failed and abandoned attempts. - **Cost per accepted change:** Total model, compute, and measured human-review cost across every attempt divided by accepted changes. State labor and pricing assumptions. - **Time to acceptance:** Report median and p95 from assignment through review and repair. Keep sample size visible and avoid tail claims from tiny samples. - **Human review and repair:** Minutes of human work and intervention counts per task, including escalations, corrections, and integration. - **Control challenge outcomes:** Publish each attempted bypass and its observed result. An untested control stays untested; a critical failure cannot be averaged away. - **Escaped defects:** Track defects after acceptance within a fixed observation window, with severity and task provenance. [Download the unscored evaluation worksheet](https://aisdlc.ai/enterprise-ai-sdlc-platforms/evaluation-template.json) [Read the perspective: A coding agent is only one part of an enterprise delivery system](https://aisdlc.ai/insights/enterprise-ai-sdlc-platforms-governance-benchmark) — Sam M. Sweilem