How enforcement works

Learn where Zero-Code makes each decision on a node, how an AI agent is held in a boundary, and how monitor mode, enforce mode and the brake fit.

Zero-Code makes its decisions on the node, in the Linux kernel, with small programs loaded by eBPF. A decision made there cannot be skipped by a workload that ignores a library or connects to an IP address directly.

The programs are loaded by the node agent, the Zero-Code component that runs on every node. This page explains what is decided, where, and what controls whether a decision is applied. To install the node agent, see Install Zero-Code on a cluster.

Where each decision is made

Zero-Code makes three kinds of decision, each at the point where it cannot be avoided.

Rules on where a workload connects

For each workload you list where it may connect: the destinations, and the ports on them. The console drafts the list from the connections it saw the workload make, under What it may reach in the workload's Protect step. Each destination is marked allowed or would be refused.

When the workload is in enforce mode, every other destination is denied. Outbound access is closed by default.

The boundary around an AI agent

A workload classified as AI agent runs as a registered AI agent, chosen in Runs as. It is held more tightly than an ordinary service. An AI agent runs code that a model wrote, so the boundary assumes the code may try anything.

The metadata address is where a cloud hands out the node's own credentials. An AI agent that reaches it has the node's access, which is why no grant opens it.

Each denial is recorded with the AI agent, what it tried and when.

Monitor mode and enforce mode

A rule is in one of two modes. In monitor mode, a rule denies nothing and records what it would have denied. In enforce mode, the rule is applied. Everything starts in monitor mode.

The mode is set at two levels.

The console shows the cluster's mode as Node mode in the cluster list. A workload whose saved rules are in monitor mode carries the badge monitor.

Turn on protection… is available once a workload has been watched for 24 hours, classified, and given its rules. Until then the console shows Watched for under 24 hours, and a saved draft records what it would deny in the meantime.

A protected workload's rules apply on the nodes running it whatever the node mode.

The brake

The cluster owner holds a switch that AuthFI cannot override. It is a field on the install's AgentRuntime resource.

spec:
  enforcementInhibit: true

With the brake on, the nodes stop denying. Everything is still monitored and recorded, so you can see what is happening while it is on. Take the brake off, and the rules in force resume.

The brake is set in the cluster, by whoever administers the cluster. Clearing it is done in the cluster too: the AuthFI console and control plane have no control over it.

How rules reach a node

Rules reach a node within 30 seconds of a change: turning protection on, or saving new rules for a protected workload. A revocation reaches the node the same way, and is then checked on every request.

A node keeps deciding when something around it is unavailable.

A node agent with no rules answers 503 so that no request is decided by a guess.

Connections that are already open

A connection already open when a workload is switched to enforce mode is left alone until it closes. Rules apply to connections opened afterwards.

To have a workload's existing connections checked at once, restart the workload.

What is recorded

Every denial, in the kernel or at the proxy, is an entry in the audit record with the layer that denied it.

Security > Signals counts denials by cause and by the gate that denied, so you can see which rules are doing the denying. Choose Last 24 hours, Last 7 days or Last 30 days. The table has the columns Cause, Refused at and Refusals.

Next steps