Fabro is currently a research preview. It has not yet been subject to third-party penetration testing. There may be vulnerabilities. We strongly recommend only deploying Fabro on private, self-hosted resources within a controlled networking environment.
Security controls not in Fabro
Fabro is single-tenant software designed for small, trusted teams. The following controls are not implemented — plan your deployment accordingly.
| Control | Status |
|---|
| Multi-tenancy | Not supported. Fabro is single-tenant only — there is no organization or tenant isolation. |
| Roles or ACLs | Not supported. All authenticated users have identical, full access to every run, workflow, and API endpoint. |
| Rate limiting | Not implemented. The API server does not throttle requests. |
| Security headers | Not configured. The API does not set Strict-Transport-Security, Content-Security-Policy, X-Frame-Options, or similar headers. |
Security recommendations
Network
- Deploy the web app on a private network. Use a Tailscale tailnet, VPN, or internal network to keep the web UI off the public internet.
- Deploy the API on a private network. Only allow access from expected hosts (the web app, CI runners, developer machines). The API binds to
127.0.0.1 by default — do not expose it with --host 0.0.0.0 unless it is behind a firewall or private network.
- Use Daytona sandboxes with network controls. When running untrusted or generated code, use the Daytona sandbox provider with
network = "block" or a CIDR-based allow list to restrict agent egress.
Authentication
- Enable authentication. Fabro supports
dev-token and GitHub OAuth. Do not disable auth outside of local development or controlled demos.
- Configure a username allowlist for GitHub OAuth.
[server.auth.github].allowed_usernames should contain the exact GitHub users allowed to log in. An empty list rejects everyone.
- Configure the session secret used by the web flow.
SESSION_SECRET should be provisioned with a strong value on long-lived deployments.
- Terminate HTTPS or mTLS upstream when needed. Fabro’s listener is plain HTTP/Unix only. If CI, scripts, or a browser must connect over HTTPS, terminate TLS at a reverse proxy or load balancer and keep the Fabro listener on a private network.
Secrets
- Keep API keys out of sandboxes. The local sandbox strips environment variables ending in
_API_KEY, _SECRET, _TOKEN, _PASSWORD, or _CREDENTIAL, but Docker and Daytona sandboxes provide stronger isolation — only explicitly configured variables are passed through.
- Use server-owned secrets or process env vars for credentials. For server-backed workflows, persist credentials with
fabro provider login / fabro secret set, which stores them under the server data directory. Do not commit secrets to version control.
- Rotate the session secret. The
SESSION_SECRET environment variable encrypts web app sessions. Rotate it periodically and use a strong random value.
Execution
- Use Docker or Daytona for untrusted workflows. The
local sandbox offers no filesystem or network isolation — agents have the same access as the host. Use docker or daytona when running code you haven’t reviewed.
- Restrict agent permissions. Use
--permissions read-only or --permissions read-write to limit which tools agents can invoke without approval. In non-interactive mode (--auto-approve), tools outside the permission level are denied outright.
Security reporting
If you discover a security vulnerability in Fabro, please report it responsibly:
- Email security@fabro.dev with a description of the vulnerability, steps to reproduce, and any relevant details.
- Do not disclose the vulnerability publicly until we have had a chance to investigate and release a fix.
- We will acknowledge receipt within 48 hours and aim to provide an initial assessment within 5 business days.
- We will work with you to understand the issue and coordinate disclosure timing.
We appreciate the security research community’s efforts in helping keep Fabro and its users safe.
