# What Axiom Border Is

## What Axiom Border is

Most edge monitoring works one way: a collector gathers data, ships it somewhere, and a platform decides
what it means. Take the link away and the collector is a data recorder at best.

Axiom Border is built on the opposite premise. It is **not an agent that reports to a cloud**. It is an
autonomous node that observes the network around it, decides what matters against rules it holds locally,
and acts on that decision — on the machine, with no server in the loop. Centralising into OpenGate is
something you switch on afterwards if a fleet-wide view is useful to you. It is never what makes the
probe work.

That single decision is why the product looks the way it does:

- **The decision engine is on the probe.** Alarms are raised where the data is, not where the platform is.
- **Everything it needs travels with it.** The vulnerability database, the vendor registry, the MIB
  catalogue, the scan templates, the metrics store, the container runtime and the web console are all
  installed with the product. A probe in an isolated network is useful the moment it starts.
- **Nothing is fetched at run time.** There is no feed to update before a scan means anything, and no
  service to call before a finding can be interpreted. What exactly it carries, where each data set comes
  from and how to refresh it in the field is set out in
  [Catalogs: vulnerabilities, OIDs, MIBs and more](../../catalogs/).

{{% notice style="note" title="Why this matters in an industrial network" icon="lightbulb" %}}
Isolated OT segments are isolated *on purpose*. A tool that needs to reach the internet to stay useful is
a tool that is either useless there or a hole in the isolation. Axiom Border needs neither.
{{% /notice %}}

## The specification, in one table

| | |
| --- | --- |
| **Deployment roles** | **`central`** — the full node: probe, metrics store and the container runtime for the AI capability. **`monitoring`** — a remote node that reports into a central one |
| **Installation path** | A single supported path, the **Keystone** deployment agent, and it is **100 % offline**. Roughly 5–8 minutes for a central node, 1–2 for a monitoring one |
| **Footprint** | About **141 MB** for a central core package and **89 MB** for a monitoring one, plus the bundled data packs, which are published once and reused across versions |
| **Management surface** | The **embedded web console** and a REST API, both served by the probe itself, both over **HTTPS unconditionally** — localhost included |
| **Internet access** | Not required, at install time or afterwards |

{{% notice style="warning" title="HTTPS is not optional" icon="triangle-exclamation" %}}
There is no plaintext listener to fall back to. A probe reached over `http://` refuses the connection, and
that applies to `localhost` as much as to anything else. On first boot the probe issues its own
certificate from a local authority, so it works with no PKI and no internet — see
[Security posture](../posture_and_storage/) for replacing it with your own.
{{% /notice %}}

## The two roles

A single probe covers a site on its own. The roles exist for when one site is not the whole picture.

```mermaid
flowchart LR
    M1["monitoring<br><i>remote node</i>"] --> C
    M2["monitoring<br><i>remote node</i>"] --> C["<b>central</b><br>probe · metrics store<br>console · AI"]
    C -.->|optional| OG["OpenGate"]:::ext
    classDef ext fill:#e9edfa,stroke:#486ac9,color:#101010
```

A **central** node is a complete Axiom Border: it watches its own network, holds the history, serves the
console, and can additionally receive from monitoring nodes. A **monitoring** node is the light end of
the fleet — it watches the machine it runs on and reports into the central one.

The dotted arrow is the point. OpenGate sits outside the boundary, it is optional, and it starts
switched off.

## How you work with it

**Through the console.** The probe serves its own web interface; point a browser at its address and log
in. Everything on the pages that follow is described from that interface, because that is how the probe
is meant to be operated.

A REST API exists underneath for integrating the probe with your own systems, and OpenGate drives the
probe over it. It is not the operator's path.

{{< staticImage "edge_products/axiom_border/console-login.png" "The Axiom Border console login" >}}

The console has six views, in the order the sidebar lists them:

| View | What it is for | Where it is documented |
| --- | --- | --- |
| **Network status** | Everything discovered on the network: assets, ports, vulnerabilities, and the passive inventory behind them | [Security assessment](../../security_probes/) |
| **Hosts Status** | The machines running a monitoring agent, one block per node | [Metrics and monitoring](../../metrics_ingestion/) |
| **Alerts** | Raised alarms, alarm history, and the rules behind them | [Alarms and rules](../../alarms_and_rules/) |
| **Supervisions** | The monitoring agents reporting in and what each last delivered | [Metrics and monitoring](../../metrics_ingestion/) |
| **AI capabilities** | Anomaly-detection models running on the probe | [AI capabilities](../../ai_capabilities/) |
| **Configuration** | The probe's own settings, edited and applied from the browser | [Configuration](../../configuration/) |

**Network status is the landing view**, which tells you where the product thinks the centre of gravity
is: what is out there, and is it exposed.

**Next:** [The full loop](../the_full_loop/) — the four stages a single observation travels through.