A security agent necessarily handles the most sensitive telemetry an organisation produces: internal hostnames, credentials that appear in logs, the shape of the network, the inventory of what is exposed. A product that routes that telemetry through a vendor's cloud to reach a model has created a second copy of your environment in someone else's custody. Monolith is designed so that copy never exists.
Two deployment models, one boundary
On-premises appliance. A purpose-built device on the intranet, in-line between the edge and everything behind it. Secure boot, a signed host OS, hardware support, and inference running entirely on the box. Loss of internet connectivity does not degrade detection or response. This is the right model for sites with strict residency requirements, unreliable connectivity, or an estate that is physically concentrated.
Your own cloud tenancy. The same agent deployed into a VPC or subscription you own, with the model weights, the evidence store and all inference inside your tenancy. This is the right model for cloud-native estates, multi-region organisations, or environments where an in-line appliance is impractical.
In both cases the boundary is yours. There is no Guardian-hosted path for telemetry, no vendor-side copy of findings, and no third-party model API between a signal and a response.
What stays inside the boundary
- Network flows, DNS, endpoint telemetry and identity events.
- Reconstructed attack paths, findings and their evidence.
- Model context, prompts and intermediate reasoning.
- The model weights themselves.
- The tamper-evident action record.
Any outbound connection — for intelligence feeds, for updates — is enabled explicitly, per data class, and logged. Egress is a deliberate decision, never a default.
Why local inference matters beyond privacy
Keeping inference inside the boundary is a residency decision, but it is also a speed decision. An external model API introduces queueing, rate limits and a dependency on a third party's availability between a finding and a fix. When time-to-exploit is measured in hours and attack-path reconstruction is measured in seconds, that latency is the difference between containment and compromise. Monolith inferences where the data is.
Choosing between them
| Consideration | Appliance | Your cloud |
|---|---|---|
| Residency requirement | Strongest — data never leaves the site | Strong — stays in your tenancy and region |
| Connectivity dependence | None for detection and response | Requires tenancy availability |
| Estate shape | Concentrated, in-line | Distributed, cloud-native, multi-region |
| Latency to telemetry | Lowest | Low, within the tenancy |
| Hardware ownership | You own the device | You own the compute |
Many organisations run both: an appliance at sites with physical infrastructure, a cloud deployment covering cloud workloads, with a single evidence model across them.
Bring your own model
Many CISOs have already standardised on an internal model, and have spent a year getting it approved. Monolith does not ask you to unwind that. It is the operator layer at the chokepoint of the intranet: the authorisation boundary, the evidence ledger, the approval gates, the connectors, the digital twin and the network-level isolation. Put the Monolith Model inside it, or point it at the inference endpoint you already run inside your boundary. The governance is identical either way, the model can be swapped without re-platforming, and the deployment is the same appliance or the same tenancy. Before anything touches production we evaluate your model against the twin, so you know how it performs in the operator seat.
A quarter, not eighteen months
You could build this layer internally. Most large organisations that have scoped it estimate eighteen months to take a model from approved to allowed-to-act with an audit trail that would survive a regulator, and that estimate is usually optimistic, because the hard part is not the model. It is the authorisation, the evidence and the approval machinery around it, which every enterprise would otherwise rebuild from scratch. We built that once, published the standard it is built to, and deploy it in a quarter. Your engineers go to the problems only you have.
For federal, defence, healthcare and financial estates where the inference boundary is a compliance requirement rather than a preference, the on-premises appliance is the deployment model, and the evidence chain is what you hand the assessor.
Frequently asked questions
Does Monolith send any data to Guardian Robotics?
No telemetry, findings or model context are routed through Guardian infrastructure in either deployment model. Outbound connections for threat intelligence and updates are enabled explicitly per data class and are logged.
Can the appliance operate air-gapped?
Detection and response function without internet connectivity. Intelligence and update ingestion require a connection, which can be scheduled, proxied, or performed by manual transfer in fully air-gapped environments.
Is the cloud deployment multi-tenant?
No. It runs inside your own cloud tenancy, with your own compute and storage. There is no shared Guardian-operated service in the path.
Can we run both deployment models together?
Yes. Organisations with both physical sites and cloud workloads commonly deploy an appliance at each site and a cloud deployment for the cloud estate, with a consistent evidence and policy model across them.
Where do the model weights live?
Inside your boundary — on the appliance, or in your cloud tenancy. The Monolith Model is engineered with Blackfrost AI and licensed for deployment under your control; there is no vendor-side copy of your environment.