---
title: Security, privacy and data
description: What Felspar stores and for how long, how workspaces are isolated, how access is checked and revoked, and where models are used.
sidebar:
  order: 1
---

This page is for the person reviewing Felspar for your company. It describes how the service behaves. It is not a certification: Felspar holds no security or compliance certification today, and nothing here is legal advice.

## Where it runs

The Felspar web app (`app.felspar.ai`), REST API (`api.felspar.ai`) and MCP server (`mcp.felspar.ai`) run as one service on Cloudflare's network. Data is held in a managed PostgreSQL database and in private object storage. Sign-in uses WorkOS AuthKit. Connected documents are read through WorkOS, with each person's own Google or Notion connection. The marketing site at `felspar.ai` is a separate site and holds no workspace data.

## Workspace isolation

Each customer has its own **workspace**. Every database query, cache entry and storage key takes its scope from the verified workspace of the caller, and the database enforces row-level security on every workspace table, so one workspace's rows can't be read in another's scope. The application's database role can't bypass row-level security. Scheduled jobs (source watching, cleanup) run once per workspace, and one workspace's failure doesn't affect another.

A session only selects a workspace; it never grants access by itself. Every request is checked against the person's live membership in that workspace and their grants.

## Who can do what

- **People** sign in with their own account. Roles are owner, approver and member. See [Roles and permissions](/guides/roles-and-permissions).
- **Agents** each get their own key, issued once and never shown again. An agent key can only read briefs, run decisions for its registered jobs, and verify its own receipts. It can never author, approve, release or read review material.
- **Assistants signed in as a person** (ChatGPT, Claude) get a narrower permission set than the web app: read, draft, check, propose and backtest. They can never approve, release, invite or manage agents, and can add a source only by reading a connected document with the person's own connection.
- **Approving and releasing** are always a person's explicit action in the web app, bound to the exact proposal they reviewed.
- Callers can't supply their own identity, actor or permission decision in any request.

## Access to documents

- Felspar reads Google Docs with the person's own connection and Google's narrow "files you pick" permission. It sees only Docs people choose in Google's picker.
- It asks for a fresh, short-lived token on every read and never stores or logs Google tokens. It never falls back to someone else's connection.
- Reading, proposing from, backtesting, approving and releasing anything built on a connected document require the current person's own access to that document, checked on each request. A refusal reveals only the provider and the kind of problem, never the document's title.
- Workspace roles grant no document access.
- Notion support is in beta and has weaker per-person checks: Notion keeps an integration's access to a page shared with it even if the person later loses access in Notion.

## Revocation

- **Agents:** revoking an agent refuses its very next call, over REST and MCP, and deletes its key. A revoked agent is never reactivated.
- **People:** removing a person or a role takes effect on their next request. Revoked grants are never restored automatically.
- **Releases:** retiring a release, or revoking anything in its chain, ends access to it at once.
- Revocations are recorded so that they survive a restore of the database from backup.

## What Felspar stores

| Data | Why | Kept for |
| --- | --- | --- |
| Source text (an exact version of a policy document) | Packs quote it; reviewers read it | 30 days if never released; while a release built on it serves, then 90 days |
| Proposals, approvals (with who approved and when), releases | The approval chain behind every decision | Same as above |
| Decision evidence: the excerpts agents send, with their sources | To replay decisions and verify receipts, and for backtests | 30 days from the first decision on the case |
| Classifications, results and receipts | Same | 30 days from the first decision on the case |
| Attempt records: question keys and source locators, never text | To enforce the attempt limit | 30 days |
| Classification cache: an answer keyed by a fingerprint of the request, never by text | Speed and cost | 30 days |
| Source watch records: version marker, revision, state | To detect changes | While the document is watched |
| Identities, grants, agent registrations and usage counters | Access control and limits | While the workspace exists |

Not stored: Google or Notion tokens; agent keys (only shown once at registration); backtest reports; the text read during a watch check. Expired data is removed by a daily cleanup.

Felspar doesn't store everything your agents see: only the excerpts they choose to send. Send the shortest passage that answers each question, and don't send data a decision doesn't need.

## Where models are used

Felspar uses a model in one place: to classify a text excerpt against the answers your released pack defines. It runs within Felspar's managed service, under Felspar's credentials, with per-job, per-workspace and per-caller ceilings. Classification only chooses among your policy's defined answers, and must clear the pack's threshold.

The decision itself, numbers and dates, rules, outcomes and receipt verification use no model. Felspar doesn't run your agents, generate content or take actions; those stay with your models and systems.

## Request handling

- All traffic is HTTPS.
- Browser writes are accepted only from the app's own origin; there is no cross-origin access to the API.
- Responses are never cached.
- Refusals name stable codes and field paths, never submitted values, source text or internals.
- Service logs record timings and counts, not request URLs, headers, keys or content.

## Integrity

- Every release has a digest, a fingerprint of its exact content, and is immutable.
- Every decision records the release and evidence it used, and its receipt can be replayed and checked at any time while the decision is retained.
- Source text is fingerprinted when it is added; every quote in a pack is located in that exact text.

## What a receipt is not

A receipt proves Felspar made a decision from given evidence under a given release. It doesn't prove the evidence was true, that the policy is lawful or compliant, or that an agent acted on it. Felspar governs only agents that call it.

## Contact

Security questions and reports: hello@felspar.ai.