Architecture

Read this page to plan around what the client puts on a machine and what crosses the machine’s boundary.

What runs on the machine

Here, a machine means the operating system the agents run on. In most estates that is a developer workstation, and it is equally a virtual desktop, a build host or a container image, wherever an agent is started. If agents run there, the client is installed there.

OpenLatch installs one thing on such a machine: the OpenLatch client. It is installed once, and it covers every agent on that machine. There is nothing to place in front of the agent, no service to stand up beside it, and no second product to keep in step with the first.

Fact	Detail
What is installed	The OpenLatch client, once per operating system that runs agents
Privileges	Installs and runs at user scope. No administrator rights are required, at install or afterwards
Network posture	Listens only on the loopback interface. No inbound port is opened, and nothing on the machine is reachable from the network
Files	The client keeps its configuration and local records in one directory: ~/.openlatch on macOS and Linux, %APPDATA%\openlatch on Windows. OPENLATCH_DIR moves it
Startup	Starts with the user’s session, under the operating system’s own service manager
Where decisions happen	On the machine, before the action runs. The console is not on that path
Loss of connectivity	Keeps working. Policies stay in force, and records are held until the console is reachable again

Figure 1. Deployment view: the client on each machine, and the console as a service.

The console

The console is delivered as a service at app.openlatch.ai. There is nothing to install and nothing to host. Your organization’s data is stored separately from every other organization’s.

The console holds four things you work with: the organization, its users and their roles, the agent record and the audit trail. The agent record lists every connected machine and the agents found on it, each with an owner and a control level: Enforced, Monitored or Known. The audit trail is append-only and exportable, with a retention window you set. Configure the organization is the procedure for all of this.

Policies are authored in the console, and from there they reach each machine. Write an Agent Intent Policy covers authoring.

How an action is decided

One action produces one verdict, on the machine, before the action runs. The console is not on this path.

Step	What happens	What you can observe
1 · The agent offers the action	The agent is about to run a shell command or call a tool. It hands the proposed action to OpenLatch first, and waits	—
2 · OpenLatch decides on the machine	The decision is made against the policies the machine already holds. There is no network call and no model on this path	A verdict is reached whether or not the console is reachable
3 · The verdict returns to the agent	The verdict comes back in the form the agent understands, carrying its reason. Where several policies match, the most restrictive wins	On a Block, the developer sees the refusal and its reason in the agent, and the action does not run
4 · The result is recorded	The action and its verdict are written down on the machine and sent to the console afterwards. Sending is off the decision path, so a slow console changes when an action is seen, never what was decided	The machine, its agents and their decided actions appear in the console’s agent record

Figure 2. One action, one verdict: the decision is made on the machine before the action runs, and the record follows.

What crosses the machine’s boundary

Four flows cross the boundary of a machine running the client. Only two of them involve OpenLatch.

Flow	Direction and content
Policies	Down, from the console to the machine. The client checks at start-up and at regular intervals for policies newer than the ones it holds
Records	Up, from the machine to the console, over HTTPS and through your proxy, after the action has already been decided
Your agents’ model traffic	Unchanged. Your agents reach their model endpoints exactly as before, with their own credentials, and OpenLatch does not alter that traffic
Console sign-in	Into the console from a browser, through your identity provider

Network requirements lists every destination and covers proxies and TLS inspection.

When the network is unavailable

An unreachable console is a delivery problem, not an enforcement problem. The policies already on the machine stay in force, and the machine keeps deciding against them for as long as the outage lasts. Records that cannot be sent are held locally, up to a size cap, and go up when the console is reachable again. An outage long enough to pass the cap drops the oldest unsent records, and the client logs that it did.

Policies do not expire on their own. A policy that switched itself off after an outage would let anyone disable enforcement by unplugging a cable, so the machine keeps enforcing and the console shows that the machine’s policies have gone stale. A machine that has never received a policy allows the action and records that it had no policy: OpenLatch never blocks without policy. Network requirements carries the full table of degraded states.

Figure 3. Deciding unplugged: the machine keeps deciding with the policies it holds, and the records wait for the network.

In short

• One client per machine that runs an agent, at user scope, with no administrator rights. It listens only on loopback and opens no inbound port.
• It keeps its configuration and local records in one directory, ~/.openlatch or %APPDATA%\openlatch, which OPENLATCH_DIR moves.
• Actions are decided on the machine, before they run, against policies the machine already holds. No network call sits on that path.
• The console is a service, with nothing to install or host. It holds the organization, its users and roles, the agent record and the audit trail, and policies reach each machine from it.
• An unreachable console does not stop enforcement. Policies stay in force, records are held and sent later, and a machine with no policy allows the action and records why.