Skip to content

Security model

FourEyes is designed to be deployed inside sensitive networks — across backbones, branch offices, and cloud regions. Its security model rests on mutual TLS identity and four non-negotiable invariants.

  • The server runs its own mTLS CA. Nodes enroll with a single-use enrollment token, exchange it for a signed client certificate, and from then on present that cert on every connection.
  • Enrollment tokens are strictly single-use (atomic consume) and expiring.
  • Node identity material and mTLS credentials are never persisted or transmitted in plaintext.

These shape every architectural decision.

The node protocol carries only the fixed, declared probe types via a typed oneof config. A bytes or generic string command field on a node-bound message is rejected in review, no exceptions. This is the single biggest blast-radius risk: a malicious or compromised server must not be able to RCE every customer’s backbone. Browser transactions are a closed step-list enum — never server-pushed JavaScript.

A node will never install or run a binary that hasn’t passed signature verification against the ed25519 trust root pinned at build time. An unverifiable artifact is dropped — fail-closed.

BGP integration observes sessions. It never originates, withdraws, or influences a route on a peered router. FourEyes is a monitor, not a routing participant.

Nodes never open an inbound listening port on the deployed network. They dial the server, so they work behind NAT and strict firewalls.

Every repository method takes an explicit Scope, and a query or action scoped to one org/team must never read or affect another tenant’s nodes, tests, or results.

Today a default-org scope is the stand-in for full multi-tenant RBAC. `/metrics` is cross-org by design and must be gated before a multi-tenant deployment. See the [Roadmap](/reference/roadmap/).