Deploy on-prem. Keep ticket data inside your boundary.
Help desk purchases stall in security review, and they stall on the same four questions: where the ticket data sits, which model reads it, whose directory issues the session, and who can read the audit trail. A hosted ticketing system answers all four with the vendor.
Latch Workflow answers them with your infrastructure. It runs on-premise, in your private cloud, or fully air-gapped. The ticket (or the case, if you work in a regulated function), the model that reads it, the identity that authorizes the action, and the audit trail that proves what happened all stay in one boundary you control.
This page is the technical detail a security reviewer asks for: tenancy, identity, where the model runs, encryption, and where the evidence is stored. If you are earlier than that and still working out whether a self-hosted ticketing system fits the way your team works, read that first and come back with the reviewer.
Your directory, not a second user list
Latch authenticates over OIDC against the identity provider you already run. Sessions, group membership, and deprovisioning stay there, so there is no parallel password store for a reviewer to inspect.
Role checks run at execution
Roles and permissions decide which operator can trigger which plugin action. The check runs when the action runs, not only when the button is drawn, and a denied attempt is recorded rather than hidden.
Tenancy holds at the data layer
Each tenant runs against its own database rather than a shared table and a filter that has to be correct on every query. Environments keep separate ticket data, identity scopes, and workflow permissions.
On-prem, private cloud, or air-gapped
Run Latch in a network with no egress. Data residency becomes a question of which rack or which region you installed it in, answerable by your own team without a vendor attestation.
Where the model runs, and what it sends
An AI feature in a hosted help desk means your tickets are the input to somebody else's inference endpoint, chosen by them, changed by them, and priced by them. That is the part a security reviewer cannot wave through, and it is the reason most regulated teams end up with an unassisted queue.
In Latch the model is a plugin like any other integration. The plugin declares what it can do; the platform applies permissions, approval gates, and audit logging around it. You choose the model and you choose where it runs.
Choose where inference happens
Point the model plugin at an open-weights model on your own GPUs, at a commercial API under your own key and contract, or at an in-house model behind an endpoint you control. In an air-gapped install only the local option is reachable.
Know what leaves the boundary
With a local model, nothing leaves. With a commercial API, only the ticket content scoped into that one call, under your contract with that provider. Latch sends no ticket text, no embeddings, and no usage telemetry back to Latch Workflow.
Keep the operator in front of the action
The model proposes a classification, a route, or a next step. The operator decides. The record shows which model proposed what, who accepted or corrected it, and what the downstream system returned.
The same boundary is what makes the queue improve without an export. Every triage call, approval, reject, and correction your operators make is training signal, and it is signal that stays in your install rather than becoming a vendor's dataset.
The evidence is stored where the ticket is stored
Audit trails have a habit of living somewhere the auditor cannot reach. A vendor log product, a retention window that expires, an export that has to be requested and then waited for. Evidence you have to ask permission to read is a weaker control than it looks on the compliance matrix.
In a self-hosted install the question of where the proof sits has one answer, and your DBA can confirm it without opening a support ticket. See what the audit trail records for the shape of the record itself.
Append-only rows in your database, in the same install as the ticket they describe. There is no separate logging product holding your evidence, and no retention window that expires on a schedule your team did not set.
Stored in object storage or on volumes you provision, encrypted at rest with keys your team holds and rotates. Deletion is your policy, applied on your schedule.
TLS between the browser, the API, and the database. In an air-gapped install that traffic never reaches your perimeter, let alone crosses it.
The ERP service account and the payment provider key live in your secret manager and are referenced by the plugin at execution time, not copied into ticket records where an operator could read them.
Running Latch on your own infrastructure moves real work onto your team: patching, backups, key rotation, certificate renewal, and the uptime of the box. Latch ships the migrations, the deploy tooling, and the upgrade notes. It does not run your servers. A five-person operations team with nobody to own that should take the managed deployment and keep the same approval and audit controls, knowing the boundary sits in a different place.
Follow the control path from intake to evidence
These pages work together: intake shapes the ticket, approvals gate sensitive actions, maker-checker enforces independence, security controls the deployment boundary, and auditability preserves the proof.
Enforce separation between the person preparing an action and the person approving it.
Route sensitive actions through role checks and approval gates before they run.
Keep decisions, blocked attempts, approvals, and action results on the same record.
Bring email, forms, alerts, and system events into one ticket queue before actions begin.
Questions security reviewers ask first
These are the questions that decide whether a faster queue is allowed anywhere near regulated work. Short answers here; your reviewer will want the deployment detail, and that conversation is worth having early.
Where does ticket data live?
Wherever you install Latch. On-premise, in your private cloud, or in an air-gapped network with no outbound route. Ticket data, attachments, the audit trail, and the identity session all sit in that one install, which makes data residency a property of where you deployed it rather than a clause about which region a vendor promises to use.
Which identity provider does Latch use?
Yours. Latch authenticates over OIDC against the directory your team already runs, so joiners, movers, and leavers are handled once, in the system that already owns them. Roles inside Latch map to groups you already maintain, and revoking access in the directory revokes it in the queue.
How does tenancy and environment isolation work?
Each tenant runs against its own database, not a shared table with a tenant column and a filter that has to be right every time. Production, staging, and per-customer environments keep separate ticket data, identity scopes, and workflow permissions, so a mistake in one cannot surface records from another.
Can Latch run with no internet access?
Yes. In an air-gapped install the model runs on hardware you own, plugins reach only the systems on your network, and there is no outbound call to Latch Workflow for licensing, telemetry, or inference. The isolation is enforced by your network, not by a setting someone can toggle.
Can we run our own model?
Yes, and regulated teams generally should. The model is a plugin: point it at an open-weights model on your own GPUs, at a commercial API with your own key and your own contract, or at an in-house model behind an endpoint you control. Swapping it is a configuration change, not a migration.
Does self-hosting mean our team runs everything?
Most of it. Latch ships migrations, deploy tooling, and upgrade notes; your team owns patching, backups, key rotation, and uptime. A team with nobody to own that should take the managed deployment instead, which keeps the same controls but moves the boundary.
See the queue, the gates, and the audit trail end to end
The walkthrough follows one ticket from intake through approval to the recorded outcome, on real screens. If your reviewer has a question it does not answer, send it over.