Set workstation policy from the console

The policy is written by the administrator in the console and evaluated by the gateway before every action. It is never interpreted by the model, and it cannot be disabled or relaxed from a workstation (security white paper V3, section 5). It sets which tools the agent keeps, which ones ask for approval on every call, which commands run freely, and which session rules are forbidden. This page describes how to set it from the console’s Policy tab, through lists and menus, and what the console installs on your behalf.

By default, no command runs freely: every modification and every command is presented to the developer. The administrator can list free commands, remove a tool from the agent without redeploying, and allow or forbid the developer to skip revalidating a command already approved (security white paper V3, section 5.1). The policy sets no network access for the agent: the sandbox has no reachable destination (security white paper V3, section 4.1).

To open the console and sign in, see Open the admin console.

Open the Policy tab

The Policy tab summary in the sidebar states what it governs: “What this organization’s developer workstations may do.” The console carries another policy, that of the gateway itself, which sets who may administer what; this page does not cover it.

The screen opens in one of three states:

What the console knows	What the screen shows	What you do
the gateway has not announced the organization served	a This console does not know what to govern warning, with no button	restart the gateway, or check that it reaches this database
the organization does not exist in the database yet	“The organization <nom> does not exist yet” and a Create <nom> button	create the organization
the organization exists	“No policy is installed yet.” or “Policy <révision>, installed on <date> by <auteur>.”	set the policy, then apply it

The first state is an incident, to be handled on the gateway side. The other two are normal states.

Below the status line, the screen holds a draft of the document in force. Every action described below modifies this draft; nothing is installed until Apply changes.

Remove a tool from the agent

Tools the agent may use panel. Its description sums up the effect: “A removed tool is not even offered to the agent.” A removed tool does not appear in the catalogue presented to the model; a forced call is refused, naming the organization’s rule.

1. Open the Tool to remove menu. Each entry gives the tool’s name, what it does in one sentence, and the surfaces that carry it: “Bash”, “Runs a shell command”, “terminal, editor”.
2. Check one or more tools. The button states what it will do: Remove tool for one tool, Remove 3 tools for three. It stays inactive as long as nothing is checked.
3. Click the button. The checked tools move into the list of removed tools, each with its description and a Restore button, and are no longer offered in the menu.

Restoring is done line by line, through Restore.

The collapsed Tools that ask every time section follows the same pattern for tools that ask for human approval on every call: Tool that must ask menu, Ask every time or Ask every time (2 tools) button. Its title line states its state, “none” or the list of tools concerned. A removed tool is not offered in this menu, and vice versa.

What these lists do not edit, and what the console names when it exists:

• a pattern rule, such as Bash(rm *) or Write(src/**), or an entry the console cannot classify, such as *. They stay in force and are edited in the JSON document; the panel cites them in the “Also in force, editable under Advanced” line;
• allow rules, counted in the same line (“1 allow rule”). These are the free commands you list; see Free commands and the “don’t ask again” approval.

A name present in the policy and absent from the product’s catalogue, an external connector’s tool or a typo, is listed with the note “not in the product’s catalogue”, and can be restored.

The three lists match the three verdicts of the policy’s permissions field: exclude, ask and allow. A workstation cannot relax these rules: a command the policy does not free stays subject to the developer’s approval, and a removed tool stays removed. A tool’s name is the same on every surface; the full list is in the product’s shared catalogue.

Forbid a session rule

Other rules panel, collapsed Session rules section. Its title line states its state: “nothing forbidden”, or the list of forbidden rules (“remembered approvals, session export forbidden”).

Expanded, the section presents rules, each with a two-position field, Not restricted and Forbidden:

Rule on screen	Policy field	What Forbidden forbids on workstations
External connectors (MCP servers)	allowMcpServers	starting an external connector
Remembered approvals (“don’t ask again”)	allowRememberedGrants	skipping revalidation of a command already approved: the terminal’s “don’t ask again”, the editors’ “Automatic” setting
Session export	allowSessionExport	moving a session’s content out: transcript, artifact upload
Other organizations	allowOtherOrgs	working for an organization other than this one

Forbidden writes false in the document. Not restricted removes the field from the document, which is what an absent field means. An explicit true in force reads as Not restricted and is only rewritten if you touch the field.

Apply

As soon as the draft differs from the document in force, a bar appears at the bottom of the screen. It names the revision that will be installed and carries two buttons: Discard, which returns the draft to the document in force, and Apply changes.

The console proposes the revision name: v3 in force gives v4; nothing in force gives v1; a free-form name receives a counter, pilote gives pilote-2. The validity period is taken from the policy in force, or one day (86,400 seconds) by default. Both are changed under Advanced.

The installed document is the document in force with your modifications, every other field intact. The console does not reprint what it has not touched.

On installation, the screen shows In force from the next request: “Revision <nom> applies to every workstation of this organization from its next request.” The status line updates and the draft restarts from the document as read back.

A refusal appears under Nothing was installed, with the reason as the server wrote it, and the draft is kept:

Situation	Console response
the document is refused by the vocabulary (unknown field, invalid entry)	400, “This policy was refused and nothing was installed:” followed by the reason. An unknown field refuses the whole document
the revision is empty, or the validity is not a positive integer of seconds	400, with the field at fault
the console cannot establish who is acting	503, “This console cannot establish who is imposing this policy […]”; installation then goes through npm run install-organization-policy on the gateway
the gateway has announced nothing	503, “This console does not know which organization the gateway serves […]”
the audit record could not be written	503, nothing was installed

Every policy modification is logged, with the old and the new value and its author, which is the identity verified by your directory (security white paper V3, sections 5.1 and 7.2). A refusal is logged the same way. The auditor reads these records back; the Policy tab does not show them.

What stays in the JSON document

The collapsed Advanced section shows the whole document and allows editing it: Revision field, Validity, in seconds field, The policy, as JSON area, Install this document button. The document there is prefilled with the one in force. Text that is not JSON is refused before any call (“This document is not readable JSON: …”); a server refusal leaves the text in place.

Through this section, and only through it: pattern tool rules, allow rules and approved connectors (approvedConnectors).

A document produced by the lists on this page looks like this:

{
  "permissions": {
    "exclude": ["CreateRuleBlock"],
    "ask": ["Bash"]
  },
  "allowRememberedGrants": false
}

When the policy takes effect

The gateway evaluates the policy before every action, on the service side, so that a workstation cannot bypass it (security white paper V3, section 5.1). It reads the database back on every request: a tool removed, a command freed or a rule forbidden from the console applies to the next action, in a session already open, with no restart and no redeployment.

On a workstation, lemni policy shows the policy in force, its revision, and every governed setting with its value and its origin; see lemni policy.