Circuit Breaker Agents Incoming!

Greetings, everyone!

It has been a while since my last development update. I’m wrapping up my sophomore year and currently between jobs, which has given me more time to work on some of the features I’ve wanted to bring to Circuit Breaker for a long time.

The biggest of those is now well underway.

Introducing Circuit Breaker Integration Agents

I’m developing a lightweight remote agent called the Circuit Breaker Integration agent, or CBI agent.

Despite the name, this is not an AI integration. CBI agents are closer to the lightweight collectors used by platforms such as Netdata. Rather than installing the entire Circuit Breaker stack on every machine or network you want to observe, you’ll install a small Go service that reports securely to your primary Circuit Breaker instance.

This will extend Circuit Breaker beyond the network where its main server is running. An agent could be placed on another VLAN, at a second home, in a branch office, on a cloud network, or anywhere else that can reach your Circuit Breaker instance.

The initial agent is being designed around three capabilities:

• Host telemetry from the machine running the agent
• Monitoring checks performed from the agent’s network location
• Controlled discovery of the agent’s directly connected networks

This means Circuit Breaker will eventually be able to see and monitor systems that the main server cannot route to directly.

Simple, Centralized Deployment

The goal is to keep deployment as close to zero-configuration as possible.

From the main Circuit Breaker application, you’ll select Deploy Agent and receive an installation command. After you paste that command into the target machine’s terminal, the installer will download the correct binary, install a hardened systemd service, and connect back to Circuit Breaker.

The agent will then appear as pending in the main application. You’ll verify its fingerprint and approve it before it receives permission to do anything.

After approval, configuration will be managed centrally. You should not need to manually configure local CIDRs, monitoring schedules, credentials, scanners, certificates, or agent-side configuration files forthe standard setup.

Agents will also be designed to survive restarts, temporary connectivity loss, NAT rebinding, and IP address changes without requiring re-enrollment.

Security Is the Foundation

Most of the work completed so far has focused on building the agent’s security and lifecycle foundation before adding collectors.

The agent uses an outbound-only connection to the Circuit Breaker server. It does not open an inbound port, expose a remote shell, or create a general-purpose tunnel into the remote network. No port-forwarding or inbound NAT rule should be required.

Communication travels over a persistent secure WebSocket connection on HTTPS, with an additional end-to-end encrypted Noise protocol channel inside it. The current design uses X25519 device identities and Noise IK with ChaCha20-Poly1305 encryption, forward secrecy, strictly increasing nonces, replay protection, and periodic transport re-keying.

That extra encryption layer means a reverse proxy or TLS-terminating service can forward the connection without gaining access to the agent protocol’s plain text.

Each agent generates its own device identity locally. Its private key is stored with restrictive permissions and is never sent to the server. During approval, Circuit Breaker displays the same device-key fingerprint shown by the agent so that you can confirm you are approving the correct machine.

Enrollment codes are:

• Short-lived and single-use
• Stored as hashes rather than plaintext
• Protected by per-IP and global rate limits
• Useful only alongside an authenticated Circuit Breaker session with sufficient permissions

Anonymous enrollment and connection endpoints also have global limits and concurrent-pending-agent protections to reduce denial-of-service and resource-exhaustion risks.

Default-Deny Capabilities

CBI agents follow a per-agent, default-deny capability model.

An agent cannot begin scanning its network simply because it has connected. Circuit Breaker sends an explicit set of centrally managed grants, and the agent independently refuses work outside those grants. Capabilities can be enabled, disabled, or revoked without reinstalling or restarting the service.

The initial capability boundaries are:

• Host telemetry: Observe the machine running the agent
• Remote probe: Perform assigned health checks from that agent’s network position
• Local discovery: Inspect an explicitly bounded network scope

Approvers will be able to review these permissions before activation. Existing installations will not silently gain newly introduced permissions during an upgrade.

Revoking an agent will close its active connection immediately, stop its capabilities, and reject future connections from that identity. Historical events and attribution will remain available for auditing.

Secure Installation and Updates

The installation process is also being built around verifiable artifacts.

For publicly trusted HTTPS deployments, the installer can rely on the normal certificate trust chain. For self-signed deployments, Circuit Breaker will provide integrity information through the authenticated application, including certificate pinning and SHA-256 verification. Installation command generation is designed to fail closed if the required trust information cannot be obtained.

Agent binaries will be served by your own Circuit Breaker instance, with Linux builds planned for both AMD64 and ARM64. This avoids requiring a third-party agent service and leaves open the possibility of private or disconnected deployments where the agent can still reach the local Circuit Breaker server.

Updates will be managed centrally through the authenticated agent channel. Downloads use the configured TLS trust and pinning policy, enforce size and timeout limits, and verify the expected SHA-256 digest before installation.

The update process keeps the previous binary available until the new version reconnects successfully and receives confirmation from the server. If that does not happen, the agent can roll back rather than leaving the remote installation unusable. Update stages including queued, started, succeeded, failed, and rolled back are recorded separately for visibility and auditing.

Device-key rotation is already part of the development work, and server-key rotation is being designed with an overlap window so a fleet can migrate to a successor key without every agent losing trust at once.

Resilient Delivery

Remote networks are not always reliable, so the agent includes a bounded on-disk spool for eligible data.

If the connection is interrupted, telemetry and completed results can be queued locally and replayed after reconnection. The spool has a fixed size and evicts its oldest records when necessary, preventing an extended outage from consuming unlimited disk space.

Control messages and heartbeats are never placed in the spool. Data frames carry stable identifiers and their original observation times so the server can safely reject duplicates, stale assignments, malformed payloads, or results that are no longer authorized.

What the Agent Will Eventually Report

The next major development phase is host telemetry. The planned collectors include information such as:

• CPU utilization and load
• Memory and swap usage
• Filesystem capacity
• Network-interface counters
• Uptime and basic host identity
• Available temperature and hardware sensor data

The intention is to collect useful operational data without requiring elevated runtime privileges. Optional sensors may not exist or may not be readable on every system, so collectors will report their readiness individually instead of failing the entire agent.

Agents will be linkable to existing Circuit Breaker hardware records, while unlinked agents can remain first-class monitored entities. Samples will retain their originating agent and original timestamp, and live updates are planned for the agent detail interface.

Remote Monitoring Vantage Points

A later phase will allow an agent to run centrally assigned monitoring checks from its own network location.

Planned checks include ICMP, TCP, HTTP/HTTPS, and DNS. This will make it possible to answer questions such as:

• Can the remote office reach its gateway?
• Is a service reachable from the user’s VLAN but not from the server VLAN?
• Is an internal application healthy from another site?
• Is DNS behaving correctly inside a specific network?

These will be assigned checks—not arbitrary commands. The agent will validate each assignment against its current grants and permitted scope before executing it.

Safe Local Discovery

Local discovery is planned as another explicitly bounded capability.

By default, the agent will derive a safe scope from directly connected private IPv4 networks and IPv6 ULA networks. Public ranges, default routes, loopback, link-local, multicast, tunnel, and point-to-point interfaces are excluded automatically.

Both the server and agent will enforce the network scope independently. Exceptional routed networks will require an explicit central override.

Discovery findings will feed into Circuit Breaker’s existing review-and-import workflow rather than automatically turning every response into an inventory record. Recurring scans will update known devices and surface newly observed systems for review, with every finding retaining the identity of the agent that observed it.

Privacy and Deployment Considerations

The agent does not necessarily require access to the public internet, but it must be able to reach the configured Circuit Breaker agent URL over HTTPS/WSS. If your main instance is available only inside a private network, agents can connect through that network, a site-to-site VPN, or an overlay such as Tailscale.

If you expose Circuit Breaker through the internet, I strongly recommend placing it behind a well-maintained access layer such as Cloudflare, Tailscale, Pangolin, or another trusted VPN or reverse proxy. Keep the host patched, use HTTPS, enable strong authentication, and apply normal network segmentation practices.

The security model is intended to limit an agent to clearly defined jobs, but it cannot protect against a compromised Circuit Breaker server or root access on the agent host. Those boundaries will be documented openly rather than hidden behind claims of perfect security.

Current Development Status

The original agent foundation has progressed beyond an early prototype. Work completed in development now covers much of the enrollment, encrypted communication, fleet management, live presence, capability control, resilient delivery, key rotation, and rollback-aware update lifecycle.

The next substantial milestones are:

1. Host telemetry collection and visualization
2. Agent-based monitoring checks
3. Bounded local network discovery
4. Full cross-network and failure-recovery testing
5. Packaging, upgrade compatibility, documentation, and release hardening

The feature is still under active development, and these details may evolve before release. My priority is to make the agent genuinely useful without turning it into an unrestricted doorway into your network.

I’m excited about what this will unlock for Circuit Breaker, and I look forward to sharing more as each phase comes together.