Security threat model summary

This is the public summary of tawqi3’s threat model. The full version is internal; the parts customers, auditors, and security reviewers most commonly ask about are surfaced here.

Who we plan for

• External attackers scanning the open internet for surface area.
• Legitimate users of one tenant attempting to read or modify another tenant’s data.
• Compromised individual users whose credentials were phished, attempting to escalate within their own tenant.
• A single compromised piece of infrastructure, where one fault should not cascade into a platform-wide incident.
• Insiders with operator access, mitigated by mandatory multi-party approvals, cross-tenant audit, and immutable hash-chained audit logs.

What we do about it

Identity and access

• Modern, standards-based sign-in. Customers can use passwords plus multi-factor codes, hardware security keys (passkeys), or their existing single-sign-on identity provider.
• Per-user, per-resource authorisation. Every action is checked against the requesting user’s role and the resource being touched, on every request.
• Per-product entitlement. Cancelled or downgraded subscriptions stop relevant traffic at the perimeter immediately; there is no grace-period where access lingers.

Data protection

• Tenant isolation at every layer. Each tenant’s data is encrypted with keys distinct to that tenant, and isolation is enforced at both the authorisation and storage layers.
• Encrypted at rest. Document bytes, signature payloads, and audit records are encrypted with strong, modern algorithms before they hit disk.
• Encrypted in transit. All traffic between your browser and tawqi3, and between tawqi3’s internal components, is encrypted.
• Secrets are never logged. Credentials and key material do not appear in operator-visible logs, ever.

Audit and detection

• Hash-chained audit log. Every privileged action is recorded; each record cryptographically references the previous one, so any retroactive tampering is detectable on the next read.
• Per-tenant audit scope. Cross-tenant audit queries are syntactically impossible from an operator’s seat, by design.
• Per-event inclusion proofs. Signers can verify their record was committed to the agreement evidence bundle without trusting tawqi3.

Out of scope

• State-level adversaries with lawful-intercept capability are not part of our threat model. We aim for the GDPR, SOC 2, and ISO 27001 baseline, not for nation-state resistance.
• Endpoint compromise of the signer’s device. Once a signer’s browser or operating system is owned, no SaaS can save the session.
• Social engineering of tawqi3 employees is reduced (mandatory hardware-key multi-factor, no single-operator privileged actions) but not zero. The compensating control is the immutable audit log: insider misuse is detectable in retrospect.

Reporting

Disclose vulnerabilities through tawqi3.com/security. We do not run a paid bug bounty yet, but we acknowledge every valid report and credit researchers on the security page unless asked otherwise.

title: Security threat model summary description: A high-level summary of the threats tawqi3 takes seriously and the controls that mitigate them. category: Security updated: 2026-05-15 readMinutes: 8 order: 1

This is the public summary of tawqi3’s threat model. The full version lives in our internal documentation; this article exposes the parts customers, auditors, and security researchers most often ask about.

Threat actors we plan for

• External unauthenticated attacker: open-internet adversary scanning for surface area.
• External authenticated attacker: a legitimate user of one tenant attempting to read or modify another tenant’s data.
• Compromised low-privilege operator: a tenant member whose credentials were phished, attempting privilege escalation.
• Compromised infrastructure component: for example a single Kubernetes node or a single OpenFGA replica.
• Insider with operator access: a tawqi3 employee abusing legitimate access; mitigated by cross-tenant audit, mandatory operator-bypass approval flow, and immutable hash-chained audit logs.

Key controls

Identity and access

• OAuth 2.1 / OIDC PKCE at the front door. The IAM service implements RFC 6749, RFC 9068 (JWT access tokens), RFC 8705 (mTLS-bound tokens), RFC 9449 (DPoP), and per-client private_key_jwt enforcement for FAPI 2.0 baseline.
• WebAuthn / FIDO2 for hardware-backed authentication. Operators can register multiple passkeys and revoke individually.
• OpenFGA hybrid RBAC + ABAC at the per-resource gate. Every product surface translates a request into an OpenFGA Check before any business logic runs.
• Per-product entitlement claim on access tokens. The IAM service mints a tawqi3:entitlements claim that downstream daemons consult through the RequireProduct middleware, a cancelled subscription stops traffic at the edge.

Cryptography at rest

• Tenant DEK / KEK envelope via SoftHSM or YubiHSM. Document bytes and signature payloads are AES-256-GCM encrypted with a per-tenant data-encryption key; the DEK is wrapped by a per-tenant key-encryption key; the KEK is wrapped by a master KEK that lives inside the HSM.
• OpenBao (Vault fork) as the secret store and KMS substrate. Plaintext credentials never appear in Ansible logs (operator initialisation is deliberately manual).
• SeaweedFS holds the encrypted blobs with per-tenant key-prefix isolation enforced both at the IAM policy layer and the object key layer.

Cryptography in transit

• Internal CA mints per-service server/client/peer leaves; all backplane traffic terminates internal TLS.
• WireGuard mesh for inter-host traffic; no service is reachable outside the mesh except through the public Caddy ingress.
• Caddy + Anubis at the edge for HTTPS termination and bot mitigation; ACME-issued certs on the public surface.

Audit and detection

• Hash-chained audit log on every IAM, billing, and product mutation. Each record stores the previous record’s SHA-256 so any retroactive tampering is detectable in O(1) on read.
• Audit-bus consumer mirrors every record into the Loki + Tempo observability stack with WithTenantID propagation so cross-tenant audit queries are syntactically impossible from a tenant operator’s seat.
• Per-event Merkle proofs in the agreement evidence bundle let signers verify their record was committed without trusting tawqi3.

Out of scope

• State-level adversaries with lawful-intercept capability are not part of our threat model. We aim for the GDPR / SOC 2 / ISO 27001 baseline, not for nation-state resistance.
• Endpoint compromise of the signer’s device is not mitigated by us, once the signer’s browser or operating system is owned, no SaaS can save the session.
• Social engineering of tawqi3 employees is reduced (mandatory hardware-key MFA, no single-operator privileged actions) but not zero. The compensating control is the immutable audit log: an insider misuse is detectable in retrospect.

Reporting

Disclose vulnerabilities through tawqi3.com/security. We do not run a paid bug bounty yet, but we acknowledge every valid report and credit researchers on the security page unless asked otherwise.