Security controls and
deployment details.

Data handling and security controls for the hosted service. Authentication, encryption, integrations, and backup configuration can differ on a self-hosted instance.

Deployment and security assessment: 26 August 2026. Documentation reorganized: 7 September 2026.

01

Data exchanged with your proxy and AI providers.

ConnectionData and credentials
Proxy syncReads logs, activity, and the key list using your LiteLLM credential. Logs contain prompts, responses, model, tokens, latency, and cost. Sync requires a credential that can read across proxy keys; its permissions are broader than one customer’s key. Sync itself uses read endpoints. A leaked credential can expose the proxy’s logs and key list.
Customer analysisSends the customer’s messages and workspace product notes to the configured provider. Automated retries and follow-up traffic are filtered before the analysis request. The configured personal or workspace provider key is used. Routing analysis through LiteLLM sends inference requests to your proxy using its token, and those requests appear in the proxy’s logs.
Aggregate analysisSends summarized findings across analyzed customers to produce the aggregate report.
AssistantRetrieves workspace conversations, analysis results, product context, and spend figures to answer questions. Retrieved content is sent to the assistant’s configured provider. Spend totals contain daily usage per key and model and can cover a longer period than conversation logs.
Connected AI clientsThe hosted service enables the remote API. Any approved member can connect an AI client and retrieve workspace conversation and spend data using their own authorization. Their client’s provider handles that retrieved content. There is no workspace-level switch to disable this path, and these reads are outside the request and AI-call audit logs.

Provider usage is billed to the configured provider account. LiteLedger’s own AI-call audit trail is not used as analysis input.

02

Membership, permissions, and server access.

Google authentication
Hosted sign-in uses Google OpenID Connect with authorization-code binding to the originating browser. Token validation checks the signature, expiry, audience, issuer, and nonce; the email address must be verified.
Account approval
A new account waits for approval unless its domain is on the auto-approve list. The platform admin approves the first account; workspace admins can then approve or deny same-domain accounts. Explicit denial takes precedence. A single-domain sign-in restriction can be configured at deployment time.
RoleScope
Workspace memberRead all synced conversations and reports in the workspace and run analyses. Data access is workspace-wide; there are no per-customer permissions.
Workspace adminMember permissions plus shared provider credentials, proxy settings, retention, audit-log viewing and export, and same-domain account approval.
Platform adminWorkspace-admin permissions plus deployment settings and platform administration. The three roles are fixed; custom roles are not supported.
Server operatorAdministrative access to the host permits reading stored conversation data. Workspace permissions apply to application access and do not isolate data from server administrators.

Workspaces are associated with email domains. Application data access is resolved through the signed-in account’s workspace. This is an application boundary, not a separate database for each customer.

03

Protection differs by data type.

DataProtection on the hosted service
Stored credentialsEncrypted with authenticated symmetric encryption. Altered ciphertext fails authentication.
AI-call audit bodiesPrompt, system-prompt, and response fields are encrypted before being written to the audit log. Audit metadata is not covered by this body encryption.
Synced conversation logsStored without application-layer encryption. Access is restricted by file permissions and the process sandbox.
Assistant threads and analysis cacheWorking copies of conversation and analysis text are stored without application-layer encryption.
Backup archivesThe archives are not encrypted. File permissions and object-storage access controls restrict access. Credential and audit-body fields remain encrypted inside the archive.
Key separation
The hosted encryption and session-signing keys are supplied from a privileged file outside the data directory and backup archive. The encryption key is loaded at startup. This separation does not protect against an administrator or process that already has access to the keys.

On self-hosted instances, credential and audit-body encryption depends on configuring the encryption key.

04

Audit coverage and deletion schedules.

Server-side AI calls
Customer-analysis and assistant calls record timestamp, model, input and output tokens, duration, status, errors, and the initiating account when available. Benchmark runs store metrics in their own run records. Client-side analysis does not create a server AI-call audit entry.
Request audit and export
The request log records state-changing API requests, including the account, time, and source address. Reads and remote API calls are not recorded, so this is not an audit of conversation viewing or export. Workspace admins can view and export audit records as newline-delimited JSON.
DataDeletion behavior
Synced conversationsUnlimited retention by default. Workspace admins can select a retention window; pruning removes conversation records older than that window.
Audit database rowsA daily sweep deletes audit and request-log rows and revoked-session records older than 90 days. This schedule does not apply to synced conversations.
Audit fallback filesIf database writes fail, audit rows are written to a file with the same encrypted body fields. These files are outside the automatic sweep and remain until an operator clears them.
Backup copiesThe hosted schedule keeps 14 daily, 8 weekly, and 6 monthly archives. Records deleted from live storage can remain in existing archives for about six months. Backup retention is configurable for self-hosted instances.
05

Browser and process protections.

HTTPS and browser policy
Browser traffic uses TLS 1.2 or 1.3, with automatic certificate renewal. A one-year HSTS header includes subdomains. The domain is not on the browser preload list; an initial HTTP request redirects to HTTPS.
Scripts, styles, and images
Runtime libraries are served from our own origin and maintained by us. The Content Security Policy also permits Google Tag Manager, Google Fonts, and analytics connections. Scripts permit unsafe-inline and unsafe-eval for the application’s browser template compiler. Images may load from any HTTPS host; framing is restricted to the same origin.
Request and output handling
State-changing browser API requests require matching same-origin headers when authentication is enabled. AI-generated Markdown is parsed and sanitized to remove dangerous elements and attributes before display.
Process and administration
The application runs as an unprivileged process in a systemd sandbox, listening on loopback behind a reverse proxy. Writable paths are limited to data, backup, metrics, and private temporary directories. Kernel tunables, modules, logs, and physical devices are restricted. Startup requires a platform admin when authentication is enabled.
Backup operations
Listing, running, and verifying backups use platform-admin endpoints. Restoring a backup requires a command on the server; there is no web restore endpoint.
06

Hosted location and assurance status.

ProviderRole
DreamHostHosts the application server, backup object storage, and outbound mail. The application server and backup storage are in the United States.
GoogleProvides hosted sign-in, tag management, analytics, and fonts.
External assurance
LiteLedger has no SOC 2 report, ISO certification, or external penetration-test report. The controls described here are internally documented.
07

Nightly backups and host recovery.

Backup location
The hosted service runs on one virtual server. Backups replicate nightly to DreamHost object storage in the United States.
Recovery after host loss
There is no standby instance for failover. Recovery requires restoring the latest nightly archive to a replacement server, with potential loss of up to a day of data.
08

Control scope in a compromise.

ScenarioControls and limits
Captured session cookieSigning out revokes that session’s server-checked identifier. Cookies use HttpOnly, SameSite=Lax, and Secure in production. Expiry is seven days without use, so continued use can extend a session. Admins cannot directly revoke another account’s session; denying account access prevents further authorized requests.
Leaked backup or diskCredentials and audit-body fields require the encryption key. Conversation logs and working copies have no application-layer encryption, and backup archives are unencrypted. Storage access controls do not encrypt data once it has been copied.
Cross-workspace accessApplication access is scoped to the authenticated workspace. This boundary has not undergone external penetration testing.
Compromised application processThe process sandbox restricts operating-system access. Data and keys available to the running application remain within the scope of a process compromise.
Dependency or tag-manager compromiseCompromised runtime dependencies or the allowed Google Tag Manager container can affect the dashboard.
Prompt injection in conversationsCustomer conversation text is model input and can contain instructions that influence analysis. The image policy permits external HTTPS images, so a crafted image URL in generated output can make a request to an attacker-controlled host.

Review the connection requirements.

Setup describes the proxy access needed to connect your workspace.