Each control below is shipping today unless explicitly marked otherwise. Where the implementation has a corresponding ADR or non-functional requirement, we cite it in the procurement docs we send on request.
// 01 - authentication
Tenant staff sign in with email and password held by the platform itself — no third-party identity provider in the login path. Passwords are stored as bcrypt hashes, logins are rate-limited per address and account, and responses never disclose whether an email exists. Sessions are short-lived signed tokens carried in httpOnly, Secure cookies.
Platform operators authenticate against a separate credential store and console host from tenant staff — operator logins cannot be minted through the tenant flow, and tenant sessions carry no operator scope. Deactivating an operator takes effect on their very next request, not at cookie expiry.
End users chatting with an agent never create platform accounts. Identity, where a workflow needs it, is a conversation-scoped one-time passcode over SMS or email, verified in-house and expiring with the conversation.
// 02 - authorization
Roles: admin, agent_builder, tenant_operator, compliance_reviewer, viewer, member. Every state-changing route is guarded by a require_role(...) dependency that reads the role from the request's organization-member lookup. Role changes write to the audit log.
Every tenant-owned Postgres table has Row-Level Security tied to a per-request tenant context. Every database connection uses a tenant-scoped role, so a bug in the application layer cannot return a different tenant's rows.
Embedding chunks live in per-tenant namespaces. The retrieval layer cannot construct a query that crosses the namespace boundary — even a buggy query returns nothing rather than cross-tenant chunks.
// 03 - cryptography + audit
A master key in a secret store derives per-tenant data keys via HKDF. Sensitive tenant data is encrypted with AES-GCM under the tenant's own data key. Tenant offboarding cryptographically shreds the key, not just the rows.
Every public endpoint is fronted by Traefik with certificates issued by Let's Encrypt via the DNS-01 challenge. Internal service-to-service traffic stays on a private Docker network; cross-service auth uses signed JWTs.
Every state-changing action writes to an append-only audit log. The tenant-scoped DB role has no DELETE permission on the table. Compliance reviewers can export a date-range archive of JSONL files with an Ed25519 signature over the manifest; the public key is published on the compliance keys endpoint.
// 04 - operational controls
Public demo tenants are labelled in the UI and on every API response. They live behind aggressive per-IP rate limits, cannot configure outbound tools, and are reset on a schedule. Production tenants are never co-located with demo data.
Operators can impersonate a tenant only with a documented reason and a JWT that expires in one hour. Every impersonated action lands in the tenant's audit log with actor_type=operator_impersonating. See the operator access page for the full policy.
Public state-changing endpoints accept an Idempotency-Key (UUID v4); the platform caches the response for 24 hours so a retried call cannot double-charge, double-send, or double-trigger a tool.
// responsible disclosure
We treat every report as in scope. Email security@primeassist.example with reproduction steps and impact. We acknowledge within one business day, triage within three, and credit researchers on a published roll when the vulnerability is resolved. We do not pursue legal action against good-faith research that respects tenant data and stays inside the rules below.
// next
The compliance page is the honest version of where we stand against SOC 2 — controls shipping, attestations pending.