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), 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.
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 Infinite Coder programs 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.
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
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
When you connect a repository, CrewWork clones it to work with. 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.
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.