Data handling and security

Hand this page to a security review. It sets out what leaves a machine running the client, what stays on it, how long each record is kept, and how access to the console is controlled.

OpenLatch controls a misbehaving agent: one that loops or spends budget on work nobody asked for, one that has been injected through its context and acts on it through its tools, and one that breaks a policy while otherwise behaving as designed. Those failures produce real incidents, and they are what the control loop catches before the action executes. OpenLatch does not claim resistance to an agent built to evade it.

Principles

Principle	What it means
The decision is made on the machine	Every verdict is computed on the machine, before the action runs. The console is not on the decision path
OpenLatch sits in no network path	The client is not a gateway and inspects none of your organization’s traffic. Your agents reach their model endpoints exactly as before
Least data	Values are masked and strings truncated before anything leaves the machine, and metadata is sent wherever content is not needed
No credential leaves the machine	The keys your agents use stay on the machine. Proxy passwords are held by the operating system, never in a configuration file and never in a log

Data inventory

Read the second column first.

Data element	Leaves the machine	Masking and limits	Where it is held	Retention
Action metadata (tool name, session, verdict, timing)	Yes	None applied. Metadata carries no free text	Console	180 days
Shell commands and tool arguments	Yes	Credentials masked with labelled placeholders. Each string capped at 4 KB	Console, and in hashed form in usage rollups	180 days; rollups 30 days
File paths	Yes	Masked the same way, and hashed with a per-organization key in usage rollups	Console, and in hashed form in usage rollups	180 days; rollups 30 days
File contents	Configurable	Filtered by default, or hash-only. Inline capture capped at 64 KB	Console	180 days
Prompts	Metadata only	Occurrence, timing, session and length. Prompt text is not sent unless your organization enables it	Console	180 days
Model requests and responses	No	Content is never sent. Token counts, the model used and the cache split are recorded	Console	90 days
User identity	Yes	Operating system user and git email, to attribute an action to a person	Console	180 days, with the record
Machine identity	Yes	Operating system, architecture, local and public IP address, software versions, an install ID	Console	180 days, with the record
Model account identifier	Yes	An account ID, or a marker showing that a shared key is in use. Never a token and never a key	Console	180 days, with the record
Policies	Downstream only	Sent to the machine, never uploaded from it	On the machine	Until a newer set replaces them
Verdicts and anomalies	Yes	None applied	Console	180 days

Figure 1. Data flow and trust boundaries: masked records go up, policies come down, and model traffic never passes through OpenLatch.

Masking, and what stays on the machine

Masking runs in the client, on the machine, before a record is queued for delivery. It walks the payload and replaces credential-shaped values with a labelled placeholder that keeps the recognizable public prefix and drops the secret, in the form [AWS_KEY:AKIA***]. Only string values are masked; field names never are. Masking runs before truncation, so cutting a string at the 4 KB cap cannot expose the tail of a partly masked secret. It runs after the verdict, so redacted text never changes which policies match. Your organization can add its own credential shapes to the client’s configuration, and they apply alongside the built-in ones.

Retention

Data	Window	Configurable	Export
Action records	180 days	No	—
Decision records and anomalies	180 days	No	CSV
Usage rollups	30 days	No	Console
Hashed archives	90 days	No	Console
Cost and token records	90 days	No	Console
Audit trail	90, 180, 365 or 730 days, or a custom window	Yes, with auto-purge	CSV or JSON

The audit trail is the one window you set yourself, in the console, with auto-purge; Configure the organization shows where. Every other window above is fixed. The policies held on the machine have no retention window: they are replaced when the client fetches a newer set, and removed when the client is uninstalled with --purge.

Hosting

The console is a service hosted in the United States, in the US-East region. Each organization’s data is kept apart from every other organization’s by the database itself: row-level security is enforced on every tenant table, with no runtime role that bypasses it. A list of subprocessors is available on request.

In transit, the client and the console speak TLS validated against the operating system trust store, with the option to trust an additional certificate authority where your estate terminates TLS with its own, and no option anywhere that disables verification. At rest, stored secrets are encrypted.

Identity and access

The console supports SAML 2.0 single sign-on per organization. You supply the identity provider’s entity ID, its sign-on URL, and a signing certificate or a metadata URL, then set the allowed email domains. A test runs the exchange and reports the result before the connection goes into service. Microsoft Entra ID, Okta, PingOne and Active Directory Federation Services connect this way.

Two gates control who joins. Allowed email domains restrict which addresses the console accepts at all, and invitations control who is admitted. A per-organization SAML connection is the only identity source that admits a member without an invitation, so a social sign-in is never a way around provisioning.

Role	What it can do
owner	Everything an admin can do, plus ownership of the organization itself
admin	Identity settings, policies, client credentials and retention settings
editor	Policies and agent ownership overrides
viewer	Read access to agents, executions, decisions and the audit trail. Invitees start here

A client credential inherits the role of the person who issued it. One issued by an editor cannot change an identity setting, and revoking the credential or demoting the person both close the same door.

The audit trail is append-only and hash-chained, so a removed or edited row breaks the chain. Every policy change writes a row naming the actor, with the state before and after. The trail exports as CSV or JSON, its retention window is configurable with auto-purge, and the export itself writes an audit event.

Protecting the client and its policies

Client updates are integrity-checked before anything is replaced: the SHA-512 digest of the download must match the digest the package registry publishes for that release. That check detects corruption and truncation; it does not protect against a compromised registry.

The policies held on the machine are checked before use, and again on every load, not only when they are fetched. A set that fails the check is discarded and reported, and the machine runs without policy until a newer set arrives. That state is stamped on every record rather than left silent, and the same holds where no policy has ever been fetched: the action is allowed and the record says why. OpenLatch never blocks an action because policy is missing.

Secret material is held by the operating system’s credential store where one is available, and otherwise in a file readable only by its owner. A credential passed on a command line is refused, because a command line is readable by other processes on the machine.

Product telemetry and crash reports

Product telemetry is about OpenLatch software, not about your organization’s agents. It carries command names, durations, the agent, error codes and volumes, and never command text, file paths, file contents or prompts. Consent is asked during installation, can be changed later, and is off by default in continuous integration. Crash reports carry a scrubbed failure message and nothing else, and are sent unless you turn them off.

Both travel to app.openlatch.ai with the traffic the client needs to run, so a network rule cannot stop them without cutting the client off from the console. The switches are on the client instead: decline telemetry at installation or run openlatch system telemetry disable, and turn crash reports off with OPENLATCH_CRASH_REPORTING=0. With them off, the client behaves exactly as it does with them on. Privacy and telemetry explains both in more detail.

Report a vulnerability

Send security reports to security@openlatch.ai. OpenLatch acknowledges a report within two business days and works the finding with the reporter from there.

In short

Action metadata, masked commands and file paths, verdicts and anomalies leave the machine. Prompt text stays on the machine unless your organization enables it, and model requests and responses are never sent.
One directory holds the configuration and the local records, in plain text, protected by the user’s file permissions and your disk encryption. Credentials are held by the operating system, or in an owner-only file.
Action and decision records are kept 180 days, usage rollups 30 days, hashed archives and cost records 90 days. The audit trail is the one window you set, with auto-purge, and it exports as CSV or JSON.
The console is hosted in the United States (US-East), with each organization’s data isolated by the database. SAML 2.0 per organization, four roles from owner to viewer, client credentials that inherit their issuer’s role, and an append-only, hash-chained audit trail.
Updates are integrity-checked before they are installed, and the policies on the machine are checked before use and on every load. A machine with no usable policy allows the action and says so on the record.