Security posture of the platform
This page describes how Osinet Command is built and operated from a security perspective. It is a product security overview — not a legal compliance certification or third-party audit report.
Role-based access control
Customer visibility scoping
Hardened sessions
Two-factor authentication
Redis rate limiting
Audit trail
Data isolation
Microsoft SSO
Role-based access control
Every API route and page enforces capability-based access. Capabilities are derived from roles at session verification time — not stored in the session token itself.
Full platform access including billing, user management, and all connector configuration.
All connector and customer operations; cannot manage billing or other admins.
Read access to all customers and connectors; cannot change configuration.
Read-only access scoped to explicitly assigned customers only.
Customer visibility scoping
Customer viewers are restricted to a specific set of assigned customers. Enforcement is layered — a bypass at one layer is caught by the next.
canSeeCustomer() filters the customer list before any connector data is fetched or rendered.
Snapshot GET routes verify customer assignment before returning connector data.
member_customer_access table persists customer assignments in Supabase. Survives cold restarts and session changes.
Sessions and authentication
Sessions are HMAC-signed, short-lived, and stored in hardened HttpOnly cookies. Deep session verification happens server-side on every protected request — the edge middleware performs a presence check only and is not the authoritative guard.
Session payload is signed server-side. Tampered tokens are rejected at deep-verify.
Sessions expire quickly. Stale sessions are rejected on re-verification.
HttpOnly, Secure, and SameSite flags set on the session cookie.
Signature, expiry, and org allowlist are re-checked on every protected server request.
Two-factor authentication
TOTP-based 2FA (authenticator app) is supported for all user accounts. Enrollment and verification infrastructure is fully implemented.
2FA enforcement (requiring all users in an org to enroll) is not currently enforced — the enforcement gate is disabled by design during early access. Individual users can opt-in.
Microsoft SSO provides a separate authentication path. Break-glass access via local credentials is preserved for recovery scenarios.
Rate limiting
Sensitive API routes are rate-limited using Redis-backed sliding window counters. Rate limiting is applied asynchronously and does not block the request path on Redis unavailability.
/api/auth/login/api/auth/register/api/auth/2fa/verify/api/connectors/*/sync/api/snapshots/*Audit logs and data handling
User logins, invites, role changes, and connector configuration events are written to Supabase.
Each connector sync records result status, org, and timestamp without storing raw API credentials.
Connector API keys and credentials are never written to log output. Log safety is enforced in sync routes.
Row-level security policies applied to sensitive tables where applicable, restricting direct data access.
Connector state is stored as org-scoped snapshots. Cold restarts do not clear data or expose stale cross-org state.
All Supabase queries are scoped by org ID. Cross-org data access is not possible through normal query paths.
This is a description of security controls built into the product. It is not a SOC 2 report, ISO 27001 certification, GDPR compliance statement, or legal attestation of any kind. For specific compliance or contractual security requirements, contact us directly.