Security

Last updated: April 13, 2026

Trust center

Overview

How Pulsar protects users, data and operations

This page explains how Pulsar protects authentication flows, APIs, database access, integrations and operational workflows. Controls are layered to reduce abuse, improve tenant isolation and strengthen recovery readiness.

Controls matrix

Layer	Controls	How	When	Why
Identity and authentication	Email verification, optional TOTP MFA, org-level MFA enforcement, invite token validation	Credentials, verification state and MFA challenges are validated before sessions are issued.	Sign-up, sign-in and step-up flows.	Reduce takeover risk and unauthorized access.
Session and browser protection	Signed HttpOnly JWT cookie, SameSite controls, same-origin checks, CSRF double-submit token	Authenticated requests validate session state. Mutating requests require origin and CSRF checks.	Every authenticated and state-changing request.	Reduce token theft and cross-site request forgery.
API route protection	Central route guard, payload validation, rate limiting, workspace checks	Routes validate request structure and identity before business logic executes.	At API ingress.	Stop malformed or abusive traffic early.
Authorization	Workspace membership checks and RBAC permission controls	Roles and membership are resolved server-side before protected operations run.	Before reads and writes.	Ensure least-privilege access.
Database isolation	Workspace scoping, organization scoping, Supabase/Postgres RLS policies	Queries are tenant-scoped and reinforced at the database layer.	At query execution.	Protect cross-tenant boundaries.
Secrets and credentials	AES-256-GCM encryption, hashed tokens, controlled reveal flows	Secrets are encrypted at rest and only decrypted in trusted server paths.	Storage and retrieval events.	Protect sensitive integration material.
Webhook boundary	HMAC verification, token validation, separate rate limits	Inbound callbacks validate authenticity before processing.	Immediately on receipt.	Reject spoofed provider traffic.
Observability	Audit records, delivery logs, alert pathways	Sensitive actions emit logs and operational signals.	During and after critical events.	Improve triage and recovery.

Lifecycle

1. Before access

Identity, invite requirements, credential validity and MFA requirements are checked before sessions are issued.

2. At request ingress

Protected routes enforce origin, CSRF and rate-limit checks before logic executes.

3. Before data operations

Workspace membership and RBAC permissions are resolved server-side.

4. At data access

Tenant-scoped queries and RLS policies reinforce isolation boundaries.

5. After changes

Operational and security-relevant events can emit logs, alerts and audit records.

Section

API and application security

Pulsar routes use centralized guard patterns to combine authentication, request validation, same-origin checks and CSRF controls for mutating requests.

Protected APIs require valid workspace context before application logic touches business data.

- HttpOnly cookie sessions

- CSRF double-submit token model

- Rate limiting at ingress

- Strict request schema validation

Section

Database and tenant isolation

Operational data is scoped by workspace and organization boundaries.

Supabase/Postgres row-level security policies reinforce server-side controls.

- Tenant scoped queries

- RLS enforced tables

- Service-role only paths where required

Section

Secrets, credentials and encryption

Integration secrets are encrypted with AES-256-GCM before storage.

One-time codes and token artifacts are stored as hashes where applicable.

- Versioned encrypted payload format

- Hashed verification artifacts

- Controlled reveal flows for sensitive actions

Section

Webhook and integration security

Inbound webhooks validate authenticity before processing provider payloads.

Separate controls are used for abuse resistance and debugging.

- HMAC verification

- Token-gated inbound routes

- Delivery logs and status traces

Section

Monitoring and incident response

Critical actions emit audit and operational records used for accountability and recovery workflows.

Alert pathways reduce time-to-detect and time-to-triage.

- Audit trails

- Operational notifications

- Failure visibility

Section

Shared responsibility model

Pulsar secures platform infrastructure, APIs and default control frameworks.

Workspace admins remain responsible for access governance, member lifecycle and least-privilege policy.

- Pulsar: platform controls

- Customer: permissions and access review

- Joint: incident coordination

Reporting

Security concerns and privacy requests

To report a security concern, contact info@pulsarspaces.com with reproduction details, timestamps and any request IDs you captured.

For privacy and personal-data requests, contact privacy@pulsarspaces.com.