CyberBoar

Define what coding agents can do. See what they try.

CyberBoar evaluates coding-agent tool calls against a YAML policy on the developer’s machine. It checks file access, Bash commands and MCP server/tool names, then returns deny, ask or no objection through the agent’s hook interface. Optional local JSON audit logs record its decisions. No LLM participates in policy evaluation.

Adapters are available for Claude Code, Codex CLI, GitHub Copilot CLI, Cursor and opencode. Coverage and failure behavior depend on the agent; review agent setup and the capability matrix before deploying.

The official Claude Code, Codex and opencode editor extensions and the Cursor editor are supported and under active testing. Copilot editor support is experimental. See editor integrations for setup, validation status and session-specific limitations.

Start here

Quick example

With Go 1.27.2 or later, run from the repository root on macOS or Linux:

mkdir -p "$HOME/.local/bin"
go build -trimpath -o "$HOME/.local/bin/cyberboar" ./cmd/cyberboar
"$HOME/.local/bin/cyberboar" check examples/baseline.yaml
"$HOME/.local/bin/cyberboar" explain --policy examples/baseline.yaml --command 'cat .env'

The last command reports DENY under files.deny[0]. explain evaluates the proposed action without executing it or installing a hook. Follow Getting started to verify enforcement in an actual agent session, including native Windows installation.

A minimal policy blocks .env files:

apiVersion: cyberboar.dev/v1
kind: Policy
metadata:
  name: starter
spec:
  defaults:
    posture: deny-listed
  files:
    deny: ["**/.env*"]

Use baseline.yaml or enterprise-baseline.yaml as a broader starting point. Review each rule for your environment before installing it.

How enforcement works

1. An agent sends a proposed tool call to its CyberBoar hook or plugin.
2. CyberBoar translates the call into actions and evaluates the policy.
3. The adapter returns the decision in the agent’s protocol. If an audit path is configured, CyberBoar appends a redacted decision event locally.

allow means the action passed CyberBoar’s checks. The agent’s own permissions still apply. Agents that cannot safely request confirmation receive a denial for ask decisions. CyberBoar denies invalid inputs, unavailable policies and decision errors; an agent that cannot launch its hook may have different failure behavior.

What it does not do

CyberBoar is a policy hook, not an operating-system sandbox. It cannot observe every file a launched program opens, govern network egress, or enforce calls the agent does not send to a hook. Users who control their machine can disable an advisory installation. Managed settings and OS permissions can protect deployment configuration; an OS sandbox is needed for a process-level boundary.

See the security model for path, shell, secret-detection and deployment limits. On native Windows, use Claude Code with Git Bash. Other agents require WSL or a Linux dev container; PowerShell analysis is not connected to the production engine.

Fleet use

Signed policy bundles can be served from a static HTTPS host without a console. Endpoints verify signatures, expiry and serial numbers before installing an update. Audit logs can be collected with an existing log agent.

enroll and ship require a compatible service implementing the endpoint protocol. This endpoint release does not include a console service. See Policy distribution and auditing for both deployment options.

Project information

• Contributing: development workflow and contribution intake. External patches are paused while the CLA and signing process are finalized; bug reports and proposals are welcome.
• Security policy: report vulnerabilities privately to security@cyberboar.io.
• Changelog: release changes and compatibility status.
• License: AGPL-3.0-only. The protocol reference includes an additional permission for compatible implementations. The commercial console is a separate product. CyberBoar is a trademark; forks must use their own name.