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.
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), land on isolated local delivery branches with push disabled by default, dedupe against in-flight runs, and are bounded by daily budgets, cooldowns, and a webhook circuit breaker, while integration health is continuously surfaced in HotFix status.
You review every change before it ships
Project fixes land on isolated local delivery branches: push is disabled by default, so nothing leaves your environment until you opt in. Platform self-repair opens draft pull requests, and nothing merges without your review.
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. Daily modification budgets and cooldowns keep automation bounded.
AI sees only what it needs to
AI instructions are kept focused and bounded. Write access is scoped to an approved per-step path list enforced by a fail-closed workspace gate, and sensitive data is automatically redacted.
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.
Four gates stand between AI and your code
Every autonomous action passes through explicit approval gates before it can affect your code.
Draft PR Review
Project fixes wait on your branch until you push; platform self-repair opens as a draft PR. See Platform Self-Repair for the full model.
Isolated Environments
Platform self-repair, and every other untrusted code execution path, runs inside gVisor (runsc) kernel-isolated containers with hard resource ceilings, with failed candidates discarded along with their isolated sandbox. Passing candidates are additionally scored against their exact trusted parent, and every merge is bound to an identifiable GitHub account. See Platform Self-Repair and Runtime Isolation for the full model.
Fail-Closed Write Scope
Write access is fail-closed: changes must fall inside planner-declared allowed paths, platform authority files are protected, and high-risk paths (core runtime, API, database, dependency manifests) automatically escalate to the strictest validation tier. See Platform Self-Repair for the full model.
Safety Validation Pipeline
Every PR is scored against a five-part quality gate (tests, coverage, security, code-health analysis, and live preview quality) posted as its own GitHub commit status. Default thresholds require at least 80 percent line coverage, a health score of 70 or higher, and zero new critical or high-severity findings before the gate passes. Platform self-repair runs additionally select validation depth automatically, from a scoped shadow check to the full test matrix, before that gate applies. See Testing & Quality Gates for how each component is scored and Platform Self-Repair for the validation model.
More protections sit behind the approval gates
Built-In Security Scanning
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 below.
- SAST: Python (Bandit, Semgrep), JavaScript/TypeScript (njsscan, Semgrep), Go (Gosec), Ruby (Brakeman), C/C++ (Cppcheck), Java (SpotBugs)
- Dependency and SCA (npm audit, npm lifecycle-script check, npm outdated, PyPI outdated, pip-audit, OSV), with license policy enforcement
- Gitleaks for secrets
- Trivy for infrastructure-as-code
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.
Opt-In Dynamic Scanning (DAST)
Secrets Blocked Before Publication
Layered RBAC, Instant Revocation, Compliance Evidence
Platform Hygiene
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, CSRF double-submit protection guards state-changing requests, and role-based access control governs every endpoint.
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
Your code stays under your control. When you connect a repository, CrewWork clones it to work with. Project fixes land on an isolated local delivery branch and platform self-repair opens a draft pull request; nothing goes straight to your default branch.
Large logs, diffs, and tool outputs are stored as artifacts outside your repo with redaction and size limits, so context stays tight without bloating your codebase.
AI write access follows the same fail-closed scoping and audited secret handling described above.
LLM traffic is local-only by default: CrewWork refuses to send model traffic to any endpoint that is not on localhost or your private network unless you explicitly opt out, and per-lane endpoint allowlists reject unapproved model hosts. Provider and model selection stay fully under your control.
Signing in and connecting a repository stay separate
CrewWork account sign-in supports GitHub, GitLab.com, or Bitbucket Cloud OAuth, and you can link more than one provider identity to the same account from Settings. Once signed in, you separately choose which repositories to connect as CrewWork projects, and CrewWork’s access can be revoked at any time from that provider’s account settings.
OAuth tokens are stored encrypted, and branch protection rules and required reviews remain in effect for every change that reaches your default branch.
Webhook signatures are verified, and HotFix workflows validate repository permissions before any push.
Error-monitoring health is never hidden: degraded or unverified integrations are flagged in HotFix status with explicit reasons and verification timestamps, so you can see exactly why signals may be missing.
Questions about security?
Reach out about security requirements for your organization.