CSI PRO vs On-Premise: Where Your Cybersecurity AI and Data Actually Run

Understanding what CSI can support across the security lifecycle is only half the architecture decision. In our previous article, Beyond AI Pentesting: How CSI Supports the Security Lifecycle, we looked at what the six-layer stack does. The next question is where those layers execute, and what crosses the trust boundary.

Alias Robotics currently defines its Cybersecurity AI stack across six tightly integrated layers: LLMs, scaffolds, datasets, agents, steering and benchmarking. Those layers do not necessarily share one physical location.

The right deployment depends on what you need to control

A CISO or security architect should separate model inference from orchestration, agent and tool execution, model context, operational logging and provider dependency.

This is also a more useful way to think about sovereignty. Endpoint geography matters, but so does control over the rest of the intelligence stack. Alias Robotics’ current analysis of European AI sovereignty makes the same broader architectural point: models, data, post-training, evaluation, scaffolds, agents and deployment infrastructure can represent separate control points.

Which one is right for your organisation?

The decision is less about company size than about capacity, infrastructure control and data requirements.

CSI PRO is a hybrid architecture, not simply “AI in the cloud”

The current CSI documentation describes a local wrapper and routing proxy. Whichever supported scaffold is launched, its API traffic is directed to a proxy on 127.0.0.1. That proxy handles wire-format translation, model switching, quota preflight, telemetry filtering, JSONL logging and the cost ledger before routing requests to the selected model backend.

The orchestration path therefore begins inside the customer environment. CSI dynamic workflows create local workflow artefacts and dispatch agents as jobs across supported cybersecurity scaffolds. Working files and key CSI logs are kept in host or container paths controlled by the customer.

Model inference is separate. Alias model identifiers route to the Alias API; the current Alias LLM family describes the hosted route as EU-hosted. CSI can also route to OpenRouter, Anthropic and other provider models, or to a custom OpenAI-compatible endpoint that may itself be local or remote.

The current CSI product and deployment page lists CSI PRO Monthly and CSI PRO Yearly. Yearly includes everything in Monthly plus additional consulting. Nothing currently published indicates a different technical deployment architecture between them. These are commercial variants of CSI PRO, not separate trust-boundary models.

What stays local under CSI PRO

The harness is local: the wrapper, supported scaffolds and routing proxy that coordinate the work. CSI’s multi-agent workflows are instantiated through that environment, and agents can act against tools, files and systems available to the deployment. The CSI scaffolds documentation also describes the local orchestration environment, while CSI documentation identifies local paths for proxy logs and supported scaffold transcripts.

That matters because local access is not the same as automatic data export. A tool can scan a target or read a file locally without the architecture implying that the entire filesystem, network or log estate is sent to a model provider.

But local orchestration is not local inference.

What crosses the perimeter when inference is remote

If an agent uses a remotely hosted model, the information included in the inference request must reach the backend performing inference. The documented CSI routing architecture routes model requests from the local proxy to the selected upstream.

Depending on the workflow, that may include prompts, system instructions, conversation context, selected tool outputs, technical findings, fragments of logs or target information incorporated into model context. Credentials or other sensitive operational information cross that boundary only if a workflow includes them in a request. Local tool access does not mean the entire underlying resource is transmitted to the model.

For privacy and infrastructure teams, the critical question is therefore not only “what can the agent access?” but:

What does the scaffold place into model context, and where is that model served?

Telemetry filtering is not zero data egress

CSI’s local proxy is designed to block non-essential telemetry. The CSI documentation describes environment controls, network filtering for supported JavaScript scaffolds and a universal proxy whitelist. That same whitelist permits the API paths needed for model requests.

These are different traffic classes. Blocking analytics or non-essential telemetry reduces unnecessary outbound traffic. It does not keep a request to a remotely hosted LLM on the machine.

“Telemetry disabled” should therefore never be read as “zero data egress”. When hosted inference is being used, inference traffic still crosses the relevant trust boundary.

Third-party models create different data boundaries

CSI routing supports Alias models, OpenRouter, Anthropic and OpenAI model slugs, plus custom OpenAI-compatible endpoints that can be local or remote. The local scaffold may be the same, but the data boundary is not.

• Alias-hosted model: the harness routes inference to the Alias API.
• Third-party model: the request goes to the selected provider or routing service.
• Local self-hosted endpoint: inference can remain inside an organisation-controlled environment.

The current CSI PRO terms state that third-party models are governed by their own terms and privacy policies. Choosing a backend is therefore also a data-governance decision.

A self-hosted model endpoint, however, is not the same thing as CSI On-Premise. Moving inference locally changes one boundary. CSI On-Premise changes the deployment boundary of the complete six-layer stack.

What changes with CSI On-Premise

The current CSI product and deployment page describes On-Premise as “All six layers, on your hardware, on demand.” Publicly listed scope includes the full Alias model family on-premise and air-gapped, self-hosted CSI meta-scaffolding and CAI framework, sovereign cybersecurity training-corpus access and custom fine-tuning, bespoke agents, domain steering, and private benchmark suites with audit logging and forensics.

That is materially different from moving only an LLM behind the firewall. The deployment is designed to bring the intelligence stack itself inside customer-controlled infrastructure.

Alias also publishes a national cyber-defence case study in which a European national defence organisation deployed CSI entirely on-premise inside sovereign infrastructure. It shows the deployment model in a real engagement without implying that every regulated organisation needs the same architecture.

CSI PRO vs CSI On-Premise by layer

A local or self-hosted model endpoint under CSI PRO moves inference inside the chosen environment, but it does not automatically constitute the complete CSI On-Premise product. CSI On-Premise places all six published layers within customer-controlled infrastructure.

The important point is that “local” has to be qualified. A locally running agent can invoke a remotely running model. A local model endpoint can sit behind a local CSI harness without necessarily representing the complete CSI On-Premise product. And a locally stored transcript does not, by itself, determine what the model backend processed.

What air-gapped deployment changes

Alias Robotics currently describes CSI On-Premise as supporting air-gapped deployment. In this model, the stack is deployed within customer-controlled infrastructure, bringing model inference and the other published CSI layers inside the customer’s trust boundary.

For organisations whose threat model or operating environment requires isolation from external networks, this changes the architecture materially: the model, scaffolds, datasets, agents, steering and benchmarking can be deployed within the environment the customer controls.

How security leaders should choose the boundary

There is no universal rule that remote inference is wrong and on-premise is right. The decision depends on the sensitivity of model context, acceptable external dependencies, latency and availability requirements, infrastructure constraints, legal obligations and the organisation’s threat model.

CSI PRO combines local orchestration and execution with a backend-dependent inference boundary. That can fit teams that want CSI’s local harness while permitting selected model context to reach an approved hosted backend. A self-hosted model endpoint can move inference inside the customer network without automatically turning the deployment into the full CSI On-Premise package.

CSI On-Premise goes further by bringing all six layers into customer-controlled infrastructure. That additional control becomes material when model requests cannot leave the perimeter, when upstream availability is an unacceptable dependency, or when defence, critical infrastructure, restricted environments or air-gap policies demand a dedicated deployment.

“Where does your Cybersecurity AI run?” is several questions: where the model reasons, where scaffolds orchestrate, where agents act, what context crosses a boundary, who governs the backend, and how the system is logged and maintained.

CSI PRO and CSI On-Premise answer those questions differently. The useful distinction is not “cloud versus local”. It is which parts of the intelligence stack your organisation needs to control, and where that control must sit.