Security & compliance
For security & procurement reviewers

Built for teams
that answer to procurement.

The controls below describe how Streamwake is built and operated. They map to common security and compliance frameworks — SOC2 Trust Services Criteria, ISO 27001, and similar — without an external audit report attached. Written for the reviewer on the other side of the procurement thread. Send the unanswered questions to streamwake@polsia.app.

Current controls

What we run today.

Controls that ship in the product right now, not on a roadmap. Every claim below links to the surface that backs it.

Control

Per-request CSP with nonce + strict-dynamic

Every HTML response carries a fresh nonce on script-src and strict-dynamic, so no inline script ever reaches production. style-src deliberately keeps unsafe-inline because Radix poppers position via runtime inline style attributes that the CSP spec refuses to nonce.

Control

Paranoid defaults for framing and form posts

frame-ancestors 'none', object-src 'none', base-uri 'self', and form-action 'self' lock down the click-jacking and form-redirection surface area before any app-specific directive runs.

Control

Encrypted in transit and at rest

TLS 1.2+ everywhere and HSTS via upgrade-insecure-requests. Database encryption at rest is inherited from the managed Postgres service we run on; we do not store production data on developer laptops or unmanaged disks.

Control

Sessions, SSRF guards, and outbound probe hygiene

A 7-day session lifetime with a 24-hour rolling refresh keeps enterprise browsers signed in through long weekends without forcing daily re-auth. Every outbound probe is run through an SSRF guard that rejects private-network destinations before the request leaves the cluster.

Control

Logging and incident records

Agent run logs record what each autonomous action decided and why; the incidents timeline captures the post-incident write-up. Both surfaces are reachable from the authenticated operator dashboard and are retained for at least one year.

Identity & access

SSO/SAML and per-org RBAC are live.

Enterprise tenants can switch on single sign-on and per-organization role enforcement today. No upgrade gate, no procurement-tied wait.

Ready

SSO / SAML — ready today

Per-organization SSO/SAML is wired through /api/v1/account/idp/sso/start and /callback. Enterprise tenants can enable IdP-initiated or SP-initiated login from day one; we additionally resolve the right IdP from the typed email domain so an acme.com user lands at the Acme IdP automatically.

Ready

Per-organization RBAC

Members of an organization are assigned one of admin, operator, or viewer. The role enum and ordering are enforced at the zod and application layer (src/lib/business/account-roles/rbac.ts) and gate every per-org API route — admins manage members and integrations, operators run pipelines, viewers read.

Ready

Domain allowlist routing

A claimed email domain maps 1:1 to an organization. Anyone signing in from a mapped domain skips the personal-account path and is routed into the right tenant without manual provisioning.

Data handling

What we store, and where it goes.

Customer data stays inside the platform boundary. External vendors see only the minimum needed to deliver the service.

Practice

Personal data we store

Account email and password hash, organization name and member roster, OAuth session rows, and per-tenant stream/probe metadata. We do not store payment card numbers — Stripe-handled checkout is used for every transaction.

Practice

Customer data is not used to train external LLMs

Every model call goes through the Polsia AI proxy (@/lib/ai/client). OpenAI, Anthropic, and other vendor SDKs never appear in the application bundle and we never hold a vendor API key, so customer content cannot leak into external model training or fine-tuning corpora.

Practice

Payments never see card data

Checkout runs on Stripe-hosted pages. We redirect to Stripe; we never mount Stripe Elements in our UI, we never accept a card number on a Streamwake origin, and we do not hold STRIPE_SECRET_KEY in the runtime environment.

Practice

Data residency

A single managed Postgres region backs all customer data today. TODO — break out regions here if multi-region residency is offered.

Practice

On cancellation

Cancelling freezes the tenant; the account, all tenant data, and related backups are hard-deleted after a 30-day recovery window. The same 30-day window applies to free-trial accounts that never upgrade.

Subprocessors

Vendors we route customer data through.

Below are the categories of subprocessor in scope today. We notify customers at least 30 days before adding a new subprocessor that handles customer data.

Category
What it does
Vendor
Managed Postgres
Primary application database, encrypted at rest, automated backups.
Polsia-managed Postgres (TODO — name the managed Postgres vendor here)
Payments
Stripe-hosted checkout; we never see card numbers.
Stripe (via Polsia bridge)
AI inference
LLM calls for the autonomous agents; mediated by an authenticated proxy.
Polsia AI proxy (no vendor SDK in bundle)
Video ingestion CDN
Origin pull and edge delivery for ingested streams.
TODO — name the CDN provider here
Email
Transactional and compliance email (welcome, alerts, questionnaires).
TODO — name the email provider here
Security framework

Control coverage, not a status note.

The controls listed above — per-request CSP with nonce, TLS/HSTS, session lifetime, SSRF guards, SSO/SAML, RBAC, encrypted at rest, and hard-delete on cancellation — are the controls that would be evidenced in any third-party audit we run. Today, no third-party audit report is currently issued for the platform.

The controls listed on this page

Per-request CSP with nonce, TLS 1.2+ and HSTS, encrypted Postgres at rest, 7-day session lifetime with a 24-hour rolling refresh, SSRF guards on every outbound probe, SSO/SAML with domain routing, per-organization RBAC, and hard-delete on cancellation after a 30-day recovery window. These are the controls that would be evidenced in any third-party audit we run.

Maps to
  • SOC2 Trust Services Criteria·Common Criteria (CC1–CC9)
  • SOC2 Trust Services Criteria·Availability (A)
  • ISO 27001·Annex A — cryptographic & access control

No third-party audit report is currently issued

No SOC2 Type I, SOC2 Type II, ISO 27001 certification, or equivalent third-party audit report is currently issued for the platform. The controls themselves are in place; the external attestation is not. We will update this page if and when an external report is published.

Maps to
  • SOC2 Trust Services Criteria·Status note
  • ISO 27001·Status note
Incident response

When something goes wrong, we tell you.

A coordinated disclosure window for researchers and a clear notification path for customers. No security theatre.

Disclosure email
streamwake@polsia.app
Disclosure window
90-day coordinated disclosure window for vulnerabilities reported in good faith.
Customer notification SLA
TODO — confirm the notification SLA (e.g. notify within 72h of confirmed material incident).
Vulnerability disclosure policy
TODO — link to /legal/vulnerability-disclosure here if/when that page exists; today, mail streamwake@polsia.app.
Security FAQ

The questions
procurement teams send us.

Quick answers to the ones we hear most. Anything usefully specific goes to streamwake@polsia.app.

Still need answers?

Tell us what the
security team wants to see.

Send any open questions and we'll come back with evidence that fits.