Agent Swarm security and trust

Agent Swarm is open source and self-hostable. In a self-hosted deployment, your own infrastructure holds the context, memory, logs, files, secrets, and model-provider keys that the system uses. This page separates the controls documented in the Agent Swarm repository from the configuration that remains the operator's responsibility, so that you can evaluate each claim against the source it comes from.

Deployment and data control

The recommended self-hosted deployment runs on Docker Compose, with a Kubernetes and Helm path documented separately. In this mode, the SQLite database that holds tasks, agent memory, and configuration lives on a volume you own, inside your environment. The same is true for logs and files produced by your agents.

Model traffic follows the same boundary. Workers connect directly to the model provider you configure, using your provider keys. Agent Swarm does not impose a model vendor: you choose the provider, the model, and the account under which requests are billed and logged.

Agent Swarm Cloud (cloud.agent-swarm.dev) is the hosted option for teams that do not want to operate the stack themselves. This page does not specify Cloud data locations or retention periods; if those details matter to your evaluation, ask us directly at the contact address below before drawing conclusions from this page.

For setup detail, see the deployment guide and the Kubernetes guide.

Runtime isolation

Each worker runs in its own container with its own workspace. One agent's filesystem and running processes are not shared with another agent's.

What happens outside those containers belongs to you. Network exposure, HTTPS termination, and firewalling are operator-owned decisions. Whether you terminate TLS with a reverse proxy you already run, and which ports reach the public internet, are your choices to make and to audit.

Version pinning is also your decision, and the default deserves attention. Leaving AGENT_SWARM_VERSION blank tracks the :latest image tag, which is rebuilt and moved on every commit to main — it is not a release. Pin a specific release version in anything you depend on.

Upgrades deserve the same care. Database migrations are forward-only: re-pinning to an older tag does not roll back a schema change, but a database backup taken before the upgrade does. Back up first, upgrade, then verify with the /health endpoint and one completed task rather than /health alone.

Secrets and access

Secrets stored in the Agent Swarm config store — API tokens, OAuth credentials, credential pools, and anything else marked secret — are encrypted at rest with AES-256-GCM. The encryption key is resolved in a documented order: the SECRETS_ENCRYPTION_KEY environment variable, then SECRETS_ENCRYPTION_KEY_FILE pointing to a key file, then an .encryption-key file on the data volume, which the system generates on first boot if neither variable is set.

That design puts one obligation squarely on the operator: back up the key material alongside the database. A lost key means the encrypted secrets are unrecoverable — there is no recovery path, and key rotation is not yet supported. Two values are never accepted into the config store at all: API_KEY and SECRETS_ENCRYPTION_KEY are rejected from the store, so the master credentials cannot be written into the store they protect. The secrets encryption guide documents what key material to back up and which keys are reserved.

Access to the API itself uses one shared operator API_KEY across all services. Every service that can reach the API with that key has operator-level access; treat the key accordingly.

Single sign-on is handled outside the application, by oauth2-proxy in front of the dashboard. Mode 1 is a gate only: users authenticate with your identity provider, and the swarm still sees the one shared API_KEY, with no per-user attribution at the API layer. Mode 2, trusted-header mode, additionally forwards X-Forwarded-User, X-Forwarded-Email, and X-Forwarded-Groups headers to the API, establishing the identity pipeline for per-user attribution as the application layer evolves. In both modes the security property is the same: only the proxy may set those headers, so the API must never be reachable except through the proxy. The SSO guide walks through both configurations.

Role-based access control is on by default: RBAC_ENABLED defaults to true. RBAC gates REST requests authenticated with aswt_ user tokens. Requests authenticated with the operator API key, and calls made by agents themselves, are not gated by it. There are two built-in roles, admin and requester, and every user currently receives admin by default — there is no API or UI to assign roles yet. If role assignment matters to your deployment, track and upvote it on the public feedback board. The full flag list lives in the environment variables reference.

Operational evidence

Agent Swarm can emit OpenTelemetry traces and OTLP metrics from the API server and the worker runners. Telemetry is disabled by default and turns on when OTEL_EXPORTER_OTLP_ENDPOINT is set; the data goes to the OTLP-compatible backend you choose, under your account and your retention policy. The observability guide describes the spans and metrics emitted.

The table below restates the boundary this whole page is about.

Documented control	Customer-owned configuration
Config-store secrets encrypted at rest with AES-256-GCM	Choosing the key source, backing up the key with the database
Workers isolated in separate containers with separate workspaces	Host hardening, HTTPS termination, network exposure, firewall rules
SSO via oauth2-proxy in gate-only or trusted-header mode	Running the proxy; keeping the API reachable only through it
AGENT_SWARM_VERSION pinning support and published release tags	Pinning a release in production, backups before upgrades
RBAC on by default for aswt_ user tokens	Who receives user tokens, and which roles they hold
OpenTelemetry export from API and workers	The telemetry backend, its access controls, and retention

A control appearing in the left column means it is implemented and documented in the repository. It does not mean the corresponding operational duty on the right is done for you.

Limits and contact

This page claims no certifications — not SOC 2, not ISO 27001, not any other. It claims no regulatory compliance, including GDPR and HIPAA, and no specific data-retention periods, and it does not describe a penetration test. Where a compliance question depends on how you configure your own deployment, the sections above describe which parts of that configuration are yours.

Before you rely on a self-hosted deployment, validate it against this checklist:

• A specific release is pinned in AGENT_SWARM_VERSION, not blank.
• The encryption key is set explicitly through SECRETS_ENCRYPTION_KEY or SECRETS_ENCRYPTION_KEY_FILE, and the key material is backed up with the database.
• The API is reachable only over HTTPS, through your proxy.
• SSO via oauth2-proxy sits in front of the dashboard, and the API is not reachable except through the proxy.
• /health returns successfully and at least one task has completed end to end.

Security questions go to contact@desplega.sh, the only public address for them — including questions about Agent Swarm Cloud data handling, which this page deliberately does not specify. You can also reach the team through the contact page.

Agent Swarm is developed in the open at github.com/desplega-ai/agent-swarm, where the code behind every control named here can be read and audited. For background on the team, see about; for how this website itself handles data, see the privacy policy. For a longer treatment of the self-hosted security model, in Spanish, read Seguridad en IA autohospedada.