Security and workspace boundaries

Workspace isolation

Each customer workspace is provisioned on its own DigitalOcean virtual machine, with a systemd-nspawn workspace boundary inside it. Automated tests check the nspawn unit configuration, private user namespaces, virtual Ethernet networking, dropped Linux capabilities and narrow bind-mount rules that reject broad host mounts in code and test environments. This is not a claim of Firecracker or microVM isolation, a formal security certification, or protection from commands executed with authority inside your own workspace.

GitHub authorization

Farstax uses GitHub App sign-in/installations and refreshable user authorization. Access depends on the repositories available to the user's App installation and the granted permissions. Selecting a repository sets the agent's default working context, not a security boundary. The repository selected in Farstax does not limit the GitHub user token to that one repository; the agent can work with other repositories permitted by the authenticated GitHub user and the Farstax GitHub App installation. GitHub permissions and branch protection remain important.

Workspace Secrets and provider sessions

Workspace Secrets are kept as encrypted, host-owned systemd credentials outside the workspace. Automated tests check that secret values are stored with root-only permissions outside the guest filesystem and are not exposed through a generic plaintext secret-reading API. AI provider CLI sessions and managed OAuth connections have separate, provider-specific storage and authentication lifecycles. An authorized agent may read code and contact connected services.

Stopping work and safeguarding changes

Agent Bridge supports active-Run cancellation and process termination with fencing of stale replies. Stopping a Run does not reverse git pushes, commands that already completed, or unrelated services an agent started. Delivery skills guide reviews and deployments; independent repository and infrastructure permissions are the enforcement boundaries.

Usage and cost limits

Configured autonomous Episodes have bounded Cycles; other interactive or scheduled Runs have different lifecycles. No universal financial cap on third-party AI-provider usage is promised. Manage provider-side usage limits and account permissions separately.

Backups, rollback and recovery qualification

DigitalOcean daily backups are enabled for managed servers, and Farstax checks whether recent backup snapshots are listed before warning you about destructive actions. As explained in A backup list is not a restore (October 2026), provider backup visibility is not evidence of a verified live restore workflow.

Deployment and workspace upgrade checks verify disk headroom before staging a release and pair guest code upgrades with SQLite database backup, migration validation and rollback on failure. Read Rollback needs disk too (October 2026) and Upgrading the host did not upgrade the workspace (October 2026) for the incidents that shaped those safeguards. Full destructive restore qualification against live provider backups remains open.

What has been checked and what remains unverified

As of October 2026, we have automated tests for workspace isolation configuration, secret ownership, GitHub authorization and recovery safeguards. They check specific behaviours in code and test environments. They are not a penetration test of every live customer workspace, and a listed infrastructure backup is not evidence of a successful restore.

We do not currently publish an independent penetration-test report, SOC 2 attestation, ISO 27001 certification, completed live provider-backup restore qualification or contractual uptime SLA for the managed beta. Consequential repository merges, production deployments, credential changes and destructive recovery actions still require human approval and your own repository or provider controls. Do not infer third-party certification from the tests or the engineering notes.

Managed Farstax or self-hosted Agent Bridge

With managed Farstax, we operate the customer virtual machine, workspace setup and managed infrastructure. You still choose which repositories and services the agents can access, and which changes to approve. With self-hosted Agent Bridge, you control the host and are responsible for updates, host security, monitoring and recovery, including backups.

Neither approach removes the authority you grant a coding agent, the risks of a compromised machine or the data handling of the AI providers you connect. Self-hosting changes who operates the infrastructure; it does not make agent access risk-free.

Evaluating the beta

Start with a repository and data appropriate to your risk tolerance. Review the Farstax GitHub App installation's permitted repositories and permissions; the repository selected in Farstax does not limit the GitHub user token to that one repository. Use staging credentials rather than live production secrets while evaluating, configure provider-side usage controls where available, and keep human review and branch protection for production changes.

Reporting a vulnerability

Report Agent Bridge OSS vulnerabilities privately through the Agent Bridge security and private disclosure policy on GitHub. Existing Farstax beta users should use their established private support contact for account or workspace security concerns. Do not post credentials, private workspace identifiers or exploit details in public issues.