Identity & Security#
An agent that IT cannot trust does not get a seat. Trust here is not a promise; it is the operating system's permission model, your own identity provider, and a record of everything.
Sign in with the identity you already have#
LIT does not have its own user database. Authentication is delegated to Keycloak, and Keycloak federates to whatever the organisation already runs:
- Active Directory / LDAP
- SAML 2.0 — Okta, OneLogin, Ping and the rest
- OpenID Connect — Google Workspace, Entra ID and other modern providers
- Social providers — GitHub, Google, Microsoft, for small teams
Users sign in once with corporate credentials; multi-factor and password policy stay where they are. A partner deploying LIT for a customer points the realm at the customer's IdP. The customer never creates a second set of accounts.
Roles come from your groups#
A team in LIT is a namespace with a guest list. Who is on the list, and what they may do, comes from the IdP:
| Role | Source | May |
|---|---|---|
| Member | realm role ns-{team}, or a group claim |
use the team's channels, agents and seats |
| Admin | adm-{team} |
edit policy, read the audit log, manage members |
| Owner | own-{team} |
everything an admin can, plus offboarding other owners and time-boxed transcript grants |
| Groups | the IdP's groups claim |
carry policy: model allow-lists, MCP allow-lists, budgets |
Policy is written against groups, never individual users, and deny wins. A person's first sign-in with an ns-{team} role creates their membership; nobody provisions accounts by hand.
In single-user mode the roles live in a local file and the box owner is the owner. Nothing else changes.
Agents run as you#
The API runs as a service account with no data of its own. Every operation on your behalf — reading a channel, running a tool, saving a session — is executed over SSH as your Linux user. Your agent's shell is your shell. It can read what you can read, write what you can write, and nothing more. There is no AI-specific permission layer and so no escalation path unique to agents; it is the permission model that already secures every server on the internet.
Consequences:
- Per-user storage. Your agents, sessions, credentials and MCP tokens live under your home directory (
~/.config/lit/), owned by you, unreadable by other members. - Audit ties to a real identity. Every action in the record names the Linux user it ran as, which is the SSO subject that signed in.
- Existing ACLs hold. Group-readable project directories are group-readable to the agent; private ones stay private.
- Excluded paths on top. Policy can forbid the agent from reading paths you can read (
~/.ssh, a secrets directory) — see Policy.
What leaves the machine#
Nothing goes to us. Sessions, channel history, memory, audit rows and usage ledgers are files on your server. Local models never leave the GPU they run on. The only thing that leaves is what you send to the model vendor you chose, under that vendor's terms — and the record shows exactly what that was.
Offboarding follows the IdP#
Disable an account in the IdP and, within minutes, LIT offboards the person: sign-in refused, heartbeats stopped, the team's credential removed, their channels and agents transferred to a named successor, and the leftovers archived after a set number of days. A legal hold keeps the source. Every step is an audit row.
The limitation this removes: an agent that knew a project's history used to walk out the door with the person. Now a successor inherits the channel. Details in Channels & the Record.
Audit#
Policy changes, refusals, kill-switch stops, transcript grants and offboarding are written by the service, not by the member's process, so the person they describe cannot edit them. Owners can open a time-boxed, reasoned window to read a member's transcripts; the member sees that the window exists. See Channels & the Record.
Single-user mode needs none of this#
LIT Desktop and lit serve in local mode run as you, for you. No Keycloak, no SSH, no roles. The same code, with the multi-tenant layer switched off. When one person becomes a team, the server adds identity without changing anything the person already had.