Security.

At rest

• BYO AI provider keys (OpenAI, Anthropic, Google Gemini) and outbound webhook signing secrets are encrypted with AES-256-GCM. The encryption key is derived from a server-only root secret, namespaced per purpose so a compromise of any other ciphertext field doesn’t reduce to plaintext. We decrypt only at the moment we need to use the value (an AI call, an outbound webhook POST), never log the plaintext, and never expose it again in any API or UI response after the initial save.
• Application database (managed) is encrypted at rest by the provider with AES-256.
• Object storage for uploaded audio / video / transcripts is encrypted at rest by the storage provider.
• Session events are not individually encrypted in the database, treat them like any other application row that benefits from the at-rest-encryption guarantees above. Don’t put raw PII into custom event properties.

In transit

All connections to playloop.gg require TLS 1.2 or newer. SDK telemetry, webhook deliveries, AI provider calls, and Stripe API calls all use TLS.

AES-256-GCM is an authenticated cipher: tampering with a stored ciphertext invalidates the auth tag and decrypt fails loudly, we never silently surface a corrupted secret to the upstream provider.

AI provider relay

Our managed inference is routed through Vercel AI Gateway to the underlying provider over TLS; the Gateway returns the provider’s billed cost at zero markup so your usage tracks what the provider actually charged. Vercel AI Gateway is listed in the Privacy Policy sub-processor table.

Calls made with your own provider key go directly to the provider you chose over TLS and do notpass through our Gateway, so your key reaches only that provider and is never relayed through Playloop infrastructure. Any BYO spending cap is computed from the provider’s own usage figures.

End users

User authentication is handled by Clerk, an industry-standard identity provider. We never see or store passwords ourselves. Sessions are cookie-based, with CSRF mitigations enforced at the proxy / middleware layer.

Multi-factor authentication is available via Clerk and can be enabled from Settings → Account & security. Supported second factors:

• Authenticator app (TOTP), any standard authenticator (1Password, Authy, Google Authenticator, etc.).
• Text message (SMS), a one-time code texted to your phone at sign-in. Available in the US & Canada.
• Backup codes, one-time codes you print or save. Useful if you lose access to your authenticator.

You can register an authenticator and a printed backup-code sheet at the same time, whichever you have on hand is what the verification modal will accept.

Passkeys (Face ID / Touch ID / a security key / your phone) are supported for passwordless sign-in. Register one under Settings → Account & security and sign in without a password. Passkeys are phishing-resistant and never leave your device.

Re-verification on sensitive actions

A handful of mutations require you to re-prove presence with a fresh password or 2FA challenge, even if your session is already authenticated. The gate is a defense against a stolen session cookie being used to redirect data or hand over keys. It covers:

• Writing or removing a BYO AI provider key (OpenAI / Anthropic / Gemini).
• Rotating an ingest or management API key.
• Creating, repointing, or deleting an outbound webhook subscription.
• Changing your email address.
• Revoking another active session.
• Permanently deleting playtest sessions in bulk (the irreversible delete that also frees storage).
• Exporting your data archive.
• Closing your account.

Each successful re-verification covers one action only; chaining sensitive ops re-prompts each time.

API keys (workspace integrations)

We issue two scopes of API key:

• Ingest key, write-only, designed to ship inside game binaries. It can post telemetry events and nothing else. Cannot read sessions, delete data, or rotate other keys. If it leaks via decompilation, the impact is bounded to spam telemetry writes.
• Management key, server-side only. Full read, write, and admin access to your workspace. Never put this in a client build. Rotate it immediately from Settings if you suspect exposure.

Both scopes are hashed before storage. The plaintext key is shown to you exactly once at generation time. Each scope has its own rotation counter so rotations are independent.

Cross-tenant data leakage, one studio reading another studio’s playtest data, is the single failure mode that would be catastrophic for an analytics platform. We defend against it at two layers so a bug in one cannot breach the other.

Layer 1, Application code

Every authenticated request, whether it comes from a signed-in user, an API key, or a verified webhook, is tied to the studio it belongs to. Every database read and write is scoped to that studio, so your queries only ever reach your own data.

Layer 2, Database enforcement

The database enforces the same boundary independently, even on Playloop’s own connection. Each request runs as one specific studio, and the database returns only that studio’s rows.

If a bug ever slipped past the application checks, the database would still return nothing rather than another studio’s data, because Playloop connects with a restricted role that can’t bypass these rules. Two independent walls, so a flaw in one can’t breach the other.

Internal cross-tenant workflows

A small set of internal workflows legitimately operate across tenant boundaries, billing, scheduled digest generation, and account hygiene tasks. These run under a tightly controlled internal service context recognised by the authorization layer. Any user-specific fan-out work is then re-scoped into an individual tenant context so downstream writes and notifications still pass through normal tenant enforcement.

Stripe (inbound)

Stripe webhook deliveries are verified using Stripe’s standard signature header. We additionally maintain an idempotency table keyed on Stripe’s event.id so retried deliveries never apply twice, the same charge update can’t silently cycle a plan transition.

Outbound webhooks to customers

When you subscribe to a webhook event, we POST to your URL with an HMAC-SHA256 signature in X-Playloop-Signature. Use the secret returned at subscription-create time to verify the signature on your side, pure HMAC, no I/O required.

The URL you provide is also validated to prevent server-side request forgery (SSRF): we reject IP literals, private / link-local / loopback addresses, and re-validate the resolved IP at fetch time to defeat DNS-rebinding attacks.

Card data never reaches our servers. Stripe handles checkout, the Customer Portal, the card tokenization, the renewal cycle, and the PCI compliance scope. We store only the metadata Stripe returns (customer id, subscription id, status) so we can render your billing UI and grant entitlements.

We use Umami for product analytics, which we self-host alongside our own database. Umami does not set advertising cookies, does not share data with third parties, and anonymizes visitor IPs at ingest. See the Privacy Policy for what we capture.

Error monitoring (Sentry). We use Sentry to catch unhandled errors in the app. Visitor IP addresses are stripped from every event at the boundary before transmission, along with cookie, authorization, and other credential-bearing headers. Sentry’s session-replay feature is enabled only for sessions that hit an error; we never record sessions that don’t crash. Sentry is listed in the Privacy Policy sub-processor table.

Playloop’s admin / operations dashboard is reachable only over a private network, gated behind additional authentication. It is never exposed to the public internet. This is the right shape for a small team where a full SSO+VPN stack would be heavier than the value it adds.

All admin mutations (gifting a paid plan, adjusting credits, cancelling a gift) are recorded in an append-only audit log in our database. We use structured-JSON logging for security events (auth failures, rate-limit hits, signature failures, key rotations) so anything notable is queryable after the fact.

High-volume endpoints (SDK telemetry ingest, AI analysis, sign-up, billing actions) are rate-limited per API key and per IP. Limits are tuned to absorb burst behavior from a real game session while shedding obvious abuse traffic.

We also enforce per-plan ceilings so a compromised or spoofed account can’t exhaust shared infrastructure: hard storage caps, a per-import session cap, and a daily limit on how many sessions a workspace can submit for analysis. Each is scoped to the workspace and resets or holds independently.

• Account data and telemetry are scoped per-workspace at the query layer. Every API endpoint that reads or writes user data validates ownership against the authenticated session.
• Backups of the application database are managed by the hosting provider; snapshot windows are at least 7 days.
• Your plan’s retention window is the limit on how long we keep a session’s data (Free: 90 days, Indie: 180 days, Studio: 365 days). You can delete any game or session yourself at any time, and closing your account removes the underlying session rows together with their audio / video / transcript files in object storage rather than orphaning them. We are expanding this with automatic deletion at the end of each plan’s window. Bulk session delete defaults to a recoverable delete (hidden immediately, kept in cold storage briefly so support can restore on request); a permanent delete option removes the rows and their files at once and frees the storage. Single-session delete and account closure are always permanent.
• Security audit-log rows (sign-ins, key rotations, rate-limit and plan-cap hits, webhook failures, billing events, and other security-relevant actions) are retained 365 days on info-severity entries and 730 days on warning and error entries. Same retention regardless of plan. After account deletion the account’s identifier reference is nulled but a pseudonymized snapshot is kept under GDPR Art. 17(3)(e) (defense of legal claims).
• When you close your account we delete account data and cascade-delete all telemetry / insights / assets tied to it. See Privacy § 7 for the timing.

Being honest about what we have not done is part of a real security posture:

• SOC 2 / ISO 27001 / HIPAA. Not certified. We’ll pursue SOC 2 Type II once revenue justifies the cost of the audit (~$15-30k for a first-time SOC 2 Type II).
• Formal penetration test. Not yet conducted. We welcome responsible disclosure (see below).
• Paid bug bounty. We do not currently offer cash rewards for vulnerability reports. Researchers who responsibly disclose a valid security issue through responsible disclosure may be recognised on our security credits page (with their permission) after the issue has been resolved.
• 24/7 on-call rotation. We’re a small team. Incidents are responded to during waking hours; urgent issues should be marked as such in your email subject.

Found a security issue? security@playloop.gg

Reasonable expectations from us:

• Acknowledgement of your report within 72 hours.
• A target fix-or-mitigation date within 14 days for high-severity issues.
• Public credit on our security credits page (if you want it).

Please don’t test against another customer’s data or use automated scanners against the live service. Reach out first if you need a staging account.

Safe harbor. If you make a good-faith effort to follow this policy, we consider your security research authorised. We will not initiate legal action against you for activities conducted in accordance with this policy, and we will work with you to understand and remediate reported issues. If a third party raises concerns regarding research performed in compliance with this policy, we will make it known that the activity was conducted under our responsible disclosure program.

When we ship a material change to our security posture we’ll update this page and bump the Last updated date at the top.