Integrating Lemniscate into your stack

Lemniscate provides the confined runtime for code agents, deployed inside your perimeter. This page is for teams that already have a code agent (OpenCode, an in-house tool), a model proxy (LiteLLM) and an inference engine, and that want to authorize this agent on a sensitive perimeter. Lemniscate sits alongside this stack and adds confined execution, policies, the log and revocation (security white paper V3, section 3.4).

If you have nothing in place yet, the path for you is Install the full code assistant.

What you keep

• Your agent. It still carries the work loop: read the developer’s instruction, query the model, propose changes and commands.
• Your model proxy and your inference engine. The gateway connects to any engine that exposes an OpenAI-compatible API, with the open-weight model you have selected. The choice of model, the provenance of its weights and its updates remain yours to handle (security white paper V3, sections 3.4 and 11.1).
• Your directory and your SIEM. Lemniscate does not manage identities: authentication goes through your organization’s identity provider (OpenID Connect), or through local accounts in an isolated environment. Logs are exported to your SIEM (security white paper V3, sections 6.1 and 7.1).
• Your repositories and your review process. The agent has no account on the forge and pushes nothing. The developer integrates the approved diff under their own identity, with their usual tools (security white paper V3, section 4.3).

What Lemniscate adds

Two components are installed on your side, each on its own machine.

The gateway services, on a Linux host: the gateway, its database and the administration console. The gateway authenticates, applies the project policy, drives the session, logs and revokes. It is the only component that talks to all the others.

The execution host, separate from the gateway host: it carries one sandbox per session, created on demand and destroyed at the end, with no network interface and a working copy of the repository as its only writable volume. It keeps no state between sessions and accepts only one inbound control channel, opened by the gateway.

These two components hold the seven session guarantees, whatever the agent and whatever the model (security white paper V3, section 4.1):

Guarantee	What it bounds
G01	The perimeter: the copy of the repository authorized by the project policy.
G02	Writes: every retained write is approved by a human, as a diff.
G03	Commands: the administrator’s policy, applied by the gateway.
G04	Execution: a disposable sandbox.
G05	The network: no reachable destination, external or internal.
G06	Traceability: instruction, proposed actions, decisions, results.
G07	Stop by the developer and revocation by the administrator, at any time.

Your agent and your model stay outside the trust perimeter: they propose, and it is the gateway and the sandbox that hold the rights (security white paper V3, sections 3.1 and 8.1).

What connects to what

Integration consists of routing through the gateway the two things your agent does outside itself: talking to the model, and acting on the code.

From	To	What travels
The agent	The gateway	Exchanges with the model, and the actions to run in the sandbox.
The gateway	Your proxy or your engine	Inference requests, over TLS. Only the gateway host reaches the engine.
The gateway	The execution host	A single control channel, opened by the gateway.
The gateway	Your directory and your SIEM	Authentication and log export.
The sandbox	No network	Nothing: no network interface, no name resolution.

This matrix matches the one in the security white paper V3, section 3.3. It contains no flow leaving your perimeter.

Exchanges with the model

This connection has a documented procedure on this site. It comes down to two declarations.

On the gateway side, you declare your proxy or your engine as a provider in the administration console: its address, and the name of the environment variable that carries its key. The gateway does not store the key, it reads it from its own environment when relaying. You then declare the model, followed by the endpoint that routes it. The steps are in Declare a model served by the gateway.

On the agent side, you replace the proxy address with the gateway address, followed by the endpoint name. The gateway strips this first segment and appends the rest of the path to your provider’s address: your agent keeps speaking your engine’s dialect. It authenticates with its user’s account key, and no longer holds the engine key. The interface a third-party program can rely on is described in The gateway relay.

Each call is then tied to a user and recorded in the database. What this detour provides is described in The role of the gateway.

Actions on the code

The target is as follows. Your agent no longer runs anything on the developer’s workstation or on the machine where it runs itself. For each session, the gateway loads the project policy and opens a sandbox on the execution host, with a working copy of the repository. The reads, writes and commands the agent proposes are run there, after evaluation by the gateway. The result comes back to the developer as a diff, which they accept or reject (security white paper V3, section 3.2).

This connection has no published procedure on this site. The protocol through which the gateway receives a command to run is that of Lemniscate extensions, and it is not an interface a third-party program can rely on. Connecting a third-party agent is prepared with the vendor, on a first deployment limited to one team and one repository (security white paper V3, section 12).

Policies, the log and revocation

These three functions live in the gateway services and require nothing from your agent.

• The project policy is written by the administrator in the console: active tools, free commands, commands subject to approval, budgets. By default, no command is free. The gateway evaluates every action before it runs, and the model never reads the policy as an instruction (security white paper V3, section 5.1).
• The log is append-only. It reconstructs a session: who authenticated, what instruction was given, what the agent proposed, what the developer decided, what was run. The content of the code and of the exchanges is absent by default (security white paper V3, sections 7.1 and 7.2).
• Revocation is done from the console, per session or per user. It takes effect without a restart, destroys the sandbox and leaves a trace in the log (security white paper V3, section 4.5).

What you need on your side

• A Linux host for the gateway services, and a separate execution host. On a base that allows a container engine on workstations, the sandbox can run on the workstation: that is the variant, the dedicated host being the reference mode (security white paper V3, section 4.4).
• An inference engine, or a proxy in front of it, that exposes an OpenAI-compatible API and that the gateway host can reach.
• Network filtering that allows only the gateway host to reach the engine and the execution host. This rule is yours; the matrix above lets you verify it with your own probes (security white paper V3, section 11.5).
• An OpenID Connect identity provider, or the decision to use local accounts.
• An agent whose model service address can be configured.

The same product deploys in connected, isolated, sensitive or classified mode. In isolated mode, it is delivered on media, as a signed archive, and runs without any connection to the vendor (security white paper V3, sections 3.4 and 9.3).

Next steps

• Discover the gateway: bring up the three services on a workstation and route a first call through them, to see how they fit together.
• Architecture: the four roles and their trust zones.
• The lifecycle of an agentic session: what happens between the instruction and the diff.
• Verify that no data leaves: the verification your security officer runs on the delivered artifacts.