Connections
Data exchanged with your proxy and AI providers.
| Connection | Data and credentials |
|---|---|
| Proxy sync | Reads 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 analysis | Sends 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 analysis | Sends summarized findings across analyzed customers to produce the aggregate report. |
| Assistant | Retrieves 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 clients | The 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.
Identity & access
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.
| Role | Scope |
|---|---|
| Workspace member | Read all synced conversations and reports in the workspace and run analyses. Data access is workspace-wide; there are no per-customer permissions. |
| Workspace admin | Member permissions plus shared provider credentials, proxy settings, retention, audit-log viewing and export, and same-domain account approval. |
| Platform admin | Workspace-admin permissions plus deployment settings and platform administration. The three roles are fixed; custom roles are not supported. |
| Server operator | Administrative 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.
Storage
Protection differs by data type.
| Data | Protection on the hosted service |
|---|---|
| Stored credentials | Encrypted with authenticated symmetric encryption. Altered ciphertext fails authentication. |
| AI-call audit bodies | Prompt, 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 logs | Stored without application-layer encryption. Access is restricted by file permissions and the process sandbox. |
| Assistant threads and analysis cache | Working copies of conversation and analysis text are stored without application-layer encryption. |
| Backup archives | The 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.
Logging & retention
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.
| Data | Deletion behavior |
|---|---|
| Synced conversations | Unlimited retention by default. Workspace admins can select a retention window; pruning removes conversation records older than that window. |
| Audit database rows | A 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 files | If 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 copies | The 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. |
Application controls
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 and fonts are served from our own origin and maintained by us. The Content Security Policy also permits Google Tag Manager 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.
Service providers
Hosted location and assurance status.
| Provider | Role |
|---|---|
| DreamHost | Hosts the application server, backup object storage, and outbound mail. The application server and backup storage are in the United States. |
| Provides 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.
Availability
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.
Threat model
Control scope in a compromise.
| Scenario | Controls and limits |
|---|---|
| Captured session cookie | Signing 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 disk | Credentials 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 access | Application access is scoped to the authenticated workspace. This boundary has not undergone external penetration testing. |
| Compromised application process | The 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 compromise | Compromised runtime dependencies or the allowed Google Tag Manager container can affect the dashboard. |
| Prompt injection in conversations | Customer 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.