Security built into every layer
Autonomous development is only useful if it’s safe. CrewWork is designed with security as a core principle, and every feature includes safeguards to keep you in control.
gates in order, before your default branch
- Plan approval a person approves before execution
- Isolated execution untrusted paths run in gVisor
- Validation before publication the quality gate posts its own status
- Human review a person reviews every change
Four gates stand between AI and your code
A change passes these in order before it can reach your default branch.
- Plan approval User-started planned outcomes pause after planning until a person approves the plan. Execution does not begin before that decision.
- Isolated execution Every untrusted execution path, including platform self-repair candidates, runs inside gVisor (runsc) kernel-isolated containers with hard resource ceilings, and a failed candidate is discarded with its sandbox. See Runtime Isolation.
- Validation before publication A five-part quality gate (tests, coverage, security, code health, and live preview quality) posts as its own GitHub commit status, and self-repair candidates are additionally scored against their exact trusted parent. Thresholds and scoring are on Testing & Quality Gates; the self-repair model is on Platform Self-Repair.
- Human review A person reviews every change. Project fixes land on isolated local delivery branches with push disabled by default, so nothing leaves your environment until you opt in; platform self-repair arrives as a draft pull request; and every merge is bound to an identifiable GitHub account.
Every feature includes its own safeguards
- Repair automation is opt-in and tightly bounded Automated fixes require explicit per-integration opt-in (auto-trigger defaults off), dedupe against in-flight runs, and are bounded by daily budgets, cooldowns, and a webhook circuit breaker.
- Writes stay inside declared paths Every change must fall inside the planner-declared allowed paths, and out-of-scope writes are refused before they apply. Platform authority files are protected, and high-risk paths escalate to the strictest validation tier.
- AI sees only what it needs to AI instructions are kept focused and bounded, and sensitive data is redacted from what the model sees.
- Every action is traceable Audit events record key actions such as project/task changes and file modifications for traceability.
- Concurrent automation cannot conflict Workspace locks guard concurrent write operations and expose lock metadata in the API.
- Low-quality recommendations never reach you Suggestion and recommendation candidates are quality-filtered before reaching review channels, helping teams avoid noisy or duplicative changes.
- Secrets stay encrypted, with audited rotation Secrets are encrypted at rest with rotation policies and dedicated audit logs.
- Abuse and runaway requests are blocked by default Layered per-endpoint rate limits (Redis-backed API quotas, per-IP ingress limits) and authenticated, rate-limited WebSockets protect critical automation endpoints.
- Untrusted input is fenced away from AI instructions A trust-tiered prompt compiler assembles every prompt from role-tagged blocks (system, developer, trusted context, untrusted user and context) fenced by reserved delimiters, with delimiter escaping, injection-pattern neutralization in untrusted blocks, a per-block source map, and an immutable guardrail epilogue appended to every compiled prompt.
More protections sit behind the approval gates
CrewWork runs 18 scanner profiles against your repository as per-project-selectable, resource-bounded jobs: static analysis, dependency and secret scanning, plus three opt-in dynamic scan modes.
| Family | Coverage | Tools |
|---|---|---|
| Static analysis | Python, JavaScript/TypeScript, Go, Ruby, C/C++, Java | Bandit, Semgrep, njsscan, Gosec, Brakeman, Cppcheck, SpotBugs |
| Dependencies and SCA | npm and Python packages, with license policy enforcement | npm audit, npm lifecycle-script check, npm outdated, PyPI outdated, pip-audit, OSV |
| Secrets | The repository | Gitleaks |
| Infrastructure as code | IaC files | Trivy |
| Mode | Target | Authorization |
|---|---|---|
| Passive baseline (ZAP) | The exact running preview build | None needed |
| Active web | Bounded and rate-limited, on an ephemeral scanner-only network torn down after the scan | Explicit, per project |
| Active API | Bounded and rate-limited, on an ephemeral scanner-only network torn down after the scan | Explicit, per project |
Findings land in a filterable triage queue, faceted by severity and family, where each one is marked action needed, reviewed, or scanner diagnostics. A single finding inspector shows each finding’s fix eligibility, its active remediation attempt, and evidence inline.
- push gate
- CrewWork blocks secrets before they ever reach a remote, rather than flagging them after the fact. Every push path is gated by a fail-closed Gitleaks scan of the exact revision range: your initial repository push, ordinary delivery-branch pushes, and platform self-repair promotion. A detected secret blocks the push outright.
- access
- Every project is owned by an organization and a team under layered role-based access control. Membership changes revoke active sessions in real time. Any project member with read access can pull a non-certifying compliance evidence report spanning scans, SBOM/VEX records, quality-gate results, release provenance, and the audit trail. See Organizations & Teams for the full model.
Isolation runs at the network layer too
CrewWork’s single-host deployment is locked down by default, at the network layer as well as the application layer.
- Single Public Entry Point Only the reverse proxy is exposed to the network. Every internal service binds to localhost by default.
- Isolated Container Control Plane The container orchestrator is the only service with Docker socket access, authenticated by its own dedicated token.
- Credential-Free Validation Containers Validation containers that run repository code never receive internal platform credentials.
- Fail-Closed Session Security Token revocation fails closed in production, and CSRF double-submit protection guards every state-changing request.
- Monitoring Behind the Same Ingress The built-in Grafana, Prometheus, and Alertmanager dashboards are reached through the same authenticated reverse proxy as the rest of the platform. Their direct ports stay loopback-only by default, and browser credentials are never forwarded to the monitoring containers.
- Locked-Down Direct API Responses Any HTML the API service serves directly fails closed to a default-src none content security policy. The one narrow exception is the interactive API reference, scoped to exact, hash-pinned assets with no unsafe-inline or unsafe-eval.
Your Code, Your Control
- repository
- When you connect a repository, CrewWork clones it to work with. Nothing goes straight to your default branch.
- artifacts
- Large logs, diffs, and tool outputs are stored outside your repo with redaction and size limits, so context stays tight without bloating your codebase.
- model traffic
- Local-only by default: CrewWork refuses to send model traffic to any endpoint not on localhost or your private network unless you explicitly opt out, and per-lane endpoint allowlists reject unapproved model hosts.
Signing in and connecting a repository stay separate
- credentials
- OAuth tokens are stored encrypted, and branch protection rules and required reviews remain in effect for every change that reaches your default branch.
- webhooks
- Signatures are verified, and runtime repair validates repository permissions before any push.
- monitoring health
- Never hidden: degraded or unverified error-monitoring integrations are flagged in the repair outcome with explicit reasons and verification timestamps.
See whether CrewWork fits your work.
CrewWork is built and running, and not yet generally available.
- worth discussing
- The errors and backlog you would hand off
- Where your source has to stay
- The evidence you would need to trust a change