Use this page to answer the questions a deployment raises. Where another page treats a question in full, the answer points to it.
| Question | Answer |
|---|
| What do you need from us to start? | Three things: an organization in the console with one administrator who can invite everyone else, outbound HTTPS on 443 to app.openlatch.ai, and the perimeter, meaning which machines are in the first wave. The install scripts bring the client with them, so a machine needs no runtime of its own. Prerequisites turns that into a checklist |
| Does it need administrator rights on the machine? | No. The client installs and runs at user scope, loads no driver and opens no inbound port |
| Can we deploy it with our existing management tooling? | Yes. Because the client runs in user context, it is delivered as a user-scope script rather than a device-scope installer, with the credential passed from your secret store through the environment and never written into a script, a package or a command line. Create one key per rollout wave and revoke it when the wave completes. See Deploy the client |
| Which agents does it cover? | The install detects the agents present on a machine and wires each one it finds. Control levels lists the agents wired today, plane by plane. Every agent appears in the console with its control level, Enforced, Monitored or Known, which tells you how much control you have over it |
| Does the developer have to do anything? | Usually not. Some agents ask the developer to confirm the connection once, the first time they run after installation, and openlatch status shows which agents are still waiting. See Verify and roll out |
| Question | Answer |
|---|
| What does OpenLatch need to reach, and does it open anything? | One destination, outbound: app.openlatch.ai on TCP 443 over HTTPS, allowlisted by name because there is no static address range. Nothing inbound: the client listens only on the loopback interface. See Network requirements |
| Our only path out is an authenticated proxy. What is supported? | HTTP and HTTPS CONNECT, SOCKS5, transparent proxies, and PAC or WPAD where the operating system’s own resolver evaluates it. Basic and Kerberos (Negotiate) authentication are supported. NTLM is not, by design; Negotiate is the route on those estates. Proxy credentials live in the operating system’s credential store |
| Does TLS inspection break it? | No, provided the interception certificate authority is trusted. Install it in the operating system trust store, or point the client at it, in which case it is merged on top of the system store. Verification is never disabled, and OpenLatch issues no certificate of its own |
| Does our agents’ own traffic change? | No. Your agents reach their model endpoints exactly as before. Those endpoints must stay reachable and be exempt from response buffering and streaming inspection |
| What happens when a machine is offline, or the console is unreachable? | Policies stay in force on the machine, because the decision is made locally. Records are held on the machine and sent when the console is reachable again. See Architecture |
| Question | Answer |
|---|
| Is this a proxy or a gateway in front of our agents? | Neither. OpenLatch runs inside the agent’s own lifecycle, and the decision is made on the machine before the action runs. Nothing of ours sits in your network path, and OpenLatch terminates no TLS |
| What leaves the machine? Our prompts? Our source code? | Prompts are captured as metadata by default: that one occurred, when, in which session and how long it was. Prompt text is not sent unless your organization turns that on, and the requests and responses exchanged with a model are never sent to OpenLatch. What does leave is action metadata with credentials and file paths masked, plus the identity signals needed to attribute an action; file contents are filtered by default. OpenLatch connects to none of your repositories. See Data handling and security |
| Where is the console hosted? | In the United States, in the US-East region, with each organization’s data isolated from every other organization’s. Verdicts are produced on your own machines, so where records are stored does not affect enforcement. A list of subprocessors is available on request |
| Who can sign in to the console, and who can see what? | Single sign-on through SAML 2.0 is configured per organization, and access inside the console follows four roles. Every administrative change is written to an append-only audit trail that you can export. See Configure the organization |
| Can someone turn it off on their own machine? | OpenLatch addresses a misbehaving agent: one that loops, wastes budget, is injected and acts through its tools, or breaks a policy while otherwise working normally. The client installs in the user’s own scope, so a person with control of their machine can remove it. What that costs them is coverage, not secrecy: coverage is reported per machine, and a machine that stops reporting shows up as a gap rather than passing as covered |
| Question | Answer |
|---|
| Does it slow the agent down? | The decision is made on the machine, with no network call and no model on the path, so a covered action does not wait on a round trip. OpenLatch publishes no latency figure. Its claim is that every covered action reaches the policy decision point, and the verdict an explicit policy produced is the verdict that is enforced |
| How do we confirm a machine is really connected? | openlatch status reports whether the machine is connected, whether policies are present and whether the agents are wired, and openlatch doctor proves each of those. The machine’s agents then appear in the console’s agent record with an owner. See Verify and roll out |
| How do updates work, and can we pin them? | The client can update itself, and each download is integrity-checked before anything is replaced. Leave that on for installs a developer runs. A managed estate turns it off, keeps the check on, and delivers the new version in its own maintenance window. See Operate |
| How do we get notifications and records into our own tooling? | Notifications go to email, a chat channel such as Slack or Microsoft Teams, or a webhook you own, and the audit trail exports as CSV or JSON on the retention you set. See Set up notification channels |
| How do we remove it? | openlatch uninstall unwires the client from every agent on the machine and leaves each one as it was. Adding --purge also removes the local directory and the stored credential. See Operate |
| How do we open a support case? | Contact your OpenLatch technical lead through the channel agreed with your organization. Run openlatch doctor --rescue on the affected machine and attach the redacted archive it produces, with the operating system and the time of the problem with its time zone. Security reports go to security@openlatch.ai |
