Trust center
Your work,under your control.
How LiteSurface protects projects, keys, and decisions. We describe what the product does today and mark anything still in progress as planned.
01
Data ownershipProject-centric by design.
Your research, concepts, and decisions belong to you, organized so they can move as a unit. Nothing about how LiteSurface stores data ties your work to a single person’s account.
Projects are the unit of ownership
In productConcepts, sources, claims, evaluations, experiments, decisions, and artifacts all belong to a project. Transfer a project and the whole dataset moves with it.
Tenant scoping on every record
In productEvery tenant-owned row carries its workspace. Services resolve each entity to its workspace and check membership; an id in a URL is never enough.
Cross-tenant tests
In productAutomated tests seed two workspaces and attempt to read each other’s data through the API, so isolation is checked on every change.
Export and deletion
In productProjects can be exported. Deleted projects are purged, along with their stored files, 30 days after deletion.
02
Keys and providersYou decide who sees what.
LiteSurface does not resell model access. It calls providers with your keys, under your policy, and every provider involved is named on this page. See Governance for the admin controls.
Bring your own keys
In productEach workspace can connect its own OpenAI and Anthropic keys. Keys stay server-side: they are never returned to the browser and never placed in model context.
Allowed providers per workspace
In productAdmins choose which providers a workspace may use. Routing and failover respect that list, so content never reaches a provider you have excluded.
Only what the task needs
In productPrompts are assembled from the specific fields a task requires rather than whole projects. Application code refers to model aliases, never to vendors directly.
Log redaction
In productLogs automatically redact authorization headers, cookies, keys, secrets, tokens, prompts, raw model responses, and signed URLs.
Sample project and fixture mode
In productExplore a sample project before you run your own. Self-hosted deployments can also run in fixture mode, which replaces every model call with deterministic outputs.
Field-level sensitivity policy
In productFields classified as sensitive are never sent to model providers: they are removed before any prompt is assembled.
03
What goes whereEvery recipient, named.
The services that receive data when the product runs, what they receive, and when. The subprocessor list covers the companies behind them.
| Recipient | What it receives | When | Notes |
|---|---|---|---|
| OpenAI | Task prompts built from the fields a task needs, such as strategy, concept genomes, cited claims, and source text for extraction. Claim text for embeddings. | Tasks routed to OpenAI, including one of the two evaluations and embeddings for retrieval | Routing is configuration; failover follows your allowed-provider list. |
| Anthropic | Task prompts of the same kinds, built from the fields a task needs. | Tasks routed to Anthropic, including the other of the two evaluations | Evaluates independently; never sees the OpenAI evaluator’s answer. |
| Search provider | Search queries derived from the research focus. Not documents, claims, or concepts. | Research and evidence-gap runs | Tavily or Brave, as configured. |
| Public websites | Ordinary page requests for the sources being fetched. | When you add a URL, or a search result passes relevance triage | Fetched through the SSRF-safe fetcher; robots.txt is honored. |
| Email delivery | Recipient address and message content. | Sign-in, invitations, and notifications | Resend in production; a local mail catcher in development. |
| Object storage | Exports, artifacts, and stored files. | Artifact export, project export, attachments | Tenant-prefixed paths; downloads use short-lived signed URLs. |
Nothing is sent before you allow it
04
Encryption and application securityDefaults, not add-ons.
HTTPS everywhere
In productProduction traffic is served over TLS with HTTP Strict Transport Security, and insecure requests are upgraded.
Security headers
In productThe site and API send a Content Security Policy that denies framing, along with nosniff and a strict referrer policy. The site also sends a restrictive permissions policy.
Secure sessions
In productAuthentication uses secure, HTTP-only session cookies. Cross-origin requests are limited to the product’s own origins.
Encryption at rest, documented
PlannedA published description of at-rest encryption for the hosted service, including databases, object storage, and backups.
05
Access rolesLeast privilege, four levels.
Workspaces have four roles. Projects add their own owner, editor, and viewer roles for sharing individual projects. Permissions are checked in the service layer on every request.
| Capability | Owner | Admin | Member | Viewer |
|---|---|---|---|---|
| Read workspace content | Allowed | Allowed | Allowed | Allowed |
| Create and edit projects | Allowed | Allowed | Allowed | Not allowed |
| Run AI workflows | Allowed | Allowed | Allowed | Not allowed |
| Record decisions and outcomes | Allowed | Allowed | Allowed | Not allowed |
| View usage | Allowed | Allowed | Allowed | Not allowed |
| Manage members | Allowed | Allowed | Not allowed | Not allowed |
| Manage prompts and providers | Allowed | Allowed | Not allowed | Not allowed |
| Delete the workspace | Allowed | Not allowed | Not allowed | Not allowed |
06
Audit logWho did what, and when.
Consequential actions are written to an audit log with the actor and time, and admins review it in the separate admin console.
Recorded events include
- Membership changes, invitations, and role updates
- Project creation, duplication, transfer, and deletion
- Strategy and scorecard changes
- Portfolio decisions and experiment outcomes
- Workspace AI policy and budget changes
- Provider breaker resets and prompt activations
- Exports created and downloaded
07
Budgets and provider breakersSpend and failure, contained.
Budgets that stop runs
Each workspace has a spending budget. When it is exhausted, new runs are refused instead of overspending, and the usage ledger shows cost per project and run.
Provider circuit breakers
Repeated failures take a provider out of rotation. After a cooldown, a single probe call tests it before traffic returns. Admins can reset a breaker, and resets are audited.
Visible degradation
If one evaluator is unavailable, evaluation continues with the other and the result is marked partial, with lower confidence.
Prompt versions with rollback
Prompts are versioned assets. Admins activate or roll back a version, and every result records the prompt version that produced it.
08
Prompt injection defensesRetrieved pages are treated as data.
A research tool reads pages written by strangers, so it must assume some of them contain instructions aimed at the model. These defenses apply to every run, and a prompt-injection evaluation suite is part of the release checks.
A fixed trust order
System policy, then operator prompts, then the signed-in user, then project state, then retrieved content, then model output. Lower levels can never redefine higher ones.
Retrieved pages are data
Fetched content is wrapped and labeled as untrusted in every prompt. Instructions inside it are treated as text to analyze, never as commands.
Tool allowlists
Each AI task gets a fixed set of tools. Claim extraction has none, and no model is given arbitrary network access.
No secrets in context
Keys and credentials are never placed in model context, so there is nothing for an injected instruction to exfiltrate.
Validated citations
Model outputs are checked against schemas, and citations to claim ids that do not exist in the project are dropped.
SSRF-safe fetching
The fetcher blocks private, loopback, link-local, and cloud metadata addresses, re-validates every redirect, pins the resolved address, and caps size and time.
09
On the roadmapPlanned, not promised as shipped.
These items are not available today. We will record them in the changelog when they ship.
- SSO and SCIM provisioning for Enterprise workspacesPlanned
- Published at-rest encryption details for the hosted servicePlanned
- Data residency options for Enterprise deploymentsPlanned
10
Responsible disclosureTell us, and we will work with you.
If you believe you have found a security vulnerability, email security@litesurface.com with a description, steps to reproduce, and the impact you observed. We will acknowledge your report, keep you updated, and credit you if you wish.
While researching, please
- Only access data in accounts you own or have permission to use
- Avoid degrading the service, including denial-of-service testing
- Do not use social engineering or physical attacks
- Give us reasonable time to fix an issue before disclosing it
Security contact
For vulnerability reports and security questionnaires. Enterprise customers can request our security documentation and DPA.
11
PoliciesThe legal detail.
- Terms of ServiceThe agreement for using LiteSurface.
- Privacy PolicyWhat we collect, why, and your rights.
- Cookie PolicyCookies, browser storage, and visit counts.
- Acceptable Use PolicyWhat the service may not be used for.
- Data Processing AddendumProcessor terms for customer data.
- SubprocessorsThird parties that process data for us.
- AI DisclosureHow models are used, and their limits.
Questions about privacy? Write to privacy@litesurface.com
Review it first,then allow a provider.
Explore the sample project, read the provider disclosure, and allow OpenAI or Anthropic only when your review is done.
- Solo and Team are free during early access
- Explore a sample project first
- Bring your own OpenAI and Anthropic keys