Security Model
Wytness's security is built on five independent control domains. Each domain provides protection that does not depend on the others — compromise of one layer does not expose the rest.
1. Data Integrity
Every audit event carries two independent integrity proofs: an Ed25519 digital signature and a SHA-256 hash chain link. Together, they make it mathematically infeasible to alter, insert, or delete any historical record.
| Control | How It Works |
|---|---|
| Ed25519 signing | Every event signed with agent's private key. Signature verifiable with public key alone. |
| SHA-256 hash chaining | Each event includes hash of previous event. Altering any record breaks the chain from that point forward. |
| Tamper detection on read | The /verify endpoint checks the entire chain for any agent on demand. |
| 7-year audit-log retention | Long-term (7-year) retention with a soft-delete recovery window on hosted storage; on cancellation your history is handed over as signed Evidence Packs.Customer-hosted storage (Business+) can opt into Azure Blob immutability_policy on the customer's own bucket. |
| Append-only event stream | The API is the only writer and exposes no update path for a recorded event. Deletion exists only where the law requires it — your erasure requests and the retention lifecycle — and each is audited. Alteration is made detectable by the hash chain and per-event signatures rather than blocked by a storage lock; customer-hosted storage can add one. |
| Per-org signing keys | Each org's events are verified against that org's own Ed25519 public key, registered at app.wytness.ai/keys. The matching private key never leaves the customer's environment. |
| Poison-event DLQ | Events that fail processing after retries are preserved in a dead-letter queue instead of being silently dropped. |
2. Access Control
| Control | How It Works |
|---|---|
| Dashboard authentication | JWT bearer tokens with bcrypt-hashed passwords. Refresh tokens (7-day) revocable per session. Self-audit log records every login, refresh, and password change. |
| Managed Identity | Service-to-service auth uses managed identity wherever supported. Zero credentials in code. |
| Resource-level RBAC | Every infrastructure resource has explicit role assignments. No wildcard permissions. |
| Per-org cryptographic key registry | HMAC, X25519, and Ed25519 public keys stored in org-scoped tables. Customer holds all private halves. Wytness has zero ability to forge events or decrypt PII. |
| API key authentication (SDK) | Each agent authenticates to /ingest with an X-API-Key header. Each key scoped to one organisation. |
| Self-audit trail | Every auth lifecycle event (signup, login, refresh, password change, API key create/revoke) and every superadmin cross-org inspection is recorded with actor, target, IP, and user-agent. |
3. Data Privacy
| Control | How It Works |
|---|---|
| Automatic PII redaction | Emails, phone numbers, SSN, TFN, and credit cards are automatically redacted from parameters and responses by default — no configuration needed. For stronger protection, enable HMAC pseudonymization with customer-held keys for a zero-knowledge architecture where Wytness cannot reverse pseudonyms. |
| HMAC cross-session pseudonyms | With pseudonymization enabled, the same PII value always produces the same token (e.g. EMAIL_3c866e6f) across sessions and agents, enabling correlation without storing raw data. |
| Customer-held decryption keys | The encrypted token map attached to each event can only be decrypted by the customer's X25519 private key. Wytness has no access to the mapping between pseudonyms and original values. |
| Browser-only PII reveal | Decryption of pseudonymized tokens happens entirely in the customer's browser. The private key is held in memory, never persisted to disk, and never transmitted to Wytness servers. Closing the browser tab clears the key. |
| Subject lookup | Owners and admins locate every event referencing a data subject by computing the subject's pseudonym token in the browser (Compliance → Subject lookup) and searching for the token. The HMAC secret and the raw value never leave the tab. |
| Secret auto-redaction | The SDK automatically detects parameter names matching key/secret/token/password/credential and replaces values with [REDACTED]. |
| Data classification labels | Each event carries an inputs_classification field (internal/confidential/restricted) for data governance. |
| Edge protection | All API traffic is proxied through a global edge network providing WAF, DDoS protection, and rate limiting before reaching the application layer. |
| TLS 1.3 in transit | All network communication uses TLS 1.3. No plaintext transmission at any point. |
| AES-256 at rest | All stored data is encrypted at rest with AES-256 managed keys. |
4. Compliance-Evidence Controls
These are output-mapping controls — what your auditor reads against the frameworks your auditor cares about. Wytness-the-vendor is not SOC 2 or ISO 27001 certified; the platform generates evidence the customer presents under their own audit. Vendor attestations Wytness itself holds (Microsoft Partner, MIT-licensed AGT substrate, pen test scheduled Q3 2026) are at /trust.
| Output mapping | How It Works |
|---|---|
| SOC 2 Common Criteria evidence | Evidence Pack maps to CC6.1 logical access, CC6.6 transmission, CC7.2 monitoring, CC7.3 evaluation, CC8.1 change management. Your CPA firm runs the audit; Wytness output feeds their working papers. |
| ISO 27001:2022 Annex A evidence | Evidence Pack maps to A.5.15 access control, A.8.15 logging, A.8.16 monitoring, A.8.17 clock synchronisation, A.8.23 web filtering, A.8.28 secure coding. Your auditor runs the ISMS audit; Wytness output supports it. |
| GDPR Article 22 | Every automated decision is logged with structured context — who, what, why, when. |
| EU AI Act audit trail | Transparency (Art. 13) and quality management (Art. 17) requirements addressed. |
| 7-year audit-log retention | Long-term (7-year) retention with a soft-delete recovery window, ending in a signed Evidence Pack handover on cancellation. Legally defensible as append-only with documented retention policy and per-event Ed25519 signatures. |
| Legal hold capability | Customer-hosted storage (Business+) can opt into Azure Blob immutability_policy on the customer's own bucket for full legal-hold treatment. Hosted storage offers long-term retention with a soft-delete recovery window and cryptographic tamper-evidence. |
5. Threat Detection
| Control | How It Works |
|---|---|
| Behavioural anomaly rules | Seven built-in rules continuously scan the event stream: first-time tool use, frequency spikes, error rates, restricted-data access, off-hours activity, chain breaks, and capability-profile deviation. A separate integrity checker reconciles the query store against the archive. |
| Signature failure = critical | Invalid Ed25519 signature triggers immediate critical alert. Event is rejected. |
| Chain tampering = critical | Hash chain mismatch triggers critical alert. Event is still stored for investigation. Breaks follow a resolution workflow (open → investigating → resolved) with password-confirmed approvals and full audit trail. |
| Platform monitoring | Infrastructure-level metrics (CPU, memory, error rates) trigger operational alerts. |
| Audit of the audit | All API access to the dashboard is itself logged. Who queried what, when. |
Important
The Ed25519 private key is the most sensitive component in the system. It stays in the customer's environment on every tier — it is never transmitted to Wytness. Where you keep it (env var, secret manager, HSM) is your call; Wytness only ever sees the public key you register.
Enterprise Hardening
Every tier — including Enterprise — runs on the Wytness-managed platform. The isolation levers Enterprise buyers care about are the data plane, not a separate deployment: your raw audit archive can land in your own storage account, and every private key stays with you.
| Control | Detail |
|---|---|
| Bring-Your-Own-Storage (BYOS) | The append-only audit archive lands in an Azure Blob container in your own subscription (Business and Enterprise). Residency, at-rest encryption settings, and immutability policy on that bucket are yours to configure |
| Customer-held keys | Ed25519 signing keys and PII pseudonymisation keys never leave your environment — Wytness cannot forge events or decrypt PII. Wytness-hosted storage uses platform-managed AES-256 keys; the keys you hold are the signing and PII keys, not storage keys |
| Per-org isolation | Org-scoped data isolation on the managed platform, enforced in every query path and pinned by cross-tenant regression tests |
| Monitoring integration (coming soon) | Connectors will push audit evidence into your own SIEM and alerting stack — Sentinel, Splunk, ServiceNow, Slack, or a generic webhook |
| Network isolation (roadmap) | Private endpoints into the ingest API and sovereign compute regions are scoped but not yet built — sales-led conversations today, not self-serve configurations |
Note
For full architecture details including network requirements, data flow diagrams, and deployment topology, see the Enterprise Architecture documentation.
Tip
For our security commitments, compliance alignment, and data processing terms, visit the Trust Centre.
Enterprise-grade security from day one.
Start recording