Security at SAM

Identity and access

SAM uses Supabase Auth as a managed provider for sign-in, invitations, and account recovery; SAM does not implement password storage itself.

Protected API access is authorized on the server using database-backed roles, organization membership, and capabilities. Property access is scoped to the active organization; Sponsor access is additionally narrowed to assigned Contracts. Automated tests cover cross-organization boundaries.

Privileged administration uses separate platform roles, server-side gates, audited operations, and step-up checks for selected high-risk actions.

Administrative access to the provider consoles that host SAM requires multi-factor authentication.

Data protection

Production data is encrypted at rest by the managed database, authentication, and object-storage providers, and in transit with TLS.

SAM minimizes analytics collection and masks defined commercially sensitive and personal data from session replay.

Every service that stores SAM data runs in the EU today: database, authentication, file storage, backend, email delivery, product analytics and support mail. The web application itself is served from a global content delivery network, which sees the network metadata of each request. If your organisation has specific data-residency requirements, talk to us before signing.

Customer visibility

SAM makes a history of significant actions on your organization and contracts available for you to review.

Application and tenant security

Images and PDFs attached to Request Conversations are restricted by type and size, inspected for expected content and structure, stored under generated paths, and served through controlled access flows; PDFs are forced downloads.

The SAM API restricts browser access to the configured application origin and applies defensive response headers and rate limits. The application document sets MIME-sniffing, framing, referrer and permissions headers.

Unexpected API errors return generic details and a server-generated request identifier rather than an internal stack trace.

Secure development

Repository secrets are kept out of browser variables and checked with a dedicated Gitleaks CI workflow; runtime secrets are supplied through environment/provider stores.

Pull requests run code-quality, type, application, database, browser, backend-artifact, dependency-audit, and secret-scan checks.

SAM runs dependency audits in CI and blocks moderate-and-above advisories, subject to explicitly reviewed exceptions, and receives platform dependency alerts.

Monitoring and incident response

SAM uses structured server logs and request identifiers to correlate API failures while applying masking and data-handling rules.

External uptime monitors and provider/application alerts cover the production frontend and API.

SAM maintains a documented incident-response process for outages, suspected data exposure, and provider incidents.

Change control and environment separation

Production runs on its own database project, separate from staging, test and development. Changes reach it through a protected branch where history rewrites are blocked and contributors merge through pull requests, and pull-request jobs never receive production credentials. Request payloads are validated on the server before use, and database values are always passed as bound parameters.

Resilience

Customer records and user accounts are covered by our providers' backups. The database runs point-in-time recovery, and account data is included in the database provider's scheduled backups.

Security reports

If you believe you have found a security issue in SAM, email security@samplatform.io with a description, affected URL, reproduction steps, and any supporting evidence. Please do not include customer data that is not needed to explain the issue. We will acknowledge the report and coordinate next steps with you.