Security

Every inbound and outbound message passes through the Tork Govern L3/L6 pipeline before being stored or returned to the user. The pipeline detects and optionally redacts personally identifiable information including:

• Full name, email, phone number
• National ID / passport numbers
• Credit card and bank account numbers
• Home addresses and GPS coordinates
• Medical record identifiers

All data is encrypted at rest using AES-256-GCM and in transit using TLS 1.3. Encryption keys are rotated quarterly and managed via a dedicated key management service.

Tork Chat supports TOTP-based MFA (compatible with Google Authenticator, Authy, 1Password, etc.). Organisation admins can enforce MFA for all users on Pro+ plans.

Every significant action — login, configuration change, document upload, role change — is recorded in an append-only audit log accessible in the Admin Portal under Audit Log.

Governance decisions made through Tork Govern are recorded in governance_receipts. Each receipt carries a SHA-256 hash of the governed input and of the governed output, the hash of the preceding receipt, and an HMAC-SHA256 authentication code stored in the receipt's signature column — so the receipts form a continuous chain in which any altered or missing link is detectable. We state the primitive precisely: HMAC is a symmetric message authentication code, computed and checked with a key Tork holds. It evidences integrity to the key holder; on its own it is not third-party verifiable and provides no non-repudiation, and we do not claim otherwise.

Independent verification comes from the anchor, not the code above. The Merkle root committing a batch of receipts is published on Solana mainnet, on a public ledger that Tork does not control and cannot rewrite. Anyone holding the receipts in a batch can recompute that root and check it against the on-chain transaction — no Tork key, and no trust in Tork, required. That is the verifiable claim, and it is the stronger one: a chain whose commitment is public cannot be silently rewritten after the fact, whatever key Tork holds.

Chained receipts for Tork Chat went live in July 2026, and coverage is complete from that date. Measured on 20 August 2026: of the 473 governed Chat turns since 1 July 2026, all 473 are hash-chained and carry an HMAC-SHA256 code, and 467 (98.7%) are additionally anchored to Solana mainnet, where a Merkle root committing the batch is published on-chain. Every tenant with Chat traffic since July has complete receipt coverage.

API requests are rate-limited per tenant on a rolling 60-second window. Limits are enforced at the edge before any database or LLM call is made, protecting against abuse and runaway costs.

See API Reference → Rate limits for limits per plan.

Topic Guard prevents the chatbot from engaging with off-topic or harmful requests. Admins configure allowed and blocked topics in Widget Config → Topic Guard.

When a message is blocked, the API returns 451 Unavailable For Legal Reasons and the governance receipt records escalated: true.

The Tork Chat widget and Admin Portal are tested against WCAG 2.1 Level AA. Key compliance features:

• Keyboard navigation — full tab order, visible focus rings
• Screen reader support — ARIA labels, live regions for new messages
• Colour contrast — minimum 4.5:1 on all text
• Reduced motion — respects prefers-reduced-motion
• Touch targets — minimum 48 × 48 px on mobile

Tork Chat is hosted on Supabase (primary region: AWS ap-southeast-2, Sydney) and Vercel (edge network). Data at rest is stored in Sydney by default.