Skip to main content
View Markdown ↗

Copy this page

Select and copy the Markdown below, then paste it into your LLM.

On this page

Architecture and trust boundaries

A Badger deployment runs entirely inside the customer's network. The agent runs on a developer workstation or in a hosted worker; everything it can reach is decided by an administrator, and the developer cannot widen it.

Badger architecture Badger: hardened OpenCode for the enclave Everything runs inside the customer enclave. Administrators decide what the agent can reach; developers cannot widen it. Available today In development CUSTOMER ENCLAVE ADMINISTRATOR Management portal one service, runs offline in the enclave • Profiles: author, approve, sign • Connectors and their markings • Model gateway and its accreditation • Devices (hardware-bound keys) • Audit log of every admin action open API specification Enclave identity and PKI administrators sign in to the portal with the enclave's own certificates Evidence store signed record of model calls, connector calls and data-flow decisions DEVELOPER DEVELOPER WORKSTATION Admission the gateway and session broker act only on a signed profile for this deployment; refuses an expired, misassigned or below-minimum profile Badger OpenCode agent and terminal UI, one executable • Approved configuration compiled in; no plugin or MCP installs • Tool commands isolated by the deployment's VM or container • Credentials redacted from tool output (best effort) • One model route: the approved gateway Classification check: nothing read flows to a lower-accredited destination Connectors built by TestifySec, to be turned on per profile by the administrator Jira Confluence GitLab every result carries its classification banner, e.g. SECRET//REL TO USA, FVEY reads by default; writes only where the profile allows Model gateway holds the model credential; the workstation holds none Approved LLM accredited to a stated classification Enclave services Jira Confluence GitLab each connector reaches only its one service, as the signed-in developer Pushgate → repository tests and leak checks must pass under a signed policy before code lands signed profile sign in evidence model requests API calls code changes TestifySec · dashed items are in development and not released

Components

ComponentRoleSourceStatus
Managed Badger buildOpenCode's agent and terminal UI built with --managed. The server runs in the same process with no listening port, no background service and no updater.packages/cli/src/managed.ts, packages/server/src/managed.tsAvailable
Model gatewayGo service. The agent reaches it only through a Unix socket. It holds the provider credential, writes an audit record before each provider call, and checks the signed profile on every request.testifysec/gateway/Available
Admission launcherNative verifier for a signed profile: signature, schema, deployment assignment, validity window, minimum sequence. The gateway and the session broker call it.testifysec/managed/Available (prototype trust input)
Session brokerLinux service that starts constrained worker containers through Docker Engine and identifies its caller by the socket's peer credentials.testifysec/broker/Available
Model brokerOptional OpenAI-compatible service with per-workspace and per-device tokens and monthly quotas. Its decision logic is proved in Lean.testifysec/model-broker/Available
ConnectorsOne MCP server per enclave service (Jira, Confluence, GitLab), each locked to one base URL.testifysec/connectors/Shared library available; connectors in development
Management portalOffline service where administrators manage users and sign and assign profiles, and where workstations will pull them.testifysec/portal/Available; device pull not built

What the managed build enforces

The --managed build flag defines a compile-time constant. A build without it behaves like upstream OpenCode and is the control build in every test; a build with it enforces the following, and nothing at run time can turn it off. The tests that prove a surface run the same case against both builds.

  • Commands. Only about, run, mini, models, stats and session are kept. The --auto, --yolo, --server and --standalone options, and the option that skips permission prompts, are refused. Session import from a URL is refused.
  • Permissions. Everything is denied, then read, edit and shell are allowed. The agent's own file tools are refused outside the project. This is a permission check on Badger's tools, not a file-system boundary: a shell command can reach whatever its account can (see boundaries the deployment supplies).
  • Removed features. Built-in providers, the models.dev catalog, web search and fetch, MCP configuration, plugin discovery and install, sharing, the updater, LSP servers, formatters, terminals and the browser are off. The HTTP routes for credentials, MCP, shells, terminals, worktrees and git init return 404 and spawn nothing.
  • Model route. The only model is managed/approved. Every HTTP request the process makes goes to the gateway over its Unix socket, /run/hardened-gateway/gateway.sock, or is refused. Redirects are refused, and telemetry export ignores OTEL_* variables. If the socket is unreachable the build stops at once.
  • Credentials. The process holds no provider credential, and the auth commands are gone.

The full list, surface by surface, is in HARDENING.md.

Trust boundaries

Untrusted inputs. Repository content, tool output, model responses, MCP servers and plugins are treated as hostile. Prompt approval is a usability feature, not isolation.

The gateway socket is a capability. Whoever can open it can send model requests on the session's behalf. There is one socket per session, and the gateway writes a metadata audit record (no prompts, no response bodies) to a local spool before it calls the provider, then delivers the spool to an OTLP log collector.

The gateway holds the credentials. The provider token is read from a file, or from an inherited pipe that never touches disk, the command line or the environment. The provider's certificate can be pinned by SPKI hash. The worker never receives a provider credential, a collector credential, the Docker socket or general network access.

Workers. The session broker starts each worker as user 65534 with a read-only root, no network, dropped capabilities, seccomp, no-new-privileges, bounded resources and no logging driver. The broker re-verifies the signed profile on every request. It trusts the Docker daemon and the kernel.

Boundaries the deployment supplies

A process cannot police its own children. These are the deployment's responsibility, and Badger does not claim them:

  • Egress from tool commands. The managed build controls the HTTP requests it makes itself. A shell command the agent runs is a separate process; its network access must be denied by the operating system, a VM or the container boundary. No operating-system egress-deny acceptance run has been recorded yet.
  • Process isolation on a workstation. The workstation preview runs tools as the developer's own account. Processes running as that account are out of scope. The macOS virtual machine path in testifysec/vm/ is a development fixture, and production execution there is refused.
  • Host administrators. Application policy cannot contain a compromised host administrator.
  • Cryptographic validation. The gateway does not claim FIPS 140-3 validation. Model traffic between the agent and the gateway is plain HTTP over the Unix socket; TLS to the provider is the gateway's.

Not built yet

  • A signed binary release, SBOM and release provenance. Nothing mints a production signature today.
  • Activation records, a persisted per-device sequence floor and certificate-chain trust for profiles. See signed profiles.
  • The session flow check behind the no-write-down rule. See classification markings.
  • Device identity and enrollment through the portal. See the portal and the platform.

Reference generated from the product documentation. Match commands and support details to your installed release.