Ingest, observe, decide, act

Everything Axiom Border does fits into four stages. They run in parallel and on their own clocks — the numbering follows a single observation through the product, not an order of execution. What binds them together is that all four write to the same local state, and all four can raise an alarm.

flowchart LR
    I["<b>1 · INGEST</b><br>from the machines"] --> O["<b>2 · OBSERVE</b><br>from the network"]
    O --> D["<b>3 · DECIDE</b><br>local rules"]
    D --> A["<b>4 · ACT</b><br>alarm and notice"]
    A -.->|optional| C["OpenGate"]:::ext
    classDef ext fill:#e9edfa,stroke:#486ac9,color:#101010

1 · Ingest — what the machines report about themselves

Every monitored machine runs a lightweight agent that watches it from the inside and sends what it sees. Four monitors, each answering one question:

Monitor What it watches
SSH-Guard Interactive sessions and login attempts against the machine
USB-Guard Devices attached to and removed from its ports
IFACES-Guard The state of its physical network interfaces
METRIC-Guard The machine’s own health, and the heartbeat that proves it is still reporting

You see this stage in two views. Supervisions lists the agents reporting in, one card per monitor, with the last event each delivered. Hosts Status turns the same data around and shows one block per machine, with the alarms currently open against it.

2 · Observe — what the probe works out for itself

Four probes on the network, one listening and three asking, each with its own scheduler. This is the stage that needs no cooperation from the equipment it watches, and it is covered in full on the next page: The four probes.

Everything they find lands in Network status.

3 · Decide — rules that run on the probe

Two mechanisms, both evaluated locally against data the probe already holds:

  • Rules on each event, as it arrives. One rule set per probe, so a rule can react to a new host, a newly opened port or a changed value the moment it is observed.
  • Periodic checks against the history. Counting occurrences over a window, and detecting the absence of them — a node that stopped reporting is a condition you can only see by looking for silence.

Both are edited from Alerts → Rules configuration. Neither needs the uplink, which is the whole point: a probe whose link is down still decides.

4 · Act — the alarm, and who hears about it

A raised condition becomes a coalesced alarm — one alarm with a count, not one alarm per occurrence — which lands on the operator’s Alerts view and in the probe’s live feed, so the console’s counter moves immediately. From event to alarm covers how that works and why it is built that way.

And then, only if you asked for it, the same alarm goes out to OpenGate.

Nothing leaves the machine by default

This is the commercially important half of the loop, so it is worth stating plainly:

  • The OpenGate integration is optional and starts inert. It has to be configured and enabled before a single byte goes anywhere.
  • The message broker the console listens on lives on loopback. It is not exposed to the network.
  • All four probes write to local storage before any decision to publish exists.

A probe you install and never configure for the cloud is a probe that never talks to one. What travels when you do enable it is the complete inventory of your network, which is exactly why the probe refuses to start that integration over an insecure address — see Security posture.

Next: The four probes — the observation stage in detail.