Security
Tack's security model, audit results, and trust properties.
Tack runs LLM-directed commands inside your repositories. Security matters here because the product is intentionally close to your code, your git state, and your local credentials.
Audit
Latest audit pass: 2026-04-15.
Recent fixed issues:
- Shell-injection hardening for branch names, merge refs, model names, and PR base/head values that flowed into
sh -c - Local ignored-file bootstrap now skips ignored symlinks whose resolved targets escape the repo root
- This page now reflects the real local-sandbox trust boundary instead of overstating isolation
Audit reports:
Security Model
Network
- Daemon binds to
127.0.0.1:9800by default (loopback only) - All daemon routes require bearer token authentication
- Agent callbacks are authenticated
- No remote access unless you explicitly configure it
Sandbox Isolation
- Each agent works in its own git worktree (local) or VM (Daytona)
- Worktree path traversal via Tack-controlled file operations is blocked
- Ignored symlinks that resolve outside the repo are not copied into fresh local worktrees
- Worktrees are automatically cleaned up when objectives complete
Important:
- Local worktrees are not containers or VMs
- Local agents run as your user
- File scope is an orchestration and tool-policy boundary, not a kernel-enforced security boundary
Credentials
- Git credentials are never persisted in remote URLs
- API keys are stored in
~/.config/tack/credentials.yaml(user-local, not in the repo) - The
tack initwizard validates credential/provider combinations before you start - Daytona sandboxes receive credentials per-invocation, not permanently
Observability
- Activity logs use
0600file permissions - Live projected events do not include raw agent content
- Escalation milestones do not leak mail bodies or payloads
- Canonical on-disk logs retain content for local debugging only
- Mail endpoints enforce project scoping
- Cross-project spoofing is blocked
- All mail routes require daemon auth
What Tack Can Access
When you run Tack with local sandboxes:
| Resource | Access |
|---|---|
| Files in assigned file scope | Intended write ownership |
| Files outside file scope | Not a hard OS boundary |
| Files outside the worktree | Not sandboxed by the OS |
| Environment variables | Only what Tack injects |
| Network | Not restricted by Tack |
Agents run as your user. Local mode is best understood as an orchestrated worktree plus prompt/tool constraints, not as host isolation. For stronger isolation, use Daytona sandboxes.
Trusted Inputs
Treat these as trusted code-execution surfaces:
.tack/config.yaml- project
quality_gates - project setup commands
- custom blueprints and rules
If you would not run a repo's scripts locally, do not point Tack at that repo in local-sandbox mode.
See Also
- Isolation & Sandboxes — how agents are isolated from each other
- Credentials & Auth — credential management and injection
- Observability — what gets logged and projected
Reporting
Security issues can be reported by opening an issue on the GitHub repository.