Status: pre-launch. This evidence reflects implemented code and deployed infrastructure. Provii is not yet serving end-user production traffic, so production operational metrics and audit history are not yet available.

Privacy Architecture Evidence

Control Family: Privacy Controls (UC-001 through UC-043) Generated: 2026-02-14 Status: Architecture Analysis

Executive Summary

This document provides evidence for Maelstrom AI’s privacy controls through architecture analysis and data flow documentation. Maelstrom AI’s zero knowledge architecture is its primary privacy mechanism. The system is designed so that it does not collect PII, rather than relying on policy to protect it after collection.

Key Privacy Claim: Maelstrom AI-operated verification services never collect, process, or store names, addresses, contact information, identity documents, biometric data, or any other personally identifiable information (PII). During credential issuance, the date of birth is transmitted once to the provii-issuer for server-side Pedersen commitment computation and immediately discarded (never stored or logged). During verification, no PII is transmitted. only zero knowledge proofs.

Evidence Structure

This document provides evidence for 38 privacy controls across:

• Data Minimization (UC-001)
• Purpose Limitation (UC-002)
• Transparency (UC-003)
• Privacy Notices (UC-004)
• User Rights (UC-005)
• Privacy by Design & Default (UC-006)
• Data Protection Impact Assessment (UC-007)
• Privacy Governance (UC-008)
• Consent Management (UC-009)
• Cross-Border Transfers (UC-010)
• Automated Decision-Making (UC-011)
• [UC-012 through UC-043 - see Unified Control Matrix]

UC-001: Data Minimization

Control Requirement: Collect and process only the minimum data necessary for the intended purpose.

Evidence: What PII is Collected (Almost None)

Server-Side Processing (Maelstrom AI-Operated Services):

COLLECTED PII: None

NOT COLLECTED:
❌ Names
❌ Email addresses
❌ Physical addresses
❌ Phone numbers
❌ Dates of birth (DOB transmitted once during issuance for Pedersen commitment, immediately discarded)
❌ Identity document numbers
❌ Biometric data
❌ Government-issued IDs
❌ Social security numbers
❌ Any traditional PII

What IS Collected (Server-Side):

1. IP Addresses - Retained 90 days for anti-abuse only; critical security event logs are retained for up to 365 days

• Hashed with SHA-256 in logs for privacy
• Not linked to user identity
• Not shared with third parties

2. Credential Nullifiers - One-way cryptographic hashes

• Prevent credential reuse/replay
• Cannot be reversed to reveal DOB
• Not personally identifiable

3. Challenge IDs - Random UUIDs

• Single-use verification session identifiers
• No link to user identity
• Expire after use

Client-Side Processing:

• Date of Birth (DOB) - Transmitted once to provii-issuer during issuance for server-side Pedersen commitment computation; DOB immediately discarded after commitment. Never transmitted during verification.
• Credential private keys - Never leave device
• Proof generation happens on-device

Evidence Locations

Architecture Documentation:

• src/content/docs/trust/security/information-security-policy.mdx (Lines 102-109) - “Zero knowledge First” principle

Data Retention Policy:

• src/content/docs/trust/security/data-retention.md
• IP addresses: 90 days (critical security event logs: up to 365 days)
• Challenge records: 5-minute active TTL
• No PII retention (because none collected)

Code Evidence:

• provii-verifier/src/security/log_sanitizer.rs
• Lines 101-111: IP address hashing (hash_ip) for privacy
• Lines 1-18: GDPR compliance comments
• Shows implementation of data minimization in logging

Conclusion: ✅ PASS - Maelstrom AI is designed to collect the minimum data required for age verification. By design, the system is architected so that it does not collect PII that it does not need.

UC-002: Purpose Limitation

Control Requirement: Use data only for the stated purpose; don’t repurpose without consent.

Evidence: Data Usage Limited to Age Verification

Purpose Statement: All data collected is used exclusively for:

1. Performing cryptographic verification of age proofs
2. Anti-abuse protection (rate limiting, replay prevention)
3. System diagnostics and security monitoring

What Data is NOT Used For: ❌ Marketing or advertising ❌ User profiling or analytics ❌ Third-party data sharing ❌ Cross-site tracking ❌ Behavioural analysis ❌ Identity resolution

Evidence: Unlinkability by Design

Random IDs Per Verification:

• Each verification uses a fresh random challenge ID (UUID v4)
• No cross-site tracking possible
• No persistent user identifiers

Nullifiers for Replay Prevention:

// From provii-verifier/src/routes/verify.rs (Line 349)
let cred_nullifier = body.proof.public.cred_nullifier.0;

1. Nullifiers are one-way hashes derived from credentials
2. Prevent credential replay attacks
3. Cannot be used to track users across sites (different nullifier per verification context)

Evidence Locations:

• src/content/docs/concepts/trust-model.md - Unlinkability guarantees
• provii-verifier/src/routes/verify.rs (Lines 349-399) - Nullifier processing

Conclusion: ✅ PASS - Data is used strictly for stated purpose. Architecture prevents repurposing through unlinkability.

UC-003: Transparency

Control Requirement: Be clear and open about data processing practices.

Evidence: Radical Transparency

Public Documentation:

1. Open Source Code - All core components are open source:

• provii-verifier (backend)
• provii-issuer (credential issuance)
• Provii mobile wallet (client) repository under the MaelstromAI GitHub enterprise
• provii-crypto (cryptographic library)

2. Published ISMS - Entire Information Security Management System is public:

• Security policies
• Risk assessments
• Control implementations
• Compliance documentation

3. Architecture Documentation - Complete system design published at:

• https://docs.provii.app/overview/architecture
• Data flow diagrams
• Privacy guarantees
• Cryptographic specifications

Quote from Information Security Policy:

“We make our security practices public because:

• We have nothing to hide (no PII to protect through obscurity)
• Open scrutiny improves security
• It builds trust through verifiability”

Evidence Locations:

• src/content/docs/trust/security/information-security-policy.mdx (Lines 111-121) - Radical Transparency principle
• Complete ISMS published at /trust
• Open source repositories at GitHub

Conclusion: ✅ PASS - Complete transparency. Architecture, code, and policies are publicly auditable.

UC-004: Privacy Notices

Control Requirement: Provide clear privacy notices to users.

Evidence: Privacy Information Available

Where Privacy Information is Documented:

1. Data Retention Policy: src/content/docs/trust/security/data-retention.md

• What data is collected
• How long it’s retained
• Why it’s collected

2. Information Security Policy: src/content/docs/trust/security/information-security-policy.mdx

• Zero knowledge first principle
• What PII is NOT collected
• Privacy by design approach

1. How the system works
2. Data flows
3. Privacy guarantees

Key Notice Points:

• No PII collected by Maelstrom AI servers
• DOB transmitted once during issuance for Pedersen commitment computation, then immediately discarded
• IP addresses hashed and retained 90 days; critical security event logs are retained for up to 365 days
• Zero knowledge proofs reveal only age threshold (not DOB)

Evidence Locations:

• Published documentation at docs.provii.app
• Wallet UI (in-app privacy information)
• API documentation for integrators

Conclusion: ✅ PASS - privacy information publicly available. Zero knowledge architecture simplifies notice requirements (by design, the system is not intended to collect PII).

UC-005: User Rights (Access, Deletion, Portability)

Control Requirement: Enable users to exercise privacy rights (GDPR Articles 15-20).

Evidence: User Rights Implementation

Right to Access (Article 15):

• Status. Not applicable - no personal data held by Maelstrom AI servers
• User-Held Data. All credentials stored in wallet under user control
• Implementation. Users can export wallet data locally (JSON)

Right to Deletion (Article 17 - “Right to be Forgotten”):

• Status. Automatic - no PII to delete
• IP Addresses. Auto-deleted after 90 days; critical security event logs are retained for up to 365 days
• Challenge Records. 5-minute active TTL
• Wallet Data. User can delete wallet app (deletes all local credentials)

Right to Portability (Article 20):

• Status. Full portability - credentials are standard JSON
• Implementation. Wallet can export credentials
• No vendor lock-in. Cryptographic credentials are portable

Right to Rectification (Article 16):

• Status. Not applicable - Maelstrom AI doesn’t store personal data to rectify
• Implementation. Users update DOB in wallet; new credentials auto-generated

Right to Restrict Processing (Article 18):

• Status. Not applicable - minimal processing occurs
• Implementation. Users control when to generate and submit proofs

Evidence Locations:

• User rights enabled by architecture (no server-side PII)

Conclusion: ✅ PASS - Zero knowledge architecture makes most GDPR rights moot (no personal data held). Users have full control over wallet-held credentials.

UC-006: Privacy by Design & Default

Control Requirement: Implement Privacy by Design (7 foundational principles).

Evidence: Privacy by Design Implementation

The 7 Principles Applied to the Provii Platform:

1. Proactive not Reactive; Preventative not Remedial

1. ✅ Evidence: Architecture prevents PII collection rather than protecting it after collection
2. Quote. “If we don’t collect it, we can’t lose it.” (Information Security Policy)
3. Implementation. Zero knowledge proofs are designed so that DOB is not revealed during verification

2. Privacy as the Default Setting

1. ✅ Evidence: System reveals minimum information by default
2. Implementation. Proofs reveal only binary age threshold (over/under), not actual age or DOB
3. No opt-in required. Privacy is automatic, not configurable

3. Privacy Embedded into Design

1. ✅ Evidence: Privacy built into cryptographic protocol, not added later
2. Implementation. Groth16 zero knowledge proofs prevent information leakage
3. Code. provii-crypto library enforces privacy at protocol level

4. Full Functionality. Positive-Sum, not Zero-Sum

1. ✅ Evidence: Privacy doesn’t compromise functionality
2. Implementation. Verifiers get cryptographic proof of age without seeing DOB
3. Win-win. User privacy + verifier confidence

5. End-to-End Security. Full Lifecycle Protection

• ✅ Evidence: Security throughout entire flow
• Implementation:
• Issuance: DOB processed ephemerally for Pedersen commitment, immediately discarded; nullifiers prevent issuer tracking of subsequent verifications
• Storage: Credentials encrypted in wallet
• Verification: ZK proofs prevent verifier tracking
• Deletion: Auto-expiry of server-side records

6. Visibility and Transparency. Keep it Open

• ✅ Evidence: Complete transparency (see UC-003)
• Implementation. Open source code, published ISMS, public documentation

7. Respect for User Privacy. Keep it User-Centric

• ✅ Evidence: User controls all credential operations
• Implementation.
• Wallet-based credential storage
• User initiates proof generation
• No central database of credentials

Evidence Locations:

• src/content/docs/trust/security/information-security-policy.mdx (Lines 25-28, 99-109) - Privacy by Design principle
• src/content/docs/concepts/trust-model.md - Privacy guarantees

Conclusion: ✅ PASS - All 7 Privacy by Design principles implemented. Privacy by design is embedded in the Provii platform’s core architecture.

UC-007: Data Protection Impact Assessment (DPIA)

Control Requirement: Conduct DPIA for high-risk processing (GDPR Article 35).

Evidence: DPIA Status

Assessment: DPIA not strictly required because:

1. No PII processing: Server-side operations don’t involve personal data
2. No high-risk processing: No profiling, automated decision-making affecting legal rights, or large-scale sensitive data processing
3. Privacy-enhancing technology: System reduces privacy risk rather than increasing it

Risk Assessment Conducted:

• Location. src/content/docs/trust/security/risk-register.mdx
• Scope. Privacy risks from IP logging, credential tracking, issuer correlation
• Mitigations. IP hashing, nullifiers, RedJubjub issuer signatures

Evidence Locations:

• DPIA - Consolidated Data Protection Impact Assessment (completed February 2026)
• src/content/docs/trust/security/risk-register.mdx - Risk assessment
• src/content/docs/trust/security/risk-methodology.mdx - Risk methodology

Conclusion: ✅ IMPLEMENTED - Formal DPIA completed February 2026. Covers all processing activities including issuance, verification, and operational data. See DPIA.

UC-008: Privacy Governance

Control Requirement: Establish privacy governance structure with accountability.

Evidence: Privacy Roles and Responsibilities

Governance Structure:

ISMS Owner:

• Overall accountability for privacy program
• Approval of privacy policies
• Resource allocation for privacy initiatives

Privacy Officer:

• Implementation of privacy controls
• Privacy-by-design reviews
• Privacy incident response

Developers:

• Privacy-preserving code practices
• Privacy testing integration
• Privacy policy compliance

Evidence Locations:

• src/content/docs/trust/security/information-security-policy.mdx (Lines 148-177) - Roles and Responsibilities
• src/content/docs/trust/security/roles-responsibilities.md - Detailed role matrix

Privacy Policies:

• Information Security Policy (includes privacy principles)
• Data Retention Policy
• Acceptable Use Policy
• Incident Response Policy

Review Process:

• Annual policy review
• Risk assessments conducted annually
• Management review of ISMS effectiveness

Conclusion: ✅ PASS - Clear governance structure with defined roles. Privacy integrated into ISMS.

UC-009: Consent Management

Control Requirement: Obtain and manage user consent for data processing.

Evidence: Consent Not Required (Legitimate Interest)

Legal Basis for Processing (GDPR Article 6):

1. IP Address Logging: Legitimate interest in security and fraud prevention

• Minimal data retained (90 days, hashed; critical security event logs: up to 365 days)
• Necessary for service operation
• Balancing test: Security interest outweighs minimal privacy impact

2. Challenge Records: Necessary for contract performance

• Required to provide age verification service
• Short retention (5-minute active TTL)
• No PII involved

No Consent Required Because:

• No “special category” data processed (GDPR Article 9)
• No profiling or automated decision-making affecting rights
• Processing is minimally invasive
• Clear legitimate interest exists

Where Consent IS Obtained:

• Wallet Installation. User consents to app permissions
• Proof Generation. User explicitly initiates verification
• Issuer Credential Request. User chooses to obtain credential

Evidence: Privacy-first architecture minimizes consent requirements. Where consent is needed (wallet operations), it’s obtained through explicit user action.

Conclusion: ✅ PASS - Consent framework appropriate for processing activities. Zero-PII architecture substantially reduces consent requirements.

UC-010: Cross-Border Data Transfers

Control Requirement: Ensure lawful cross-border data transfers (GDPR Chapter V).

Evidence: Minimal Cross-Border Transfer Concerns

Data Transfer Analysis:

What Gets Transferred Internationally:

1. Zero knowledge Proofs - Cryptographic data (not personal data)
2. Challenge IDs - Random UUIDs (not personal data)
3. Credential Nullifiers - One-way hashes (not personal data)
4. IP Addresses - Hashed, minimal retention

Where Data May Travel:

• Cloudflare Edge Network. Globally distributed (300+ locations)
• GitHub Actions. Build infrastructure (various regions)
• Data at rest. Cloudflare KV (configurable regions)

GDPR Compliance Mechanisms:

1. Standard Contractual Clauses: Cloudflare provides SCCs
2. Data Minimization: No PII transferred = reduced risk
3. Adequacy Decisions: Some Cloudflare regions in adequate jurisdictions

Australian Privacy Act Compliance:

• Cross-border disclosure rules (APP 8) not applicable (no personal information disclosed)
• Maelstrom AI can operate globally without privacy barriers

Evidence Locations:

• src/content/docs/trust/security/supplier-management.md - Cloudflare vendor assessment
• Cloudflare SCC documentation (external)

Conclusion: ✅ PASS - Zero-PII architecture substantially reduces cross-border transfer concerns. Minimal data transferred is not personal data.

UC-011: Automated Decision-Making

Control Requirement: Provide safeguards for automated decision-making with legal effects (GDPR Article 22).

Evidence: No Automated Decision-Making with Legal Effect

Analysis: Maelstrom AI does NOT engage in automated decision-making as defined by GDPR Article 22 because:

1. No Profiling: System doesn’t build user profiles or predict behaviour
2. No Legal Effects: Age verification results don’t have legal or similarly significant effects
3. Human Oversight Available: Verifiers can implement manual review if desired
4. User Control: Users choose when to generate and submit proofs

What IS Automated:

• Cryptographic proof verification (mathematical, deterministic)
• Challenge generation (random, not decision-making)
• Replay detection (security, not profiling)

What IS NOT Automated:

• Identity verification (out of scope)
• Credit decisions (out of scope)
• Employment decisions (out of scope)
• Legal judgments (out of scope)

Evidence: Age verification is a simple binary check (over/under threshold), not a consequential automated decision requiring Article 22 protections.

Conclusion: ✅ PASS - Article 22 not applicable. System doesn’t make automated decisions with legal or similarly significant effects.

Data Flow Evidence

1. Issuance Flow (User → Issuer → Credential → Wallet)

┌─────────────────────────────────────────────────────────────────┐
│ ISSUANCE FLOW - What Data Goes Where                           │
└─────────────────────────────────────────────────────────────────┘

1. USER DEVICE (Wallet)
   ├─ INPUT: Date of Birth (DOB)
   ├─ PROCESSING: Sends DOB to issuer API for Pedersen commitment
   │  └─ DOB transmitted once, processed ephemerally
   ├─ DURING VERIFICATION: DOB never transmitted
   └─ SENDS TO ISSUER: DOB + randomness bits

2. ISSUER SERVICE
   ├─ RECEIVES: DOB transiently for Pedersen commitment computation
   ├─ PROCESSING: Computes Pedersen commitment, signs with RedJubjub key
   ├─ DISCARDS: DOB immediately after commitment (never stored or logged)
   └─ SENDS TO USER: Signed credential

3. USER DEVICE (Wallet)
   ├─ RECEIVES: Signed credential
   ├─ STORES: Credential locally (encrypted)
   └─ RESULT: User has ZK credential proving DOB without revealing it

┌─────────────────────────────────────────────────────────────────┐
│ PRIVACY PROPERTIES                                              │
├─────────────────────────────────────────────────────────────────┤
│ ✅ Issuer sees DOB ephemerally, discards immediately             │
│ ✅ Issuer cannot track user later (nullifiers)                  │
│ ✅ DOB never transmitted during verification                    │
│ ✅ No PII stored on Maelstrom AI servers                        │
└─────────────────────────────────────────────────────────────────┘

Evidence Locations:

• provii-issuer/ - Issuer implementation (computes Pedersen commitments server-side)

2. Verification Flow (Challenge → Proof → Verification)

┌─────────────────────────────────────────────────────────────────┐
│ VERIFICATION FLOW - What Data Goes Where                       │
└─────────────────────────────────────────────────────────────────┘

1. VERIFIER REQUEST
   ├─ SENDS: Origin, age threshold (e.g., "18+")
   └─ RECEIVES: Random challenge ID, RP challenge nonce

2. USER DEVICE (Wallet)
   ├─ INPUT: Credential, challenge, age threshold
   ├─ PROCESSING: Generate zero knowledge proof
   │  ├─ Proves: "My DOB makes me over threshold"
   │  ├─ Reveals: NOTHING about actual DOB
   │  └─ Includes: Nullifier (prevents replay)
   ├─ NEVER TRANSMITTED: DOB, credential private key
   └─ SENDS: Zero-knowledge proof + nullifier

3. VERIFIER API
   ├─ RECEIVES: ZK proof, nullifier, challenge response
   ├─ PROCESSING:
   │  ├─ Verifies cryptographic proof (Groth16)
   │  ├─ Checks nullifier not previously used
   │  ├─ Validates challenge matches
   │  └─ Confirms issuer signature valid
   ├─ LEARNS: User is over threshold (binary yes/no only)
   ├─ DOES NOT LEARN: Actual age, DOB, identity
   └─ RESULT: "VERIFIED" or "FAILED"

4. DATA RETAINED (Server-Side)
   ├─ Challenge record: 5-minute active TTL (then auto-deleted)
   ├─ IP address: 90 days, hashed (for anti-abuse); critical security events: up to 365 days
   └─ Nullifier: Checked against ban list (no personal data)

┌─────────────────────────────────────────────────────────────────┐
│ PRIVACY PROPERTIES                                              │
├─────────────────────────────────────────────────────────────────┤
│ ✅ Verifier cannot see DOB                                      │
│ ✅ Verifier cannot track user across sites (random IDs)         │
│ ✅ Zero-knowledge proof reveals only age threshold result       │
│ ✅ No PII processed by Maelstrom AI servers                     │
│ ✅ Unlinkability: Each verification is independent              │
└─────────────────────────────────────────────────────────────────┘

Evidence Locations:

• provii-verifier/src/routes/verify.rs - Verification implementation
• Lines 71-755: Complete verification flow
• Line 100-104: Challenge ID redaction for privacy
• Lines 349-399: Nullifier processing (privacy-preserving)

What’s NOT Collected (Critical Privacy Evidence)

Traditional PII - NONE Collected

This is just as important as what IS collected. Maelstrom AI’s architecture is designed so that the following items are not collected:

NOT COLLECTED (by architectural design):
├─ Personal Identifiers
│  ❌ Full name
│  ❌ Email address
│  ❌ Phone number
│  ❌ Physical address
│  ❌ Postal code
│  ❌ Social security number
│
├─ Identity Documents
│  ❌ Passport numbers
│  ❌ Driver's license numbers
│  ❌ Government-issued ID numbers
│  ❌ Document scans/photos
│
├─ Biometric Data
│  ❌ Facial recognition data
│  ❌ Fingerprints
│  ❌ Iris scans
│  ❌ Voice prints
│
├─ Sensitive Attributes
│  ❌ Date of birth (processed ephemerally during issuance, never stored; not transmitted during verification)
│  ❌ Actual age (only threshold revealed)
│  ❌ Birthplace
│  ❌ Nationality
│  ❌ Race/ethnicity
│  ❌ Gender
│  ❌ Religion
│
├─ Financial Data
│  ❌ Credit card numbers
│  ❌ Bank account details
│  ❌ Payment information
│
├─ Behavioral Data
│  ❌ Browsing history
│  ❌ Search queries
│  ❌ Location history
│  ❌ App usage patterns
│  ❌ Social connections
│
└─ Device Identifiers (No Tracking)
   ❌ Persistent device IDs
   ❌ Advertising IDs
   ❌ Cross-site tracking cookies
   ❌ Browser fingerprints

Why This Matters: Traditional privacy controls focus on “how we protect PII.” Maelstrom AI’s approach is to design the architecture so that PII is not collected in the first place. This is a substantially stronger privacy posture than policy-based controls.

Evidence:

• Information Security Policy states: “Maelstrom AI-operated services never collect, process, or store [PII]”
• Architecture documentation shows client-side DOB processing
• Code review shows no PII storage mechanisms

Privacy Policy Locations

Primary Privacy Documentation

1. Information Security Policy

• Path: src/content/docs/trust/security/information-security-policy.mdx
• Sections:
• Lines 102-109: “Zero knowledge First” (what’s NOT collected)
• Lines 111-121: “Radical Transparency”
• Lines 25-28: “Privacy by Design” philosophy

2. Data Retention Policy

• Path: src/content/docs/trust/security/data-retention.md
• Covers:
• IP address retention (90 days; critical security event logs: up to 365 days)
• Challenge record retention (5-minute active TTL)
• No PII retention schedule (none collected)

3. Architecture Documentation

• Covers:
• Data flow diagrams
• Privacy guarantees
• Zero knowledge protocol

4. Trust Model

• Path: src/content/docs/concepts/trust-model.md
• Covers:
• Unlinkability guarantees
• Issuer blindness
• Verifier limitations

5. Log Sanitization Implementation

• Path: provii-verifier/src/security/log_sanitizer.rs
• Lines 1-18: GDPR compliance documentation
• Lines 101-111: IP hashing (hash_ip. data minimization)
• Lines 23-50: PKCE verifier redaction
• Lines 52-79: Challenge ID redaction

Cross-References to Existing ISMS Docs

Security Controls Implementing Privacy

1. Access Control

• Policy: src/content/docs/trust/security/access-control.md
• Privacy Impact: Protects operational secrets, not PII (no PII to protect)

2. Cryptography Policy

• Policy: src/content/docs/trust/security/cryptography-policy.md
• Privacy Impact: Zero knowledge proofs are core privacy mechanism

3. Incident Response

• Policy: src/content/docs/trust/security/incident-response.mdx
• Privacy Impact: Breach risk is substantially reduced (no PII collected by design)

4. Business Continuity

• Policy: src/content/docs/trust/security/business-continuity.mdx
• Privacy Impact: No PII backup/recovery needed

5. Risk Management

• Methodology: src/content/docs/trust/security/risk-methodology.mdx
• Register: src/content/docs/trust/security/risk-register.mdx
• Privacy Risks Assessed:
• IP address correlation
• Credential tracking
• Issuer deanonymization

6. Supplier Management

• Policy: src/content/docs/trust/security/supplier-management.md
• Privacy Impact: Cloudflare processes no PII (only ZK proofs)

Privacy Architecture: Comparison with Traditional Systems

Why Maelstrom AI’s Privacy Architecture Matters

Traditional Age Verification:

Traditional System:
├─ Collects: Full name, DOB, ID document, address
├─ Stores: PII in central database
├─ Risks: Data breach exposes all user PII
├─ Compliance: Heavy GDPR/Privacy Act obligations
└─ User Trust: Must trust verifier with sensitive data

Provii’s Zero knowledge Approach:

Provii System:
├─ Collects: Nothing (ZK proof only)
├─ Stores: No PII (by architectural design)
├─ Risks: Breach reveals no PII (none to breach)
├─ Compliance: Minimal obligations (no PII processing)
└─ User Trust: Cryptographic verification, not policy promise

Operational Benefits of Privacy Architecture

1. Reduced Compliance Burden

• No GDPR data subject access requests (no data to access)
• No data breach notification requirements (no PII to breach)
• No data retention schedule for PII (none collected)

2. Lower Risk Profile

• No honeypot of PII for attackers
• No regulatory fines for PII mishandling
• No reputational damage from PII leaks

3. User Trust

• Mathematical proof of privacy (not policy)
• No “trust us” required
• Open source verification

4. Regulatory Alignment

• Zero knowledge design aligns with privacy-by-design regulatory expectations
• Privacy-first approach in age verification
• Architecture supports regulatory obligations (privacy by design)

Gaps and Recommendations

Current Gaps

1. DPIA Documentation (UC-007)

• Gap. No formal Data Protection Impact Assessment documented
• Recommendation. Create lightweight privacy impact analysis documenting:
• Data flows (issuance, verification)
• Privacy risks identified (IP logging, correlation)
• Architectural mitigations (hashing, nullifiers)
• User controls (wallet-based)
• Effort. Low (2-4 hours)
• Priority. Medium (strengthens compliance posture)

2. Privacy Notice in Wallet UI

• Gap. In-wallet privacy notice not documented
• Recommendation. Ensure wallet displays:
• “Your date of birth is sent once during setup, used to create your credential, then immediately deleted”
• “During age checks, only a cryptographic proof is sent — your date of birth is never transmitted”
• “Only binary age threshold (over/under) is revealed”
• Effort. Low (UI text update)
• Priority. Medium (user transparency)

3. Consent Flow Documentation

• Gap. User consent flows not formally documented
• Recommendation. Document:
• Wallet installation consent
• Proof generation consent (explicit user action)
• Issuer credential request consent
• Effort. Low (1-2 hours)
• Priority. Low (already implemented, needs documentation)

Control Strengths

1. Zero knowledge Architecture - Privacy designed into the core protocol
2. Privacy by Design - All 7 principles implemented
3. Radical Transparency - Open source + published ISMS
4. Data Minimization - Architecture designed to avoid collecting PII (by design, not policy)
5. Unlinkability - Random IDs reduce cross-site tracking risk

Conclusion

Privacy Controls Summary

Overall Assessment: STRONG PASS

Maelstrom AI’s zero knowledge architecture provides strong architectural privacy properties superior to policy-based controls. The system is designed so that it does not collect PII, which substantially reduces privacy compliance obligations.

Key Characteristics

1. Architecture over policy: Designed so PII is not collected rather than protected after the fact
2. Privacy through cryptography: Zero knowledge enables privacy properties not achievable with traditional systems
3. Compliance simplification: No PII = minimal compliance burden
4. Radical transparency: Open source + published ISMS builds trust

Evidence Strength

Excellent Evidence:

• Zero knowledge architecture documentation
• Open source code implementing privacy controls
• Data flow diagrams showing no PII collection
• Log sanitization code (IP hashing, redaction)
• Published ISMS policies

Good Evidence:

• Data retention policies
• Privacy governance structure
• User control mechanisms (wallet-based)

Areas for Improvement:

• Formal DPIA documentation (recommended)
• In-wallet privacy notice documentation
• Consent flow documentation

Evidence Artifacts

Code References

1. provii-verifier/src/security/log_sanitizer.rs - GDPR compliance, IP hashing
2. provii-verifier/src/routes/verify.rs - Verification flow, nullifier processing
3. provii-verifier/src/routes/challenge.rs - Challenge generation

Documentation References

• src/content/docs/concepts/trust-model.md - Privacy guarantees
• src/content/docs/trust/security/information-security-policy.mdx - Privacy principles
• src/content/docs/trust/security/data-retention.md - Data retention
• src/content/docs/trust/security/risk-register.mdx - Privacy risks

Policy References

• Information Security Policy (v1.0, 2026-02-14)
• Data Retention Policy
• Cryptography Policy
• Risk Assessment Methodology

Document Information