security architecture
Security
What Wytness sees, what it doesn't, and what it does about both.
the model
Keys we never hold
Two threats shape the design: a compromise of Wytness exposing customer data, and a compromise of your environment forging events. Both are answered with keys we never hold. Keypairs are generated in your browser; the private halves live in your secrets manager; only public keys are registered with us — used for verification, never decryption. We can be compromised and still not expose your PII. An attacker in your environment can only forge under your key, and rotation invalidates the forgeries.
the boundary
What Wytness can and cannot see
wytness can see
- ·Pseudonymised events with PII fields replaced by customer-generated tokens.
- ·Event metadata: timestamps, agent identifiers, tool names, outcomes, error codes.
- ·AGT policy decisions and the public key registered for signature verification.
- ·Anomaly engine results derived from the above.
wytness cannot see
- ✕Raw PII. Pseudonymisation runs in the customer environment before egress.
- ✕The private keys used to sign events or pseudonymise PII. Browser-side keygen, customer-held storage.
- ✕Data behind tokens: re-identification requires the customer's private key and runs against the customer's copy.
- ✕In Bring Your Own Storage mode, the raw audit events themselves. We hold a metadata index only.
four layers
Who holds which key
| Layer | Primitive | Property | Key holder |
|---|---|---|---|
| AGT — identity | Ed25519 on agent DIDs, IATP delegation | Who ran this | Customer (AGT runtime) |
| AGT — tamper-evidence | SHA-256 hash chain, optional HMAC | Chain was not altered | Customer (HMAC secret, optional) |
| Wytness — non-repudiation | Per-event Ed25519 in wrapper envelope | Owner attested to this exact action, cannot deny later | Customer (browser-generated) |
| Wytness — zero-knowledge | HMAC-SHA256 + X25519 + ChaCha20-Poly1305 token map | Wytness never sees PII | Customer (browser-generated) |
mechanics
Encryption, isolation, access
in transit
TLS 1.3 between the wrapper SDK and the ingest endpoint.
at rest · wytness
Azure Storage Service Encryption with platform-managed keys.
at rest · byos
Customer-managed encryption per your storage configuration. We never hold the data key.
event-level
Per-event Ed25519 envelope with your private key. Any auditor with the public key can verify.
Every query is org-scoped, every storage object path-isolated, every service token single-org. Staff access is least-privilege, MFA'd, and logged — and the customer-held key is the backstop: an elevated session still can't decrypt your PII. Cross-org access is a named focus of the pen test.
vendor attestations
What Wytness-the-vendor holds
Wytness is not pursuing SOC 2 or ISO 27001 certification at launch; the platform generates Evidence Pack output your auditor reads under your own audit.
Microsoft Partner
Active
Wytness is an active Microsoft Partner.
MIT-licensed substrate
Active
Composes on Microsoft's Agent Governance Toolkit (MIT, open source). The chain primitives under every audit entry are inspectable, not vendor-locked.
OWASP Agentic Top 10
Coverage via AGT
AGT's identity, hash-chain, and policy primitives cover the OWASP Agentic Top 10 threat surface; Wytness inherits that coverage in the wrapper SDK.
Penetration test
Scheduled Q3 2026
First annual third-party pen test: ingest, dashboard, per-organisation isolation, PII middleware. Summary on request under NDA after the first report lands.
Doing a security review?
Incidents: documented IR plan, customers notified within 72 hours — sooner where GDPR or your DPA requires. Vulnerabilities: security@wytness.ai, response within 48 hours.