Decide who talks to what

The principle of ordered ACLs

A VIGIL ACL is an ordered list of rules. Each rule expresses a simple intent: such source is allowed (or not) to reach such destination, possibly restricted to certain services. For a given flow, the controller walks the list in order and applies the first rule that matches. Order therefore carries meaning: a rule placed higher wins over a rule further down.

Sources and destinations are not designated by fragile IP addresses but by identity: a machine, a group, a role, a tag assigned at enrollment. A rule written for a group remains true when a machine joins or leaves that group, without rewriting. This is what lets the policy survive time and fleet changes.

1. 1
   A flow presents itselfA source tries to reach a destination on a given service, inside a network.
2. 2
   The rules are evaluated in orderThe controller walks the ACL top to bottom and retains the first rule whose source, destination and service match the flow.
3. 3
   The decision applies — deny by defaultIf no rule allows the flow, it is denied. Only the explicit is allowed: what is not permitted is forbidden.

Signed generations, verifiable offline

The policy is not a mutable state modified in place. Every change — adding a rule, modifying a group, publishing a service — produces a new, complete generation of the policy. This generation is signed by the controller, then distributed to the members of the network. Generations succeed one another, numbered, giving a clear history of the policy over time.

The decisive point is verification on the client side. A node only applies a generation after verifying its signature against the controller's public key, which it already knows. This verification is cryptographic and local: it depends on no live connection to the controller at the time of application. A client can therefore validate the authenticity and integrity of the policy it receives even offline.

This signature is part of the overall trust model — the controller's public keys, machine identities, end-to-end encryption. The complete articulation is described in the security model.

Example rules

The table below illustrates the logic of an ordered ACL. Each line is a rule; they are read top to bottom, and the first that matches a flow decides. The last line recalls the default behavior, which denies whatever no rule has allowed.

Several traits of the model can be read in this example: entities are designated by group or by tag, never by IP; some rules restrict the allowed service (RTSP, database port); order matters, since an explicit deny rule can precede a broader one; and absent an allowance, the flow falls onto the default deny.

Zero Trust: access follows identity

The model trusts neither the physical network, nor the location, nor the mere fact of having joined the mesh. Access flows from the machine's verified identity and from the rules that concern it. Being a member of a network grants no right in itself: without a rule that allows it, a flow is denied. This is the Zero Trust principle applied to the mesh.

• No implicit trust: position on the network confers no right, only the policy does.
• Access by identity: sources and destinations are machines, groups and tags, not addresses.
• Least privilege: only the explicit and the necessary is allowed; the rest falls onto the default deny.
• Verifiable policy: each generation is signed and checked by the client against the controller's public key.

This model is precisely what makes it possible to replace a star-shaped enterprise VPN with a mesh segmented by policy. That scenario — access by identity, ordered ACLs, audit — is developed in Replacing an enterprise VPN with a Zero Trust mesh.