Skip to main content
View Markdown ↗

Copy this page

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

On this page

Badger

Badger is TestifySec's coding agent for networks that keep their code, tickets and models inside the boundary: classified enclaves, air-gapped labs, and regulated programs. It is a maintained fork of OpenCode (MIT) with a small patch series under testifysec/.

A managed Badger build differs from upstream in three ways:

  • One compiled policy. The managed build compiles its configuration in. No environment variable, flag, user setting or repository file can turn the policy off or widen it.
  • One model route. Every model request leaves through a model gateway that the administrator runs. The gateway holds the provider credential; the workstation holds none.
  • Signed configuration. What a workstation may run is described by a profile that an administrator signs. The gateway and the session broker refuse a profile that is unsigned, expired, assigned to another deployment, or below the minimum sequence the build trusts.

Badger also labels what it reads. Each connector has one classification, set by the administrator, and every result it returns carries that marking. The session will refuse to send data to a destination accredited below what it has read. The first half is on main; the second is specified and not built. The classification page says exactly which part is which.

Badger is a development preview. There is no published binary release and no signed release artifact yet. Several features described here are in open pull requests; each page marks them as In development and names the pull request. Publishing the source does not establish runtime isolation, a compliance qualification or an authorization.

What do you need to do?

Run Badger as a developer

Start a session against your administrator's gateway and work in a repository.

  1. Build the managed binary and start a session
  2. Understand what the managed build allows

Administer Badger

Decide what every workstation may run, with what model, against which services.

  1. Configure the model gateway
  2. Install the management portal offline
  3. Author, approve and publish a profile
  4. Enroll a device

Connect Jira, Confluence or GitLab

Let the agent read your enclave's services as the signed-in developer, with a marking on every result.

  1. Understand connectors
  2. Understand classification markings
  3. Configure a connector with a marking

Assess the security architecture

Read the trust boundaries, what is enforced today, and what is still open.

  1. Read the architecture and trust boundaries
  2. Read the no-write-down guarantee and its status
  3. Run the conformance suites yourself
  4. Check the NIST SP 800-53 control alignment
  5. See who is responsible for what, and what IL6 means here

How the pieces fit

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
PieceWhat it doesStatus
Managed Badger buildThe OpenCode agent and terminal UI with the policy compiled inAvailable on main
Model gatewayHolds the provider credential, checks the signed profile and writes an audit record before every model requestAvailable on main
Signed profile admissionVerifies a profile's signature, assignment, validity window and sequenceAvailable on main (prototype trust input)
ConnectorsJira, Confluence and GitLab tools, each locked to one serviceAvailable on main; not yet loadable by a managed session
Classification markingsOne administrator-set marking per connector, on every resultAvailable on main
Management portalOffline service where administrators manage users and sign and assign profilesAvailable on main (devices, activations and two-person signing not built)

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