The role of the gateway

In the reference architecture, the gateway is the only component that talks to all the others: the workstation, the execution host, the inference server, your directory and your SIEM. The workstation reaches neither the inference engine nor the execution host; it knows only the gateway’s address (security white paper V3, section 3.1).

This page describes what the gateway holds, and what it does not do.

What the gateway holds

The gateway authenticates, applies the project policy, drives the session, logs and revokes (security white paper V3, sections 3.1 and 6). Together with the sandbox, it forms the product’s trust boundary: rights are held by these two components, not by the model or the agent.

Function	What it covers	Section of this page
Authenticate	identity comes from your directory; the agent has none	Identities and roles
Apply the policy	every action is evaluated before it runs, outside the workstation	The project policy
Drive the session	it opens the sandbox and talks to it over a single control channel	Session control
Relay to the model	it is the only component allowed to reach the inference engine	A single path to the model
Log	every session can be reconstructed afterwards	The audit log
Revoke	a session or a user is withdrawn from the console, with no restart	Withdrawing access

Identities and roles

Lemniscate does not manage identities: it relies on yours (security white paper V3, section 6.1). Authentication goes through your organization’s identity provider, over OpenID Connect, or through local accounts for isolated environments. Each session is tied to a user and a project.

Role	What it does
Security administrator	defines global policies and log exports; does not see the code
Project administrator	defines active tools, commands that run freely or need approval, budgets, project members
Developer	starts sessions in the projects they belong to; approves diffs and commands
Auditor	reads logs and policies, read-only, with no access to sessions
Agent	no account; reaches only the sandbox of the current session

The workstation holds neither key nor engine address

The workstation presents the gateway with a proof of identity that is only valid against the gateway: an OIDC token issued by your identity provider, verified locally against its public keys. When relaying a model call, the gateway strips the caller’s authorization and x-api-key headers, then sets the inference engine’s key in their place, read from its own environment, if the engine declares one. The workstation does not see this key, and nothing leaving the workstation makes it possible to reconstruct it.

The engine key is not in the database. The database records the name of the environment variable that carries it and the HTTP header to place it in; the value stays in the process environment. A copy of the database therefore yields no key. A missing variable produces a 500 error whose message names the missing variable.

Withdrawing access

Since each person has their own proof of identity, access is withdrawn without touching the other workstations. The administrator revokes from the console, by session or by user. Revocation takes effect with no restart, it is logged, and revoking a session destroys its sandbox (security white paper V3, sections 4.5 and 6.1).

The gateway keeps a revocation list: a subject on that list is refused, and the reason stays in the decision log. Revocation is checked before the endpoint is resolved, so that a revoked subject cannot probe which endpoints exist through return codes. None of these operations requires redeploying the gateway: it re-reads the database on every request.

The project policy

The policy is written by the administrator in the console, evaluated by the gateway before every action, and is not interpreted by the model (security white paper V3, section 5.1). It sets the active tools, the commands that run freely, the commands that require approval and the budgets. By default, no command runs freely.

Every command is evaluated on the gateway’s service side before it runs: a workstation can neither bypass the policy nor disable it. Any policy change is logged, with the old value, the new one and its author. What the policy distinguishes is described in Execution guardrails; how to write it is in Setting workstation policy from the console.

Session control

The gateway opens a sandbox on the execution host for each session, with a working copy of the repository, and talks to it over a single control channel that it opens itself. The execution host never initiates a connection, and no traffic flows the other way (security white paper V3, sections 3.2 and 3.3). The steps of a session are described in The lifecycle of an agentic session.

A single path to the model

Everything going to the model passes through the gateway (security white paper V3, section 8.2). Access to the inference engine is controlled at the network level:

• the engine only listens on the inference server’s internal network;
• your network filtering only allows the gateway host to reach it;
• neither the extensions nor the sandboxes know its address.

What this means for operations:

• the firewall rule to write for workstations has a single destination, the gateway;
• an inference engine is declared in the console, and the workstation’s configuration does not change when you switch engines;
• no component has a route to the Internet.

Along the way, the gateway applies the administrator’s policies, including secret detection. This relies on known patterns (infrastructure provider keys, access tokens, private keys, connection strings) and on entropy-based detection. The policy sets the response: block, mask or alert. Blocking is the default. A detected secret is not logged in clear text.

The audit log

The gateway logs every session: authentication, prompt, files read and modified, actions proposed by the agent, human decisions, executions in the sandbox, policy changes (security white paper V3, section 7.2). The logs are append-only, each entry contains the digest of the previous one, and the export to your SIEM follows a documented event schema (section 7.1). By default, the log contains neither the requests nor the code.

The console shows a session’s acts in its Audit tab; see Reading a session’s acts in the Audit tab.

Spending caps

This section describes the serverless build profile. In the on-premise artifact, the one installed inside your perimeter, the gateway has no billing: the module that counts spending is not in the artifact.

In the serverless profile, each account carries a plan, and each plan carries a monthly cap in euros. On every relayed request, the gateway recomputes the current month’s spending by aggregating request_logs with the models’ per-token prices, over a window that starts on the first day of the month. As soon as spending reaches the cap, the request is refused with a 402 status. If the billing database does not respond, the request is refused with a 503 status.

Account state	Behavior
no plan attached	refused, status 403
plan with a cap	refused at the cap, status 402
plan with no cap	no refusal on spending grounds

After the join, “no plan” and “unlimited plan” both produce an empty cap. Only the attachment to a plan tells the two apart, and they lead to opposite outcomes.

In both profiles, the gateway writes one usage row per relayed request (subject, source, model, tokens, latency), which serves operations.

Endpoint indirection

The client does not call a model, it calls an endpoint: a name you publish that designates a model served by an inference engine. When the request body is JSON, the gateway overwrites its model field with the endpoint’s. An endpoint name describes a use, for example code-principal or completion-rapide, not the model of the moment.

Redirecting an endpoint to another model is therefore a change made in the console, which takes effect on the next request, with no workstation reconfigured. You replace the model when a better one is available, and the sessions’ guarantees stay the same (security white paper V3, section 8.1).

Encrypting inbound traffic

Traffic between components is encrypted with TLS (security white paper V3, section 6.2). The gateway terminates TLS itself as soon as you give it a certificate and its key, through the TLS_CERT_FILE and TLS_KEY_FILE environment variables. It then announces at startup that it is listening over TLS. A half-set configuration (only one of the two variables, or an unreadable pair) is refused at startup.

Without these two variables, it listens in clear text and announces it at startup. This case assumes a TLS terminator placed in front of it encrypts the workstations’ traffic.

The path of a model call, end to end

Each of the previous sections describes one property. The full sequence shows two things: the checks have an order, and the refusal happens at the first one that fails.

Four things can be read from this diagram.

• The proof of identity leaving the workstation is not the key arriving at the engine. These are two separate arrows, and between them two gateway actions.
• An unknown endpoint is refused early. Revocation is checked before the endpoint is resolved.
• Every verdict, granted or refused, is recorded in a separate table, except for the 404 of an unknown endpoint. An approval whose record could not be written becomes a 503 refusal. The usage row is written after a response that completed.
• Verdicts are not cached. The database is re-read on every request, and a change made in the console takes effect on the next request, with no restart. Kept in memory for a time: OIDC discovery and the identity provider’s public keys, and the license seat counter.

One code does not appear on the diagram: the 500 of a missing key variable (see above).

What this diagram does not show

• The plan and cap of the serverless profile, absent from the on-premise artifact; see Spending caps.
• The check on the engine’s certificate, which happens on the outbound arrow and which no gateway setting disables. UPSTREAM_TLS_CA_FILE adds a certificate authority without removing any.
• The gateway’s other addresses. The relay is not the only one: two addresses for running agent commands exist, with the same sequence of checks and no inference; four addresses serve the installed documentation without authentication; three addresses serve the IDE for organization policy, agent acts and identity provider discovery. The full list is in What the gateway does not do.
• The detail of the streaming path. For a stream, the response starts going to the workstation before the usage row is written: it is written at the end of the stream, in the background, with a retry queue if the write fails. The diagram merges the two paths into one.
• What happens in the session before the call. The agent loop, what it asks the human and what bounds it, is described in The lifecycle of an agentic session.

What the gateway does not do

• It has no destination outside your perimeter. Its only destinations are the execution host, the inference engine, your directory and your SIEM (security white paper V3, section 3.3).

• request_logs is not the session log. The table carries the timestamp, the subject, the endpoint, the model, the latency and the tokens: usage metadata. The gateway’s database role holds only the SELECT and INSERT rights, and startup refuses a role able to rewrite.

• It exposes neither a health route nor a version route. A supervisor expecting a /health finds nothing.

• It exposes ten addresses, five of which respond without authentication. An operator sizing their firewall and an auditor counting entry points need all of them:

  Address	What it is	Authentication
  POST /_agent-execution/commands	run an agent command	yes
  POST /_agent-execution/commands/:id/interrupt	interrupt an agent command	yes
  ALL /v	the root of the segment reserved for documentation	no
  ALL /v/_search	search in the installed documentation (GET only)	no
  ALL /v/_mcp	the same search, over the agent protocol (POST only)	no
  ALL /v/*	the files of the unpacked documentation (GET only)	no
  GET /ide/policy	organization policy, read by the IDE	license
  POST /ide/acts	agent acts submitted by the IDE	license
  GET /ide/identity-discovery	identity provider discovery	no
  ALL /:endpoint/*	the inference relay, catch-all placed last	yes

  The /v segment serves the documentation the operator unpacked alongside the gateway: it is read-only, it lists no directory, it calls no language model, and it is open because the documentation people come looking for is often the one that explains how to authenticate. With no documentation configured, it responds 501. The /ide/policy and /ide/acts addresses require the deployment license in the Authorization header. Each relay and documentation address is detailed in Reference: the gateway relay.

Three services

llm-gateway, gateway-db and gateway-admin are installed on the same host, separate from the execution host and the inference server (security white paper V3, section 6). They are separated because they do not run the same risks.

The gateway is on the path of every request: it stays small, and it holds the inference engine’s key. The console is an administration tool, reserved for administrators, and it has no need to know that key: it only talks to the database. You can restrict it to your administration network. The database is the only durable state, so the only thing to back up.

The split can be read in the traffic: the console does not call the gateway, the gateway does not call the console. They meet in the database. The overall diagram is in Architecture.