01{ }
Define the rules
Write YAML policy for file paths, shell commands, and MCP server or tool names. Validate changes before installing them.
Policy reference ↗Policy control for coding agents
Give agent access
an explicit boundary.
CyberBoar checks coding-agent tool calls against deterministic policies on the developer’s machine, before supported actions proceed.
Open source endpoint · YAML policies · No LLM in the decision path
POLICY EVALUATION LOCAL
Proposed tool callRead file
01apiVersion: cyberboar.dev/v1
02kind: Policy
03spec:
04files:
05deny:
06- "**/.env*"
DENYMatched files.deny[0]DECISION
ONLY
ONLY
Illustrative example
A policy layer at the tool boundary
Know what the agent
is asking to do.
Agent permissions can be broad, fragmented, and hard to review in the moment. CyberBoar gives teams a readable policy for supported tool calls, with decisions made locally and without an AI model in the evaluation loop.
02⇄
Check proposed calls
An agent hook or plugin sends supported tool calls to CyberBoar. The policy engine evaluates them deterministically and returns a decision.
Security model ↗03≡
Review decisions
Optional local JSON Lines audit events record the policy decision, matching rule, and available call metadata for later review.
Operations guide ↗Policy scope
One policy.
Three control points.
Rules describe the action the agent proposes. Coverage depends on the agent adapter and the information available to its hook.
Files
Check paths exposed by native file tools and supported file actions inferred from shell commands.
Shell commands
Analyze supported Bash syntax and command patterns without executing the command during evaluation.
MCP tools
Match configured rules against the server and tool names supplied by the agent adapter.
Agent coverage
Meet teams where
they build.
Adapters are available for five coding agents. The exact checks, native platform support, and hook failure behavior vary by agent—review the matrix for your environment before rollout.
Claude CodeCodex CLIGitHub Copilot CLICursoropencode
Review the capability matrix ↗
Deployment options
Start local.
Plan for the fleet.
Try CyberBoar on one project, then decide how signed policy distribution and audit collection fit your endpoint operations.
Local evaluation
Install a hook for one project, validate a policy, and check a harmless test call in the agent session. No CyberBoar account or console is needed.
Follow the getting-started guide ↗Signed distribution
Sign policy bundles and serve them from a static HTTPS host. Endpoints verify signatures, expiry, and serial numbers before applying updates.
Read the operations guide ↗Audit collection
Keep decisions locally or collect audit records through an existing log agent. Authenticated console delivery requires a compatible service.
See deployment models ↗Security with clear boundaries
Designed to deny
when a decision fails.
Invalid input, unavailable or invalid policies, signature failures, decision timeouts, and internal evaluation errors produce denial.
THE ENFORCEMENT BOUNDARYREAD BEFORE ROLLOUT
CyberBoar evaluates tool calls delivered to its hook or plugin. It is not an operating system sandbox and does not govern every action a launched program can take.
- Launched programs can access files beyond arguments visible to the policy check.
- Network egress is not governed by CyberBoar.
- Calls outside an agent’s hook visibility receive no CyberBoar decision.
- Managed settings and OS permissions are needed to protect deployment from local users.
See the policy in action
Start with one safe test.
Use a fake secret, inspect the decision, and learn how to roll back the local hook.