Check that no data leaves

By the end of this tutorial, you have built the artifact a customer receives and obtained proof, on that exact binary, that it contains no outgoing network calls.

The time is unevenly distributed. The first two steps install and build the repository, once and for all, and take anywhere from a few minutes to about twenty depending on your connection and the state of your npm cache. The verification itself, steps 3 to 6, takes a few seconds. Step 7, optional, checks the JetBrains plugin and requires a few more minutes of building.

You run this verification yourself, on the shipped product, without reading the source code. It holds for both ways of deploying Lemniscate, integrated into your stack or as a full coding assistant: the artifacts are the same.

Lemniscate commits to sending no data to the vendor: no telemetry, no error reports, no license checks. That commitment corresponds to an absence of code, observable during an audit (security white paper V3, sections 1.3 and 11.3). This tutorial makes that observation on the artifacts. It complements the first of the six verifications the white paper offers to the security officer, network observation, without replacing it: the last section places them in context.

1. Install the dependencies

A npm ci at the root on its own installs only the formatting tools: the repository is not a single npm workspace. The full chain is the one below, and the repository snippet check runs it.

npm ci
node ./scripts/build-packages.js
npm ci --prefix core
npm run build --prefix core
npm ci --prefix packages/lemniscate-sdk/typescript
npm run build --prefix packages/lemniscate-sdk/typescript
npm ci --include=optional --prefix extensions/cli
npm ci --prefix extensions/vscode
npm ci --prefix gui
npm ci --prefix llm-gateway
npm ci --prefix gateway-admin

2. Build the other deliverable units

The check in step 4 inspects the six shipped units: the terminal, the VS Code extension, the graphical interface, the gateway, its console, and the JetBrains plugin. It refuses to draw a conclusion about a missing unit: an absent artifact does not read as a clean artifact. All six must therefore exist on your disk.

Five are built with the commands below. The sixth, the JetBrains plugin, requires a Java virtual machine and several minutes: it has its own step, at the end, and the check states itself that it has not looked at the plugin until you run that step.

mkdir -p extensions/vscode/build
(cd extensions/vscode && npm run esbuild-base)
(cd gui && NODE_OPTIONS=--max-old-space-size=6144 npx vite build)
(cd llm-gateway && npm run build)
(cd gateway-admin && npm run build)

npx vite build rather than npm run build for the interface: the repository’s build script chains a type check onto it that the compliance check does not require. The memory is raised because building the interface exhausts Node’s default heap and stops without a message.

These first two steps are the only ones that need Internet access, and the only long ones. You will not repeat them. Everything that follows runs with the network off and takes seconds.

3. Build the terminal, without specifying a profile

npm run build --prefix extensions/cli

Pass no profile. With no instruction, the build produces the restricted artifact. The default is closed.

4. Ask for the proof

node scripts/verify-onprem-artifact.mjs \
  --composant cli --composant vscode --composant gui \
  --composant llm-gateway --composant gateway-admin

The script inspects the artifacts that were just produced and looks for the symbols of the network egress layer. It completes successfully, and its last line begins with “No new violations”.

Above that, it lists egress paths that are still present, with a count of “known debt”. This is not a failure: the check knows the list of paths that have not yet been removed from the product. It is written in scripts/onprem-violations-baseline.json with, for each one, the reason it is there. That list can only shrink: a path that appears without being listed makes the check fail, and a path removed from the product without its line being deleted makes it fail too. The guarantee is on that point: no leftover can be added without you seeing it.

The report names the JetBrains plugin among what it did not look at, and states that the debt lines concerning that plugin are neither judged nor declared paid. The check asserts nothing about an artifact it has not opened, good or bad. Step 7 gives it the plugin to look at.

5. Watch the check fail

Rebuild, explicitly requesting the open profile:

LEMNISCATE_DEPLOYMENT_PROFILE=serverless npm run build --prefix extensions/cli
node scripts/verify-onprem-artifact.mjs \
  --composant cli --composant vscode --composant gui \
  --composant llm-gateway --composant gateway-admin

This time the script reports the symbols present and exits with an error. You have seen the difference between the two artifacts, and confirmed that the check detects it.

6. Go back to the closed artifact

npm run build --prefix extensions/cli

7. The sixth deliverable: the JetBrains plugin

The plugin is written in Kotlin and shipped as an archive, not a JavaScript file. Building it requires a Java 17 virtual machine and takes several minutes. The rule is the same: with no profile requested, you get the air-gapped artifact.

(cd extensions/intellij && ./gradlew buildPlugin)
node scripts/verify-onprem-artifact.mjs --composant intellij

The resulting archive is in extensions/intellij/build/distributions/. The same archive built with the open profile is noticeably heavier: the open profile adds two full emission libraries that the air-gapped profile does not bundle.

Then run the counter-test, as in step 5:

(cd extensions/intellij && ./gradlew buildPlugin -PprofilDeploiement=serverless)
node scripts/verify-onprem-artifact.mjs --composant intellij

The check does not hold its symbols against this archive: it recognizes the open profile, declines to judge it, then exits with an error. A serverless artifact conforms to what was asked of it; its air-gapped conformity is not established, and the check does not claim to have established what it has not verified.

What you have established

The restricted profile is what you get without asking for it, and an artifact containing an outgoing call is detected by a check that also runs on every proposed change to the product.

To understand what that profile covers, read Where the data goes.

The six verifications in the white paper

The security white paper V3, section 12.1, offers six verifications to run yourself. This tutorial covers the artifacts; the six cover a deployment, with your own tools.

Verification	What it confirms	On this site
T01. Observe the network	No traffic outside the matrix in section 3.3.	This tutorial establishes that the artifacts carry no emission code; the observation is done with your own probes.
T02. Attempt a network egress from a sandbox	Containment: the sandbox has no network interface.	Execution guardrails
T03. Attempt a read outside the repository copy	Containment: the perimeter is the working copy.	Execution guardrails
T04. Load the SBOM and the VEX into your tools	Transparency on dependencies.	Supply chain
T05. Replay a session and reconstruct it from the logs	Traceability.	Read a session’s actions in the Audit tab
T06. Attempt a content injection on a test repository	Content that is read does not widen the session’s rights.	The life cycle of an agentic session