Workspace gated
Access control
Enterprise workspaces are permissioned by organization. Admin and privileged workflows route through authenticated server handlers, not public browser secrets.
Security
Security posture buyers can review before paid enterprise access.
This page documents route-level hardening, database-isolation design, server-only privileged keys, incident handling, and the evidence a buyer should request. It does not certify a specific deployment or customer configuration.
- Hosting
- Vercel
- Next.js production deployment
- Database
- Supabase
- migration and isolation evidence reviewed per release
- Checks
- Per release
- request dated advisor and runtime results
Security scope
Controls buyers usually ask for first
These controls describe implemented product and configuration scope. Current runtime posture requires release-bound evidence. Final legal commitments belong in the MSA, DPA, order form, and SLA.
Evidence per release
RLS enforcement
RLS policies are present in the public and enterprise migration source. Current release review requires migration receipts, dated advisor output, and runtime tenant-isolation evidence.
Server-side
Secret hygiene
Service-role keys, cron secrets, provisioning secrets, and integration encryption keys are expected only in server/runtime environments.
Configured
Transport security
The hosting and response configuration defines HTTPS delivery, HSTS, frame protections, content-type protections, and a restrictive frame-ancestors policy. Verify headers on the exact deployment under review.
Source classified
Route security inventory
Source checks classify admin, cron, secret, callback, public, and session-scoped flows so risky endpoints stay visible. Classification is not runtime authorization or durable-event proof.
Execution limits
Data export and deletion scope
Scoped operational exports and owner-only deletion previews are available. Tenant deletion execution and its worker are hard-disabled pending complete erasure certification. Privacy requests require a manual scope and timeline review.
Controls in detail
What is implemented, and where the limits are
One canonical list for security questionnaires, covering both tokensand.com and the enterprise workspace. We handle customer-generated developer data — emails, usage events, attribution signals. Each statement describes repository-visible controls and stated programs and names its limit; it is not certification of the exact deployment, provider configuration, or customer environment, and anything marked limited must not be treated as a contractual commitment.
Tenant isolation
Tenant-scoped data paths use organization identifiers and database policies where the release migrations define them.
- Implemented · verify per release
Row-level security for listed tenant tables
Repository migrations define organization-scoped policies for developer_profiles, normalized_events, accounts, recommendations, attribution_results, and audit_log. Static policy presence does not prove deployment state or every credential path; release certification requires cross-tenant denial tests against the exact database.
- Implemented · verify per release
API key scoped to one organization
Ingestion API key records use a SHA-256 hash and non-secret prefix, and accepted source paths bind the key to an organization and product. Release-bound negative runtime tests are required before treating that source design as deployed enforcement.
- Implemented · verify per release
Service role trust boundary
The service role is intended for server-only handlers and jobs and remains a privileged trust boundary. Exact deployment secret exposure and privileged-path coverage require build and runtime verification.
Encryption in transit and at rest
Provider-managed transport and storage controls; exact deployment and provider configuration evidence is required.
- Implemented · verify per release
Public HTTPS deployment target
Vercel supports HTTPS for deployed endpoints. This repository does not prove the negotiated protocol, HSTS state, or certificate handling for an exact public deployment or its internal Supabase connection; collect current deployment and provider evidence.
- Implemented · verify per release
Provider-managed encryption at rest
Database and backup encryption depend on the active Supabase project, plan, and provider configuration. The repository does not establish a separate backup KMS key; obtain current provider evidence before making an algorithm or key-management claim.
- Implemented · verify per release
Credential storage depends on secret type
API key records use one-way hashes. Webhook and integration credentials are encrypted with the server-side integration key because the runtime must recover them to sign or authenticate outbound requests; legacy webhook fields require migration and release verification.
- Implemented · verify per release
Signed outbound webhooks
Outbound webhooks leave a durable outbox with bounded retries and dead-lettering, carry an HMAC-SHA256 x-webhook-signature header when a signing secret is configured, and are delivered only to public HTTPS destinations; private-network targets and redirects are refused. Receivers should verify the signature and de-duplicate on the delivery id.
- Limited · not a commitment
Security headers and content security policy
Both hosts send HSTS (with preload), X-Frame-Options DENY, nosniff, a strict referrer policy and a Permissions-Policy. The marketing host enforces a Content-Security-Policy; the enterprise host currently sends its policy in report-only mode while it is tuned, so it should not be described as enforced until that changes.
Audit logging
Tenant-scoped records for supported security-relevant actions, visible to authorized admins.
- Implemented · verify per release
Restricted audit table
The audit_log schema stores actor, action, resource, IP address, and timestamp. Ordinary tenant policies expose no update or delete path, while the service role remains privileged. Implemented call sites cover selected actions, but source classification does not prove every mutation records successfully at runtime.
- Implemented · verify per release
Customer-visible admin UI
The audit UI and API provide organization-scoped viewing and filtering for authorized roles. Exact release authorization and cross-tenant denial still require runtime verification.
- Implemented · verify per release
Retention & export
The tenant archive source includes selected audit-log fields and excludes IP address and user agent. No indefinite retention period is claimed; contract and deployment evidence must define the applicable retention and deletion behavior.
AI governance
Controls for agent context, model access, approvals, and runtime observability.
- Implemented · verify per release
External-model policy setting
The governance policy includes an external-model setting. The current synchronous planner returns deterministic plans and records external_llm_used=false; any provider-enabled path requires separate release-bound data-flow verification.
- Implemented · verify per release
Agent-context redaction
The default strict policy redacts enumerated sensitive fields and email patterns from agent context and records a redaction summary. Coverage is key- and pattern-based, so every outbound provider path needs adversarial release testing before broader PII claims.
- Implemented · verify per release
Agent approvals and budgets
Agent plans mark external actions as approval-gated, and policy fields set daily run and token limits. Those controls do not guarantee an audit event for every execution; verify approval, budget, and audit failure paths against the exact release.
Data rights (GDPR, CCPA)
Owners can request a scoped export and inspect a deletion preview. Automated tenant deletion is unavailable; contact privacy support to review a data request.
- Limited · not a commitment
Scoped owner JSON export
The owner workflow can request a privacy-filtered subset from Settings → Data & privacy. It excludes selected secrets, request metadata, survey responses, feedback contacts and bodies, SCIM mappings, and agent conversations/tool payloads; it is not certified as a complete Article 20 portability response.
- Limited · not a commitment
Tenant deletion — execution unavailable
Tenant deletion and its worker are hard-disabled; no environment flag enables them. A complete erasure process covering authentication, storage, in-flight work, shared-service records, retained receipts, and backups must be certified before automated deletion can be offered.
- Limited · not a commitment
Data subject requests for specific developers
No per-developer self-serve endpoint is implemented. Contact privacy@tokensand.app with the relevant identifier to review scope, applicable requirements, and the response timeline.
- Limited · not a commitment
Data Processing Addendum (DPA)
Draft DPA summary for procurement review. Customer-specific processing, transfer and retention terms require legal review.
Access control
Source-defined roles, credential scoping, and provider-managed sessions; release verification is required.
- Implemented · verify per release
Role-based access (owner, admin, analyst, viewer)
The role model defines owner, admin, analyst, and viewer permissions, and privileged source paths use access helpers. Full API enforcement is a release-bound coverage claim and requires positive and negative runtime authorization tests.
- Implemented · verify per release
Provider-managed session tokens
Supabase Auth controls JWT expiry and refresh behavior. Sign-out clears the application session, but the repository does not prove that every previously issued JWT is invalidated immediately; certify provider configuration and revocation behavior for the release.
- Limited · not a commitment
SAML single sign-on
SAML sign-in routes through Supabase Auth after identity-provider configuration and a verified test login. Mandatory SSO enforcement is not implemented in the current application; review alternative sign-in and session requirements before contracting.
- Limited · not a commitment
SCIM 2.0 provisioning (analyst and viewer roles)
Owner-issued SCIM bearer tokens (stored as SHA-256 hashes, with a bounded expiry) let an identity provider create, update and deactivate users in the analyst and viewer roles; owners and admins are managed in the application. User DELETE and group-membership push are not implemented, and deactivation is enforced by the application on the next request rather than by immediate token revocation.
Infrastructure & reliability
Deployment targets and provider capabilities; active controls require exact-project evidence.
- Implemented · verify per release
Vercel + Supabase deployment target
Repository configuration targets Vercel for the application and Supabase for database, auth, and storage; verify exact project bindings and enabled controls for the release. Supabase handles Postgres, auth, and storage in SOC 2 Type II certified environments.
- Implemented · verify per release
Managed backup capability
Backup cadence, encryption, point-in-time recovery, and retention depend on the active Supabase plan and project configuration. Repository contents do not prove those settings; obtain current provider evidence and perform a release-bound restore test.
- Limited · not a commitment
Global edge delivery with region pinning on request
Request the current hosting, database, backup, log, and AI-provider locations during procurement. Region pinning and residency requirements need an approved implementation scope and verified provider configuration before they can be committed.
Security program
How we operate, test, and respond.
- Limited · not a commitment
SOC 2 report and readiness review
Request current audit status and available control evidence during security review. This page does not establish an audit engagement, completion date, or SOC 2 certification; any report must be reviewed for its actual scope and period.
- Implemented · verify per release
Dependency and vulnerability scanning
Repository CI runs npm audit for pull requests and pushes to main. A current successful workflow run—not this static page—is the evidence that the configured threshold passed for a particular release.
- Implemented · verify per release
Incident response
Report suspected incidents to security@tokensand.app. Support coverage, escalation contacts, and notification commitments must be confirmed in the applicable enterprise agreement; this page does not establish 24/7 staffing.
- Implemented · verify per release
Responsible disclosure
Security researchers should email security@tokensand.app with findings. We acknowledge within 2 business days and do not pursue legal action for good-faith research.
Contacts
- Security & breach disclosure: security@tokensand.app
- Privacy & data subject requests: privacy@tokensand.app
- Procurement, DPA drafts, subprocessor categories and review requests: Trust Center
Incident response
Operational response model
Enterprise buyers will ask what happens when something goes wrong. This is the response model the team can operationalize.
- 1
Triage
Classify customer impact, affected systems, severity, and whether credentials or customer data may be involved.
- 2
Contain
Disable affected cron, API, or integration paths; rotate keys; pause exports or webhooks if needed.
- 3
Recover
Deploy the fix, verify production checks, inspect logs, and replay safe queued work from durable sources.
- 4
Notify
Provide customer-facing status, timeline, impact, remediation, and follow-up actions under the contract notice process.
Buyer-safe claims
Security claim guardrails
These keep revenue, product, and the website aligned with what can safely be represented today.
- Do not put Supabase service-role keys in NEXT_PUBLIC variables.
- Do not promise SOC 2, HIPAA, or ISO certification unless the current artifact exists.
- Do not expose private account intelligence in public proof pages or share cards.
- Do not replay enterprise migrations into the public schema; enterprise data lives in the enterprise schema.
- Do not run destructive database rollback actions without a recovery source and explicit approval.
- Do not treat sample reports as verified live evidence unless the source data is labeled.
Security questionnaire
Answer from this page plus the enterprise packet; route edge cases to commercial review.
Escalation
Contract should name severity levels, response targets, and notification contacts.
Residual risk
Custom domain, signed legal documents, and contract-specific SLA are still business operations, not code.
Start security review with current evidence.
The public materials define the review scope. Dated release evidence and final customer commitments must be supplied through the enterprise review and order form.