Platform Security & Data Protection

1. Cryptographic Key Management & Data at Rest

Postlyn treats customer credentials as critical assets. We maintain a zero-plaintext policy for sensitive tokens:

• Authenticated Encryption: Social OAuth access tokens (Meta, LinkedIn, Pinterest) and user-supplied LLM API keys are encrypted using AES-256-GCM with unique initialization vectors (IV) and authentication tags.
• Key Segregation: Encryption keys are injected exclusively via secure server runtime environment variables, never hardcoded in client bundles or logged in telemetry.
• Database Encryption: Underlying PostgreSQL volumes run on encrypted storage partitions managed by container hypervisors.

2. Multi-Tenant Database Isolation

Postlyn operates on a strict multi-tenant SaaS architecture:

• Mandatory Workspace Scoping: Every database query initiated by tenant users executes through an automated middleware pipeline (`authenticate → resolveTenant → authorize → validate`) that injects the verified `workspaceId`.
• Channel Scoping: Within workspaces, scheduled posts, media files, and analytics are partitioned strictly by `socialAccountId`, preventing accidental cross-posting or metric pollution.
• Role-Based Access Control: Actions are gated server-side based on tenant roles (`WORKSPACE_ADMIN`, `CONTENT_MANAGER`, `AGENT`, `VIEWER`). Frontend visibility gates are purely cosmetic; authorization is verified on every API request.

3. Authentication, Cookie Security & CSRF Defense

We reject vulnerable client-storage token patterns:

• HttpOnly Cookie Isolation: JWT authentication tokens are stored exclusively in HttpOnly, SameSite cookies with the `Secure` flag enabled, making them inaccessible to JavaScript XSS attacks.
• Short-Lived Access Tokens: Access tokens expire after 15 minutes and rotate via a cryptographically bound refresh token stored in a separate secure cookie.
• Double-Submit CSRF Protection: All mutating requests (POST, PUT, PATCH, DELETE) require a cryptographically verified CSRF header matching the server token.

4. Universal AI Client & SSRF Hardening

Because Postlyn allows users to connect arbitrary OpenAI-compatible AI backends, our network egress layer implements strict Server-Side Request Forgery (SSRF) countermeasures:

• Private Range Blocking: Requests targeting loopback (`127.0.0.0/8`), link-local (`169.254.0.0/16`), and private RFC 1918 subnets (`10.0.0.0/8`, `172.16.0.0/12`, `192.168.0.0/16`) are immediately rejected.
• Protocol Whitelisting: Only `http` and `https` protocols are permitted; all system schemes (`file:`, `gopher:`, `ftp:`) are blocked.
• Redirect Suppression: HTTP redirects are disabled on outbound inference calls to prevent rebinding attacks.

5. Data in Transit & Infrastructure

All network communication with Postlyn occurs over TLS 1.3 encryption with strict HTTP Strict Transport Security (HSTS) headers enabled. Our production microservices run in isolated Docker containers deployed on managed cloud clusters with automated daily backups.