Deployed on your machines. Run by you.
SILO.RED comes two ways. The retail clients, Personal and Professional, install on one or two computers and need nothing else. For an estate, Cortex runs on a Linux host of your own and agents enrol with it over mutual TLS; gateways, clusters and clouds connect to the same address.
Personal and Professional
A client on one or two computers, with its own console and no server. Download, install, enter a key.
Retail deployment → EnterpriseCortex and endpoint agents
A control plane you host, an agent on each machine, and the gateways, clusters and clouds around them.
Enterprise deployment →One installer for Cortex. One package per platform.
Pick a part to see how it goes on. Commands are shortened; the operator documentation has every option.
Cortex Available
The control plane runs on one Linux host with Docker. The installer asks each question in turn, or takes flags, checks every answer before it writes anything, and starts the stack.
- Postgres on a network with no outside access, or your own database
- Migrations applied by a one-shot before Cortex starts
- Containers run as non-root, read-only, with every capability dropped
- Your certificate, Let’s Encrypt, or a self-signed one
$ sudo ./silo-cortex-install.sh \ --domain cortex.example.com \ --role standalone --tls letsencrypt✓ answers checked✓ database started, migrations applied✓ cortex and console up✓ https://cortex.example.com/ health: healthy
The console and the SOC wall display Available
Nothing separate to install. The installer starts the console on 443, in front of the API and the agents’ enrolment, so browsers, agents and an MDM all see one address.
- First visit creates the administrator; a second attempt is refused
- Sign-in with your identity provider through OIDC, with MFA required
- The SOC wall display is the same console with ?mode=soc, or on a host name starting map.
→ https://cortex.example.com/✓ create the administrator✓ Administration → Licence: key accepted→ https://cortex.example.com/?mode=soc✓ full-screen attack map on the wall
Child Cortex Available
A large estate runs a child Cortex per site or region. Each watches its own hosts and keeps working on its own; the parent gets a rollup per host, decisions at Restrict and above, and serious alerts.
- Same installer, with --role child and the parent’s address
- Admitted only from the parent, with the child’s own licence key
- Federation runs over TLS; plaintext is refused
- Needs an Enterprise parent
$ sudo ./silo-cortex-install.sh --role child \ --parent cortex.example.com:9190 \ --federation-token …→ parent: Infra → Add Cortex, with the child’s key✓ child key validated✓ handshake done, first rollup received
Endpoint agents Available
Each package is built for your estate with Cortex’s address and certificate authority inside it. Give the agent a join token, approve it once, and it reports over mutual TLS.
- Linux: a .deb for Ubuntu and Debian, three small services
- Windows: an MSI with a service and an optional kernel driver
- macOS: a notarised app run as root through Endpoint Security
- Keys held in the TPM or Secure Enclave where the host has one
- Join tokenminted by an administrator
- Requestthe agent makes its key and asks
- Approvein Pending Agents, against your seats
- Certificate30 days, renewed in the last week
- Reportingmutual TLS, no restart
$ sudo apt install ./silo-linux-agent_….deb$ sudoedit /etc/silo/agent/agent.env$ sudo systemctl enable --now silo-agent✓ enrolled, reporting
Kong Available
The SILO plugin tells Cortex who called which model and enforces Cortex’s decisions at the door: a Restrict rate-limits the agent, Isolate blocks it, and release lifts both.
- Configured with Cortex’s address and an API key
- Heartbeat every 10 seconds, decisions pulled every 3
- Metadata only; bodies are never stored
- Azure API Management, Apigee and AWS API Gateway Early Preview
plugins: - name: silo config: cortex_api_url: https://cortex.example.com cortex_api_key: …✓ gateway listed in Cortex
Kubernetes Add-on Early Preview
An operator in the cluster, with SiloAgent, SiloPolicy and SiloTenant resources, that can evict, cordon and quarantine. It is built and tested and has not yet run on a real cluster.
- Watches agent pods and reports to Cortex
- Policy written as custom resources
- Running Cortex itself on Kubernetes through a Helm chart Planned; use the installer on a Linux host today
→ operator in the cluster✓ SiloAgent, SiloPolicy, SiloTenant resources✓ evict, cordon, quarantine✓ findings to Cortex○ first run on a real cluster: to come
Cloud
A cloud virtual machine is a Linux or Windows host, and takes the same package. Connectors act through your own provider accounts.
- Agents on EC2, Azure and Compute Engine VMs Available
- AWS, Azure and Google Cloud connectors: isolation, WAF rules, flow logs Early Preview
- Cortex on AWS, Azure or Google Cloud from Terraform: written, not yet applied Early Preview
- A cloud action that cannot be carried out fails with the provider’s reason; it never reports success
SILO_AWS_REGION=eu-west-2SILO_AZURE_ISOLATION_NSG=…SILO_GCP_PROJECT_ID=…✓ each provider’s state shown in the console✓ isolation uses your own account
Cloud plugins Early Preview
For agents that run where no endpoint agent can go: functions, managed gateways and model services. Each plugin sends to Cortex over HTTPS; none has yet run in a customer’s own cloud account.
- AWS: a Lambda layer for agents in Lambda, and API Gateway and Bedrock logs through Firehose
- Azure: an API Management policy, and a Python module for agents in Functions
- Google Cloud: an Apigee shared flow, API Gateway logs through Pub/Sub, and a Python module
- Metadata only: requests and responses, never prompts or bodies
# the function’s environmentSILO_CORTEX_URL=https://cortex.example.comSILO_AGENT_NAME=claims-agent✓ silo_monitor layer attached✓ the function’s activity reaches Cortex
NetApp ONTAP Early Preview
Cortex reads what agents do to shared storage and scores it against the agent: audit records, volume metrics, XCP transfers and SnapDiff changes, with mass deletes and encryption-shaped writes among the signals.
- Clusters added in the console’s Storage screen, credentials stored encrypted
- Talks to ONTAP’s REST API with an account you create for it
- Run against a simulated filer so far; the live file-policy listener does not yet speak ONTAP’s own protocol
SILO_NETAPP_ENABLED=trueSILO_NETAPP_ENC_KEY=…→ Storage → add cluster✓ audit and volume metrics polled✓ storage activity scored against the agent
VMware Early Preview
Where agents run inside virtual machines, Cortex can watch the VMs themselves and act on a whole machine: isolate it from the network or take a snapshot before a response.
- VMware Workstation and Fusion: VM events, isolation and snapshots
- The hypervisor reader compares a VM’s memory with what its own kernel reports
- Configured on Cortex with the host and an account; isolation on its own only when you allow it
- Not yet run against a live VMware host
SILO_VMWARE_ENABLED=trueSILO_VMWARE_HOST=vmhost.example.comSILO_VMWARE_AUTO_ISOLATE=false✓ virtual machines listed✓ isolate and snapshot from the console
Windows Terminal Server Early Preview
On a Remote Desktop Services host many people run agents on one machine. The Windows agent is installed once per host and watches every process, whichever session started it.
- The same MSI and enrolment as any Windows host
- Canary credentials planted in each user’s profile
- A network block applies to a program, not a session, so the agent refuses one that would cut other users off, and names them
- Proven on Windows 11; not yet run on Windows Server with Remote Desktop Services
> msiexec /i SILO-Enterprise.msi /qn> Restart-Service SiloEnterpriseAgent✓ enrolled with Cortex✓ every session’s agents watched
Manual and air-gapped installs Available
Every step the installer takes can be done by hand, and a site with no route out can run the whole platform.
- --no-start writes the stack without starting it, for review or change control
- A bare docker compose up -d starts the same stack afterwards
- Licensing set to isolated, or an offline build that never calls out
- Agent packages copied in and installed with your own tooling or MDM
$ sudo ./silo-cortex-install.sh \ --entitlement isolated --no-start$ docker compose up -d✓ running, no outbound connections
Personal and Professional, for one or two machines.
The retail clients run on their own, with a console on the machine and no Cortex. Both watch and score every agent; Professional may also isolate and end one, and asks first.
Personal Available
- One machine
- 7-day trial
- Observe and restrict
- The built-in, on-device model
- Seven days of history
Professional Available
- Two machines
- 14-day trial
- All four responses; isolate and terminate ask first
- On-device model, or a cloud model with your own key
- Runs as a background service; command-line tools; unlimited history
macOS
A signed installer package. SILO.RED appears in Applications with an icon in the menu bar, which opens the console and signs you in.
- Touch ID, or the Mac password, before the console opens
- Starts at login, or at boot before anyone logs in
- Removed with Uninstall SILO.RED, which also clears its decoys and data
$ open SILO.RED.pkg✓ SILO.RED in Applications✓ menu bar: open console✓ Settings → licence key: Professional✓ watching the agents on this Mac
Windows
An MSI, installed by an administrator. A tray icon opens the console and signs you in.
- Windows Hello can be added for sign-in
- Removed from Apps, or with msiexec /x
> msiexec /i SILO.RED.msi✓ installed✓ tray icon: open console✓ Settings → licence key: Personal✓ watching the agents on this PC
Linux
An install script run as yourself, with no root. SILO.RED runs as a user service that starts when you log in.
- The console opens from the tray, or at 127.0.0.1:9092
- Stopped with its own command, never the service manager: an unexplained stop is treated as an attack
$ ./install.sh✓ user service enabled✓ console at 127.0.0.1:9092✓ Settings → licence key✓ watching the agents on this machine
You may decline an update. Nobody may redirect one.
An update is code that runs as the security product, so where it comes from is fixed when the software is built.
Retail clients and agents Early Preview
The update source and its signing key are compiled into each build. The client checks, downloads, compares the checksum and then the Ed25519 signature before it stages anything. An unsigned or unverifiable source is refused, and plain HTTP is refused. Automatic updates can be switched off, or set to ask first; the source can only be changed by a new build.
Cortex Available
Cortex does not update itself. You replace the images when you choose and start the stack again; the migration step applies only what is new. Licence, settings, policies, approvals and the record are in the database and carry over. Re-running the installer changes TLS, the role or the optional parts and keeps every secret.
Optional, and local unless you say otherwise.
Detection and scoring need no language model. A model adds an assistant that explains and triages; its verdict can raise a score and never lower it.
Cortex Available
Point Cortex at a model server on your own network, such as Ollama or LM Studio, in Settings. A cloud provider is used only if you configure one with your own key.
Baseline service Available
An optional machine-learning service started with --with-ml. If it is down, Cortex pauses calls to it rather than slowing down.
On the endpoint Available
A small model downloaded once with a pinned checksum, and refused if the machine cannot hold it. Nothing leaves the machine on this path.
Online, on your own server, or not at all.
These are Cortex’s modes. A retail client takes its key in Settings. Either way, a lapsed licence withholds licensed features and never stops SILO watching, responding or keeping the record.
Online
Cortex checks the key every hour and the revocation list every five minutes. Seats refresh daily or weekly.
Your own server
The same checks against a licence server you host, named with --ls-url.
At activation
Seats checked when Cortex starts and not again, for sites that allow a call out now and then.
Offline
Isolated seat entitlement, or an offline build that never contacts a licence server and never expires, its tier fixed when it is built.
What the Cortex host needs.
| Need | Detail |
|---|---|
| Host | Linux with Docker and Docker Compose |
| Database | Postgres 16, bundled or your own |
| A name and a certificate | Self-signed, Let’s Encrypt, or from your own certificate authority |
| 443 | Console, API, enrolment and gateways, through one address |
| 50053 | The EventBus, mutual TLS, from every enrolled agent |
| 9190 | Federation between parent and child Cortex |
| Monitored hosts | Ubuntu 22.04–26.04 and Debian 12; Windows 11; macOS 26 on Apple silicon |
Planning a deployment?
Tell us the size of the estate and what it runs, and we will send the installer and the operator documentation.