Built on the
principles we sell.

Security Philosophy

We treat customer data like a verified threat: assume hostile, validate everything, log it forever. Every privileged action passes through an authorization gate, gets audit-logged with SHA-256 hash chaining, and is reversible by design.

• Defensive only. Pythorix simulates attacks against assets you authorise. We don't generate exploit payloads for unauthorised targets, perform unauthorised intrusion, or modify production systems autonomously.
• Authorisation first. Every scan is bound to an actor, an organisation, and an explicit grant. Production-grade assets require ownership verification.
• Reversibility. All scans are read-only. No payload writes. No DELETE/PUT against unowned resources. Anything that mutates state requires human approval.
• Auditability. The platform's audit log is append-only and hash-chained. Tampering is detectable; revocation is durable.

Data Protection

What we store

• Your account: email, password hash (bcrypt, work factor 12), name, optional avatar
• Your assets: host, kind, environment, criticality, owner, tags, ownership-verification token
• Scan results: posture grade, finding details, evidence snapshots, OAST callback metadata
• Integration configuration: webhook URLs, API tokens (encrypted at rest)

What we never store

• Full HTTP response bodies from your assets — we keep evidence snippets bounded to ~5KB
• Payload secrets (passwords, tokens, PII) detected during a scan — these are flagged but redacted
• OAST callback content beyond the verification window

Encryption

• In transit: TLS 1.3 (TLS 1.2 minimum) on every public endpoint. HSTS preloaded.
• At rest: Postgres with provider-managed disk encryption. Integration secrets envelope-encrypted before persistence.
• JWTs: HS256 signed with rotated secret; 24h access token expiry.

Tenant isolation

Every Asset, Scan, Finding, Integration, API key, and Audit entry is scoped to an Organization. The X-Org-Id header pins your active workspace; cross-tenant access is rejected at the API layer regardless of role.

Platform Architecture

• Frontend: Next.js (server-rendered + static), CSP-locked, no third-party trackers in app pages
• Backend: FastAPI + Python 3.12, async I/O, multi-worker
• Datastore: Postgres 16 (with pgvector for embeddings), Redis for hot state
• Infrastructure: Containerised (Docker), declarative deploys, immutable images
• Network egress: outbound HTTP via the Pythorix scanner identity (Pythorix-IntelOps/1.0 (+defensive)) — never spoofed
• Security headers on every response: HSTS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, CSP for HTML
• Self-scan: Pythorix runs Pythorix against itself. Yes, really.

Access Control

• RBAC: 5 organisation roles (Owner, Admin, Security, Developer, Viewer) + global Admin
• MFA: Email signup requires OTP verification; Google sign-in inherits Google's MFA
• Session revocation: Logout terminates the server-side session row immediately
• API keys: bcrypt-hashed, prefix-only display, scoped, expirable, revocable
• SSO/SAML: Enterprise tier (request via contact)

Responsible Disclosure

Security researchers — please review our Responsible Disclosure Policy before testing the Pythorix platform. We coordinate with finders, don't pursue good-faith researchers, and credit those who help us improve.

Compliance

Pythorix is built to assist your compliance posture. Every Verified Threat Intelligence Report includes mapping to PCI DSS 4.0, ISO 27001:2022, SOC 2, GDPR, NIST CSF 2.0, OWASP Top 10, OWASP API Top 10, and OWASP LLM Top 10. We are working toward formal SOC 2 Type II attestation; status updates available via contact.

Subprocessors

Current third-party services that process customer data:

• Cloud hosting (containerised compute + managed Postgres)
• Email delivery (transactional OTP and welcome emails — see configured SMTP provider)
• Optional: Stripe for billing (only when paid plan is active)
• Optional: Google OAuth (only when user signs in via Google)

Incident Response

We follow a structured incident-response runbook with clear severity tiers. Customers affected by a confirmed security incident are notified within 72 hours. Our public Trust Center will host post-incident write-ups for any incident that materially affected customer data.

Contact

Security questions: contact our security team. For anything time-sensitive, mark your message SECURITY and we'll route it appropriately.