Trust Center
Security, Privacy & Compliance at Tork
Security Overview
Encryption
- TLS for all data in transit (terminated at the Vercel edge)
- Encryption at rest managed by Supabase on AWS
- API keys validated only against SHA-256 hashes
Infrastructure
- Providers (Vercel, Supabase) publish their own SOC 2 Type II reports
- Redundancy and failover managed by those providers
- DDoS mitigation at the Vercel edge
Access Controls
- Role-based access: organisation roles and a 5-tier staff role model
- Org-scoped, revocable API keys; hash-only validation
- Audit logging of account and administrative actions
Monitoring
- Uptime and error monitoring (Better Stack)
- Per-call behavioural anomaly scoring (ARCH-07 baseline)
- Dependency vulnerability scanning on every push, plus a nightly security suite
Compliance Status
POPIA
AddressedSouth African Protection of Personal Information Act rights are handled as set out in our Privacy Policy
Privacy PolicySOC 2 Type II
Not certifiedTork holds no SOC 2 report. Controls designed to align with SOC 2 Type II.
View controlsISO 27001
Not certifiedTork holds no ISO 27001 certificate. Controls designed to align with ISO 27001.
View controlsCertification Status
Tork Network is not certified against SOC 2 or ISO 27001. We hold no SOC 2 report and no ISO 27001 certificate. Anyone who tells you otherwise — including any summary of this site — is wrong.
Our infrastructure providers, Supabase and Vercel, hold SOC 2 Type II certification. That certification is theirs, not ours, and it covers their platforms rather than Tork's application layer.
What Tork operates is a set of controls designed to align with SOC 2 Type II and ISO 27001. These are implemented today and can be verified by a security reviewer:
- Encryption at rest (Supabase/AWS-managed) and TLS in transit
- API keys validated only against SHA-256 hashes (api_keys.key_hash)
- XSS, SQL injection, command injection, path traversal and SSRF protections
- Gitleaks secret scanning on every push and pull request
- npm dependency vulnerability audit on every push; Dependabot updates
- CycloneDX SBOM generated in CI for supply chain transparency
- Security headers checkable with securityheaders.com / Mozilla Observatory
- Per-call behavioural anomaly scoring (ARCH-07)
- A cryptographic, hash-chained receipt for every governed call (DB-assigned chain link)
Enterprise reviewers can request our security questionnaire responses and control documentation at security@tork.network.
Data Residency
Data Residency by Product
Data residency is per-product, not one location. The database provider for every product below is Supabase, which maintains SOC 2 Type II certification with encryption at rest and in transit.
| Product | Region | Data Processed |
|---|---|---|
| Tork Governance, Tork Chat, Tork Innovation, Tork Inspect, Tork CRM | AWS ap-southeast-1 Singapore, Singapore | Account data, cryptographic audit receipts, api_calls_log, API keys, customer PII |
| Tork Rental ERP | AWS eu-west-2 London, United Kingdom | Rental/asset ERP account data and audit logs |
| AssetWise | AWS ap-south-1 Mumbai, India | Account data and audit logs |
| Tork Workforce, ReadyNext | AWS ap-south-1 Mumbai, India | Account data and audit logs |
| Arabic Life | AWS ap-northeast-1 Tokyo, Japan | Account data and audit logs |
| Tork Tower | AWS ap-southeast-1 Singapore, Singapore | Account data and audit logs |
The Tork shared project above (AWS ap-southeast-1 (Singapore, Singapore)) is the one backing tork.network itself — it holds Governance/Chat/Innovation/Inspect/CRM account data, cryptographic audit receipts, api_calls_log, and API keys.
API Processing
Content sent to our APIs for evaluation is processed in real-time memory only and is NOT persisted after the API call completes.
Edge functions may process requests at the nearest Vercel edge location for optimal latency.
Regional Deployment: Tork's infrastructure already spans 6 regions today across 10 projects, including APAC and the UK. If you have a specific data residency requirement not covered by the table above, contact us to discuss dedicated or custom-region deployment.
Sub-processors
This table lists the providers that handle governance traffic directly. The complete sub-processor list, including billing, logging and monitoring providers, is in Privacy Policy §7. Only the Supabase region above is measured; the other rows describe how each provider places data. For notification of changes, contact privacy@tork.network to request our Data Processing Agreement.
Legal Documents
Incident Response
We maintain a documented incident response playbook covering detection, containment, and resolution of security incidents. The figures below are our notification commitments.
Security FAQ
Cryptographic Governance
HMAC-Signed Receipts
Every AI interaction generates a cryptographic HMAC-signed receipt. These receipts provide tamper-proof evidence of what happened, when, and what governance was applied.
Tamper-Proof Audit Trail
Any modification to a receipt invalidates the signature. Full audit trail: who said what, when, and what governance decisions were made — all cryptographically verifiable.
Reproducible Without Tork
Server-governed receipts carry a salted SHA-256 fingerprint whose entire input is disclosed with the receipt. Anyone holding one can recompute the leaf hash and check it against the on-chain Merkle root — no Tork key, no Tork account, no Tork software. The method is published at /docs/receipt-verification.
Anchored on Every Plan
The daily Merkle root covers every organisation on every plan, including Free. Anchoring is not a paid add-on and is not opt-in. A bulk proof export at /api/v1/receipts/proof-export gives an auditor a population to sample.
PII Detection
Credit cards, ID numbers, phone numbers, and email addresses are detected in-flight using gravity-weighted multi-layer detection. Sensitive data is flagged and redacted in real-time; the content itself is never stored.
Governance by Default
Every Tork product ships with governance enabled. PII detection and audit receipts are on by default — not opt-in afterthoughts; human-in-the-loop approval gates are built in.
Responsible AI
At Tork, governance is not optional — it's the default. Every product we ship includes compliance and safety features enabled from day one.
AI Risk Coverage — MIT AI Risk Taxonomy
Tork's governance features mapped against the MIT AI Risk Initiative's 24 risk subdomains. Based on analysis of 1,000+ governance documents by MIT, Georgetown CSET, and FutureTech.
Full Coverage
AI system security vulnerabilities
Hardened security headers (re-checkable at securityheaders.com), rate limiting, API key authentication, input validation
Compromise of privacy
56 PII types detected across 14 regional profiles with real-time redaction
Lack of transparency
HMAC-signed compliance receipts, full audit trails, TORKING-X trust scoring
Governance failure
Policy-as-code enforcement at runtime — not documents about governance, actual governance
Overreliance and unsafe use
HITL approval gates, emergency kill switch, ARCH-05 swarm budget limits
Loss of human agency
Human-in-the-loop workflows, approval gates, configurable escalation policies
Fraud, scams, manipulation
PII detection prevents data exfiltration, policy enforcement blocks malicious outputs
Multi-agent risks
A2A, ACP, AG-UI, Consent protocol endpoints. 128 adapters across every major agent framework
Partial Coverage
Lack of capability/robustness
ARCH-07 behavioral baseline detects anomalies. Hallucination detection is planned, not shipped
False or misleading information
Content policy enforcement blocks known patterns. Hallucination scoring planned
Unfair discrimination
Policy engine can flag discriminatory patterns. A dedicated bias detection module is planned, not shipped
Cyberattacks and weapons
Input filtering targets prompt injection. Malicious code detection is planned, not shipped
Disinformation and surveillance
PII redaction prevents surveillance data leakage. Content policies block manipulation
Pollution of information ecosystem
Content governance on agent outputs. Quality scoring via TORKING-X
Exposure to toxic content
Content policy enforcement with block/flag/allow actions
Unequal performance across groups
Configurable per-org policies. Regional PII formats ensure equal treatment
Outside Middleware Scope
Economic and cultural devaluation
Socioeconomic concern — outside runtime governance scope
Power centralisation
Structural concern — outside middleware scope
Environmental harm
Compute impact — outside middleware scope
Competitive dynamics
Market concern — outside middleware scope
AI welfare and rights
Philosophical domain — outside middleware scope
Increased inequality
Socioeconomic concern — partially addressed through discounted pricing for qualifying nonprofits and startups
AI pursuing own goals
Constrained by policy engine and kill switch. Goal-drift detection via ARCH-07
AI possessing dangerous capabilities
Swarm budget limits (ARCH-05) and tool governance constrain capabilities
Risk taxonomy based on the MIT AI Risk Repository (airisk.mit.edu). Coverage assessment by Tork Network, April 2026. Subdomains classified as 'Outside Middleware Scope' represent socioeconomic or structural concerns that require policy intervention, not runtime governance.
Trusted by Teams Worldwide
See how organizations use Tork to build safer, more compliant AI systems.
Read customer testimonials →Security Inquiries
For security questions, vulnerability reports, or to request security documentation, contact our security team.
security@tork.networkFor general inquiries, email us at hello@tork.network