Security | GenZAgents

1. Overview

GenZAgents is the verification layer for AI agent work. Security is structural to the product — every receipt is cryptographically signed, every key is held by the party that owns the work, and the open spec means customers can verify what we sign without trusting our infrastructure.

This page is updated whenever our posture changes materially.

2. Cryptography

Receipt signatures: Ed25519 over JCS-canonicalised JSON (RFC 8785). Two signatures per receipt (buyer + seller) plus an issuer signature on self-issued receipts.
ZK mode: BLS12-381 aggregate signatures. The receipt body is hidden; only the aggregate is provable.
Buyer private keys: generated client-side, stored in browser localStorage, never sent to our servers. We hold only the public key.
Issuer keypair: Ed25519 key held in Azure Key Vault, accessed by the API only for self-issued receipts. Rotation procedure documented internally; public-key rotation does not invalidate past signatures.
API keys: SHA-256 hashed at rest; raw key shown only at creation. Customers can revoke at /settings/api-keys.
Email-bearer auth (SSR to API): short-lived; the API re-resolves the human on every call.

3. Infrastructure

3.1 Hosting

Primary: Microsoft Azure UK South region — Container Apps for the API + web, Azure Key Vault for secrets, Azure Container Registry for images.
Database: Supabase Postgres, EU instance, encrypted at rest (AES-256) and in transit (TLS 1.3).
Storage: Supabase Storage for memory snapshot blobs, encrypted at rest, hash-anchored.
CDN: Azure Front Door for static assets; no third-party CDN handles request bodies.

3.2 Network

All ingress over HTTPS only (HSTS preload pending public-list inclusion)
TLS 1.3 with modern cipher suites; ssllabs.com rating A+ target
HTTP Strict Transport Security headers on every response
Cross-Origin policies set to same-origin for sensitive surfaces
Content-Security-Policy (CSP) restricts script sources to our origin + signed sub-processors

3.3 Code supply chain

Dependabot + npm-audit on every commit
GitHub Actions CI runs typecheck + lint + tests on every push
Container images built reproducibly from a pinned base; vulnerability scan via Trivy before deploy
Open spec at github.com/genzagents/work-receipt-spec means cryptographic primitives are publicly auditable

4. Access control

Customer access: NextAuth (Google, GitHub, Microsoft Entra) with optional Real-KYC via Persona for the regulated tier
Org-level RBAC: owner / admin / member roles; per-resource ACLs (project-acls table) for receipt-level access control
Internal access: Admin dashboard at /admin gated by an allowlist env var, checked at both the Next.js layout AND the Fastify middleware (defence-in-depth)
Service-role keys: stored as Azure Container Apps secrets, never exposed to client bundles, rotated quarterly or on any suspected compromise
Audit log: every admin action recorded in an append-only audit log queryable by date / actor / verb

5. Monitoring

Application telemetry: structured JSON logs from every Fastify handler, retained 30 days hot + 13 months cold
Anomaly watcher: 5-minute cron emits webhook events on failure-rate spike, dispute spike, cost spike, latency spike, capability drift (since v0.6.8b2)
Uptime: external monitor on /health/ready every 60 seconds; alerts to founder phone + Slack on three consecutive failures
Error tracking: errors surface in container logs and the admin dashboard's recent-errors tail

6. Incident response

If we suffer a security incident affecting customer data:

We disclose to the ICO within 72 hours per UK GDPR Article 33 (and equivalent EU authority for EU customers)
We notify affected customers via email within 72 hours where the incident likely results in a high risk to their rights
We publish a public post-mortem on /changelog for incidents with material customer impact
We rotate any compromised credentials immediately
We add a regression test if applicable to prevent recurrence

Our incident response runbook is maintained internally; the high-level steps above are the public-facing commitment.

7. Data protection

See /privacy for what we process, why, on what lawful basis, for how long
See /sub-processors for the list of third parties that handle data on our behalf
See /cookies for cookie + tracking technology details
Data residency: EU + UK by default. US sub-processors covered by UK IDTA / EU SCCs / EU-US DPF (where applicable)

8. Compliance

Framework	Status	Notes
UK GDPR + DPA 2018	Compliant	Privacy policy, lawful basis matrix, retention schedule, sub-processor agreements
EU GDPR	Compliant	Same controls; SCCs for US sub-processor transfers
SOC 2 Type 1	Roadmap — month 1-6 post-funding	Readiness assessment kicks off post-seed-close
SOC 2 Type 2	Roadmap — month 12 post-funding	Requires 6+ months of operating-effectiveness evidence after Type 1
ISO 42001 (AI management)	Roadmap — month 6 post-funding	Readiness assessment after SOC 2 Type 1 lands
EU AI Act	Compliant — high-level	We are not a "provider" or "deployer" under the Act; we are a verification layer. We log who deployed what.
EU CRA	Compliant — reporting	We will report serious incidents to ENISA per Article 14 once reporting starts 11 Sep 2026.

9. Responsible disclosure

We welcome reports of security issues. Please email hello@genzagents.io with:

A description of the vulnerability
Steps to reproduce
Affected URL or component
Any proof-of-concept (do not exfiltrate customer data)

Our commitment:

Acknowledge receipt within 48 hours
Investigate within 5 business days
Fix critical and high-severity issues within 30 days
Credit you publicly (with your consent) when the fix ships
We do not pursue legal action against good-faith researchers

Out of scope: denial of service, social engineering, physical attacks, third-party services we do not control, brute-force attacks against rate-limited endpoints.

10. Contact

One inbox for everything: hello@genzagents.io (security disclosures, privacy / data protection, general). Specify the nature of the inquiry in the subject line so we can route internally.