Loopback-first services
Normal daemon API and Desktop listeners bind to the local machine. Unsupported non-loopback startup fails closed rather than silently exposing the runtime to a network.
Security & privacy
Swarm Security
Privacy and security are primary design goals for Swarm. The local runtime keeps you close to your data and tools, while explicit boundaries clarify what stays on your machine, what can be sent to a provider, and what Swarm's hosted web services process. These controls reduce risk, but no software or process can guarantee complete security.
Security at a glance
Concrete controls, with explicit limits.
Swarm narrows routine access through local defaults, authenticated transport, encrypted credential storage, permission policy, workspace-aware file tools, and isolated delegation. Each control addresses a specific risk; none turns a host-running AI into a sandboxed process.
Authenticated daemon access
Non-health requests require local identity or attach credentials, so reaching a listener is not enough to operate the daemon.
Encrypted provider credentials
Saved provider credentials are sealed with authenticated encryption, and the local root key uses owner-only file controls. This protects stored records, not a compromised user or host.
Tool policy and approvals
Runtime contracts evaluate tool calls as allowed, approval-gated, or denied. Consequential operations can stop for review, while enforced denials remain unavailable to the agent.
Workspace-aware file access
File tools resolve paths within the workspace roots granted to a run, and linked directories must be added deliberately. This narrows normal file operations but does not confine a permitted shell process.
Durable, isolated delegation
Delegated work is recorded in durable child sessions, and implementation agents use separate Git worktrees from a committed base. This reduces accidental code collisions; it is not host isolation.
Controls reduce risk. They do not guarantee safety.
Your host, approvals, provider choices, dependencies, and configuration remain part of the security model.
Privacy and data flow
Local-first does not mean nothing leaves your machine.
Swarm keeps its durable runtime state and tool execution local by default. Data crosses that boundary when a feature you use requires an external service. Review the context available to a session before sending a request, especially when a workspace contains private source, customer data, credentials, or regulated information.
stays localSession durability, local configuration, tool execution, workspace state, and saved provider credentials remain with the runtime you operate unless you deliberately export or transmit them.provider requestsPrompts and attached context are sent to the AI, search, or other provider selected for the request. Consult that provider's privacy, retention, and training policies before use.web servicesWebsite analytics, waitlist submissions, and available account services have a separate hosted data boundary described in the Privacy Policy.Local runtime and transport
The daemon is local infrastructure you control.
local controllersThe launcher, terminal UI, and Desktop connect to the same local daemon rather than creating separate session authorities.loopback firstNormal API and Desktop listeners default to the local machine. Unsupported non-loopback startup fails closed instead of silently exposing the daemon to a network.authenticated accessNon-health daemon access requires local identity or attach credentials. If you deliberately add remote access, secure the tunnel, host, and credentials as part of your own operating boundary.Local operation limits routine exposure; it is not a defense against a compromised machine, service account, or operating-system user.
Credentials and local storage
Provider credentials are encrypted local runtime secrets.
connect deliberatelyUse /auth to add only the provider credentials you intend Swarm to use.encrypted at restSaved credential records are sealed with authenticated encryption before they are written to the local secret store. The local root key is protected with owner-only file controls.host boundaryAt-rest encryption helps protect stored records, but it is not a sandbox. An attacker with sufficient control of the runtime user or host may be able to access both encrypted data and the material needed to use it.Keep provider scopes and balances narrow, rotate credentials when exposure is suspected, and never place secrets in prompts or source files when a safer mechanism is available.
Permissions and system agents
Capability is constrained by runtime contracts, tool policy, and your approvals.
allow · ask · denyTool calls are evaluated against the active runtime contract and permission policy. Higher-impact operations can pause for explicit approval, while hard boundaries remain enforced.reads have riskRead, search, and list operations do not modify files, but they can still expose private source or sensitive data to a model or tool. Ignore rules and file-tool scope reduce accidental reads; they do not prevent an approved shell process from using another user-accessible path.system agentsLaunch agents are code-owned roles with defined runtime and tool contracts. Account settings can choose their models without turning those roles into unrestricted custom profiles.delegated workDelegation uses durable child sessions. Implementation workers use isolated Git worktrees from a committed base to reduce collisions, but a worktree is not an operating-system sandbox.An approval prompt is a decision point, not proof that an action is safe. Permission bypass increases trust in automation and should be used only when you understand the active workspace, tools, and host authority.
Review and change tool policy with /permissions.
Workspaces, worktrees, and hosts
Scope access narrowly, then secure the machine underneath it.
workspace rootsFile tools resolve paths within the workspace roots available to a run. Add linked directories deliberately instead of granting broad filesystem access by habit.shell authorityShell commands run with the permissions of the daemon's operating-system user. A workspace root organizes file-tool access; it does not confine every process that user can start.Git worktreesManaged worktrees isolate concurrent branch changes and make review easier. They reduce accidental overlap, not access to the host, network, or credentials.host securityYou are responsible for operating-system updates, user privileges, disk protection, network exposure, remote access, backups, and physical security on machines running Swarm.Security engineering and operations
Security is an ongoing engineering and operational practice.
Build and review
Development and release checks look for leaked secrets, unsafe paths, policy regressions, dependency vulnerabilities, formatting issues, and launch-readiness gaps. Changes still require human review and can contain defects.
Reduce exposure
Local services use loopback-first defaults. Hosted services separate public and private routes, restrict origin exposure, and keep privileged operations away from browser code.
Observe and recover
Hosted operations use bounded monitoring, alerting, runtime detection, backups, and routine review. Signals can be delayed, incomplete, or missed, so healthy checks are evidence, not a guarantee.
Keep improving
We update controls as the product, dependencies, and threat landscape change. A past check or clean scan does not prove future security or the absence of every vulnerability.
Responsible disclosure
Found a security issue? Tell us privately.
Email [email protected] with a clear description, affected version or surface, reproduction steps, and potential impact. Please do not include live credentials, private customer data, or destructive proof-of-concept activity.