Security model

The whole idea

Breakerbox is the visual agent builder that can't be hacked into — because there's nothing to hack. No server executes your flows. No keys are stored. The builder only generates code.

Three permanent constraints

• No server execution. There is no run button, no runner, no sandbox that executes your graph on our infrastructure. You run the generated Python yourself.
• No stored keys. Breakerbox never stores, receives, or transmits your provider API keys. Bring-your-own-key features (like AI code suggestions in the builder) call the provider directly from your browser; the key lives only in your browser's localStorage.
• Codegen only. Code generation is one-directional: a spec (JSON) becomes a Python string you download or copy. No endpoint evaluates, imports, or templates your code.

Why this matters

Server-side flow builders that execute flows and store credentials have a long history of remote code execution vulnerabilities — several have landed on CISA's Known Exploited Vulnerabilities list. Breakerbox removes that entire attack surface by design: the dangerous capabilities simply don't exist in the product.

Ingest keys

The optional cloud dashboard uses a Breakerbox ingest key (not a provider key) to associate runs with your account. It is stored only as a hash; the plaintext is shown once when you create it. A provider (LLM) key is never involved.

Security scanning (0.11.0)

Beyond protecting your own budget, Breakerbox ships four scanners that treat an agent — its flow, its config, its cost — as something to audit. All are static and offline (no run, no network, no payload generation) and emit the same JSON finding shape, so they compose into a CI gate.

breakerbox dow — denial-of-wallet

Reframes the provable cost ceiling as a security finding: an input pattern that can burn spend without limit. A reachable loop with no max_hops is critical (no cap at all) or high (only the budget caps the per-invocation loss); it names the uncapped loop as the attack surface.

breakerbox dow pipeline.spec.json --strict   # exit 1 if a denial-of-wallet finding exists

breakerbox flow — flow scanning

Scans an exported Langflow flow as code and reports embedded credentials (a secret hardcoded in a node instead of a stored variable) and unguarded actions (a side-effecting node reachable from untrusted input — web / search / retrieval — with no approval step in between).

breakerbox flow exported-flow.json --json

breakerbox mcp — MCP server posture

Audits an agent's MCP configuration (mcpServers): secrets hardcoded in env/args, an unpinned supply chain (npx/uvx at @latest), non-TLS remotes, and static bearer tokens in headers. ${VAR} references and pinned packages are correctly treated as safe.

breakerbox mcp .mcp.json --strict

breakerbox baseline — regression gate

Turns any of the above into a recurring CI gate: record an accepted set of findings, then fail the build only when a new one appears (a scan that was clean stays clean).

breakerbox flow app.json --json  > findings.jsonl
breakerbox mcp  .mcp.json --json >> findings.jsonl
breakerbox baseline findings.jsonl --update   # accept the current set once
breakerbox baseline findings.jsonl            # in CI: exit 1 on anything new

The baseline (.breakerbox/findings-baseline.json) fingerprints each finding by source file, rule, and location — so a re-graded or re-worded finding keeps its identity and doesn't churn.

Runtime capability lock

At run time, guard(capability_lock=True) enforces the same principle the flow scanner checks statically: once an agent consumes untrusted content, its capabilities downgrade to read-only. Tag an untrusted source with mark_untrusted(); if a side-effecting tool then fires, the run trips (TripReason.CAPABILITY) before the tool executes — so the write/send/spend never happens. See the reference for the guard() parameters.