Security posture

We ingest: AI-inference billing CSVs from your providers (OpenAI, Anthropic, Google, Bedrock, xAI, DeepSeek, Mistral, Cohere, Perplexity, OpenRouter, Azure OpenAI, Vertex AI, Together, Fireworks, Groq, Replicate) and seat-billing exports from dev-tool and workspace subscriptions (Cursor, GitHub Copilot, Windsurf, Cody, JetBrains AI, Tabnine, Claude.ai Team, ChatGPT Team, Gemini Workspace, Perplexity Enterprise, v0, Bolt, Lovable, Replit). Optionally, gateway and observability exports from Helicone, Langfuse, Portkey, LangSmith, Braintrust, PromptLayer, Arize.

We never ingest: end-user prompts or completions, source code, production credentials or API keys, end-user personal data, or any cross-site tracking signals. The Joint Baseline is computed from billing-line-item data and aggregate workload telemetry — not from the content of your AI workloads.

We never receive write-access to your inference endpoints. Tessera observes; clients decide and implement. This is a structural property of the engagement, not a policy we could be asked to relax.

Tessera client data lives in a single Supabase Postgres project (project ID tyqjsegyhwyrdbfcojaa, region us-east-1), with the operator and sponsor dashboard hosted on Vercel. Public landing at tesseraai.io uses no client data. Sentry telemetry routes to the EU region (de.sentry.io). PostHog product analytics, when a visitor has granted consent, routes to PostHog's regional infrastructure with all PII-shaped fields disabled.

The full subprocessor list with regions is in the Data Processing Agreement and in our Privacy Policy.

TLS 1.2 or higher in transit for every connection — public landing, dashboard, API routes, Supabase, Sentry, PostHog. AES-256 at rest via Supabase managed encryption for the Postgres database and storage buckets. Authentication tokens (Supabase Auth) are short-lived JWTs with refresh rotation; no plaintext passwords are stored.

Row-Level Security is enabled on every Tessera application table — twenty-eight tables as of the last security review. Three policy classes apply:

• · Operator (Tessera staff with a JWT email present in the operators table) — full read/write across every client, scoped by the application middleware.
• · Sponsor (client-side authorised contacts) — SELECT only on their own client's rows, plus UPDATE on their own recommendations (mark-as-implemented). No cross-client visibility, ever.
• · Anonymous — only public surfaces: Monthly Joint Reading retrieval by share_token on a specific reading row, the matching client row, and INSERT into diagnostic_applications. No other table is reachable.

Helper functions is_operator() and sponsor_client_ids() are SECURITY DEFINER with a locked search_path, to prevent RLS recursion from operator policies that themselves read the operators table. We caught a recursion bug with this pattern during end-to-end JWT simulation before the dashboard ever opened to a real sponsor.

Service-role keys are stored in Vercel encrypted env vars (never committed to git) and are scoped to server-side API routes only — the publishable anon key in the client bundle has no privileged access because RLS treats it as anonymous.

The Joint Baseline anchor and each Monthly Joint Reading are stored with the pricing-snapshot version identifiers in force at compute time (pricing_snapshot_version_ids JSONB on each row). Vendor pricing changes mid-contract do not retroactively alter the Performance Fee calculation. Corrections to a published reading are issued as superseding versions, not by overwriting; both versions remain queryable for audit.

Pricing-catalog rows themselves are append-only — price updates close the prior row's effective_to and insert a new row, preserving the full historical chain. The dashboard surfaces an Audit tab where the sponsor can see every state change on their data — every anchor ratification, every reading publication, every invoice issued — with operator identity and timestamp.

Sentry SDK is wired into both the public landing and the dashboard. Before any event leaves the browser or server, a beforeSend hook strips the Authorization and Cookie headers from breadcrumbs. Replays on the dashboard are maskAllText: true and blockAllMedia: true by default, so screenshots captured during error replays cannot leak the contents of CSV uploads or workload names. Sentry events tunnel through /monitoring (a same-origin proxy) so that browser ad-blockers and corporate firewalls don't drop them.

PostHog product analytics load only after a visitor grants explicit consent through the cookie banner. Until consent is given, no PostHog script is requested and no analytics events fire. The consent decision is stored in localStorage (tessera_analytics_consent) and can be revoked at any time by clearing site data.

We do not use Google Analytics, Facebook Pixel, advertising identifiers, or any cross-site tracking technology.

Tessera is a small practice. Access to Controller data is on a need-to-know basis under written confidentiality obligations, with two-factor authentication enforced on every administrative surface (Supabase admin, Vercel, Sentry, Cloudflare). We do not share credentials between team members. Departures trigger immediate revocation of all access on the same business day.

Supabase managed automated daily backups with seven-day point-in-time recovery. Joint Baseline anchors, Monthly Joint Readings, balance-transaction history, and invoices are retained for seven years per Estonian accounting law (Raamatupidamise seadus § 12), even after a Tessera account is closed. Raw workload-metadata snapshots and any optionally retained prompt logs are deleted within thirty days of account closure.

Honest framing first: we are not yet SOC 2 certified. Tessera is a young practice serving an initial cohort of Annual engagements. We do not pretend to controls we cannot continuously demonstrate.

SOC 2 Type II is in scope. We commit to completing a SOC 2 Type II audit covering the Optimize Layer (Cloudflare Worker proxy, dashboard, billing infrastructure) within twelve months of the first Annual signup processing a full billing cycle. The audit will examine controls across security, availability, processing integrity, confidentiality, and privacy. Auditor selection in Q3 2026, target attestation Q1 2027. We will announce the auditor and start date publicly in the Changelog rather than as marketing.

What we already operate under, today, as SOC 2 Type II preparation controls: a small and inventoried attack surface (one Postgres project, two Next.js apps, one Cloudflare Worker, documented subprocessors); Row-Level Security on every application table; encryption at rest and in transit; a written DPA that incorporates SCCs for non-EEA transfers; a 72-hour breach-notification commitment in Section 10 of the DPA; an immutable audit log on every $ figure; client-controlled kill-switch on the request path; access review and credential rotation on departure; and the full technical controls listed in the sections above.

For procurement teams that require a Type II report attestation before sign-off, write to contact@tesseraai.io — we can share interim controls evidence (architecture diagram, RLS policy matrix, subprocessor inventory, breach-response runbook) under NDA, and walk through our posture in a structured vendor-security review.

Responsible disclosure policy: /security/disclosure. For active incidents involving client data, write directly to privacy@tesseraai.io and we will respond within twenty-four hours.

If your procurement process requires a structured security questionnaire, write to contact@tesseraai.io with the questionnaire attached. We complete CAIQ and SIG-Lite forms directly rather than running you through a third-party trust portal we have not built. For short-form vendor security reviews, this page plus the DPA usually answers the standard B2B SaaS questions.