Information Security Policy

Purpose

This Information Security Policy establishes the security principles, objectives, and requirements for Maelstrom AI as an organisation, covering both platforms it operates under one ISMS — Provii (zero-knowledge age verification) and downpipes (no-custody backup & disaster recovery for the Cloudflare data layer). It provides the foundation for our ISO 27001:2022 Information Security Management System (ISMS).

Scope

This policy applies to:

• All team members (employees, contractors, consultants)
• All information systems within the ISMS scope
• All information assets, including source code, cryptographic keys, and operational data
• All third-party service providers with access to our systems

Policy Statement

Maelstrom AI is committed to protecting the confidentiality, integrity, and availability of both platforms it operates — Provii and downpipes — through a risk-based security program.

We recognise that security is fundamental to our mission of privacy-preserving identity verification and no-custody data resilience. Our security philosophy emphasises:

1. Privacy by Design: Building systems that can’t collect PII (Provii), and a no-custody architecture where Maelstrom holds no customer keys or data (downpipes), rather than relying on policy to protect it
2. Defence in Depth: Implementing multiple layers of security controls
3. Transparency: Making our security practices publicly auditable
4. Continuous Improvement: Regularly assessing and enhancing security posture

Security Objectives

1. Protect Cryptographic Integrity

Objective: Ensure the mathematical soundness and security of our zero knowledge proof systems (Provii) and the integrity of post-quantum-sealed, tamper-evident archives (downpipes)

How We Achieve This:

• Using battle-tested cryptographic libraries (bellman, bls12_381)
• Sealing downpipes archives with post-quantum hybrid encryption under customer-held keys (no-custody)
• Regular security reviews of cryptographic code
• Maintaining strict access control for signing keys
• Testing including fuzzing, property-based tests, and known-answer tests

See: provii-crypto documentation | Cryptography Policy

2. Maintain Service Availability

Objective: Provide reliable age verification services (Provii) with minimal unplanned downtime, and proven recoverability of customer data (downpipes)

Target: 99.9% uptime for production APIs (best-effort internal objective; no contractual SLA at this tier)

How We Achieve This:

• Edge-based architecture on Cloudflare’s global network
• Edge-based redundancy through Cloudflare’s global network with smart placement
• Rate limiting and DDoS protection
• For downpipes, a fail-open vendor control-plane that never gates backup or restore, with 3-2-1 fan-out to customer-controlled destinations and an offline reader for vendor-independent recovery
• Incident response procedures for rapid recovery

See: Business Continuity Plan

3. Secure Software Development

Objective: Produce secure, auditable code through rigorous development practices

How We Achieve This:

• Security scanning in CI/CD (CodeQL, cargo audit, npm audit)
• Mutation and property-based testing
• Code review requirements
• SLSA Level 3 supply chain security

See: Development Best Practices

4. Protect Operational Secrets

Objective: Safeguard API keys, signing keys, and authentication secrets

How We Achieve This:

• Cloudflare Workers secrets (never in source code)
• KV storage with access controls
• HMAC-based API authentication
• Regular secret rotation for long-lived credentials
• Zeroization of secrets in memory after use
• For downpipes, the vendor-side downpipes Licence Signer is held in Cloudflare Secrets Store (control-plane, fail-open) and the downpipes Update Signer is held offline by the operator and never deployed to any Worker; customer encryption keys are held solely by the customer (no-custody)

See: Cryptography Policy

5. Ensure Compliance

Objective: Meet legal and regulatory requirements, particularly Australian Privacy Act

Status: For Provii, the zero knowledge architecture significantly simplifies compliance by minimising server-side PII processing. During issuance, the date of birth is transmitted once to the issuer API for Pedersen commitment computation and immediately discarded. During verification, no PII is transmitted. For downpipes, the no-custody architecture means Maelstrom holds no customer keys, data or Cloudflare tokens, so Maelstrom adds no sub-processor for customer data.

How We Achieve This:

• Regular compliance assessments
• Documented policies and procedures
• Audit trail for security-relevant events
• ISO 27001:2022 certification pursuit when commercially justified

Information Security Principles

1. Data Minimisation and No-Custody

Our architectural principle: If we don’t collect it, we can’t lose it (Provii); if we never hold the customer’s keys or data, we cannot expose them (downpipes).

2. Radical Transparency

We make our security practices public because:

• We have little to hide (Provii holds no PII to protect through obscurity; downpipes holds no customer keys or data under a no-custody model)
• Open scrutiny improves security
• It builds trust through verifiability
• Customers can audit our controls without waiting for a sales call

What’s Public: Architecture, policies, procedures, control implementations, source code (Provii repositories under a per-repo licence mix; the downpipes engine, console and control-plane are source-available under the Elastic License v2, and the offline reader is MIT open source)

What’s Private: Operational secrets (API tokens, signing keys, HMAC secrets, the offline downpipes Update Signer)

3. Security by Design

Security is integrated into every phase:

• Design. Threat modelling before implementation
• Development. Security scanning, testing, code review
• Deployment. Hermetic builds, artifact signing, provenance
• Operation. Monitoring, logging, incident response

4. Defence in Depth

We implement multiple layers of security:

• Network. Cloudflare DDoS protection, edge security
• Application. Input validation, rate limiting, HMAC authentication
• Cryptographic. Zero knowledge proofs and digital signatures (Provii); post-quantum hybrid encryption of archives under customer-held keys (downpipes)
• Operational. Access controls, audit logging, incident response
• Supply Chain. SLSA Level 3 compliance, artifact signing, and the signature-pinned downpipes update channel (the engine verifies updates against a pinned public key before applying; pulled, never pushed)

5. Least Privilege

Access rights are minimised:

• CI/CD jobs have minimal permissions
• API keys scoped to specific functions
• Role-based access control where applicable
• Time-limited credentials for temporary access

Roles and Responsibilities

ISMS Owner

• Overall accountability for the ISMS
• Approval of security policies and risk treatments
• Resource allocation for security initiatives
• Management review and ISMS effectiveness

Security Lead

• Implementation and maintenance of security controls
• Security testing and vulnerability management
• Incident response coordination
• Internal security audits

Developer

• Secure coding practices
• Security testing integration in development
• Compliance with security policies
• Reporting security concerns

All Team Members

• Completing security awareness training
• Following the Acceptable Use Policy
• Reporting security incidents immediately
• Protecting credentials and access tokens

See: Roles and Responsibilities Matrix

Risk Management

Approach: We follow a risk-based approach to security, focusing resources on the most significant threats to both platforms — the Provii zero knowledge age verification service and the downpipes no-custody backup & disaster recovery service.

Process:

1. Identify information assets and threats
2. Assess likelihood and impact of risks
3. Treat risks through controls or acceptance
4. Monitor effectiveness and emerging threats

Frequency: Risk assessments conducted annually and after significant changes

See: Risk Assessment Methodology | Risk Register

Security Controls

We implement controls based on ISO 27001:2022 Annex A, tailored to our cloud-native architecture across both platforms — Provii’s zero knowledge model and downpipes’ no-custody, in-tenant model:

See: Statement of Applicability for full control catalogue

Key Supporting Policies

Compliance Requirements

Australian Privacy Act 1988

Status: Significantly simplified compliance — Provii’s zero knowledge architecture and downpipes’ no-custody architecture both minimise the personal information Maelstrom handles

Obligations:

• For Provii, we minimise personal information collection; during age verification, no personal information is collected. During credential issuance, a date of birth is processed ephemerally and immediately discarded
• For downpipes, Maelstrom holds no customer keys, data or Cloudflare tokens; backups run in the customer’s own Cloudflare account, sealed under the customer’s keys
• IP addresses in audit logs are treated as personal data and automatically deleted after 90 days
• Audit logs retained 90 days for anti-abuse; critical security event logs are retained for up to 365 days

Documentation: Our architecture naturally satisfies privacy principles through technical controls rather than policy restrictions

ISO 27001:2022

Status: ISMS implementation in progress, certification pursued when commercially justified

Requirements Met:

• ✅ ISMS scope defined
• ✅ Information security policy established
• ✅ Risk assessment methodology documented
• ✅ Statement of Applicability (all 93 controls addressed)
• ✅ Supporting policies and procedures
• ✅ Internal audit program

Remaining Work:

• Achieving 12 months of evidence for certification audit
• External certification audit process

Security Awareness and Training

All team members receive security awareness training covering:

• Information security responsibilities
• Threat surface (phishing, social engineering, supply chain attacks)
• Secure coding practices
• Incident reporting procedures
• Password and credential management
• Remote work security

Frequency: Initial training on onboarding, annual refreshers, ad-hoc for emerging threats

See: Security Awareness Training Program

Incident Response

Security incidents must be reported immediately to: security@maelstrom.au

Definition of Security Incident:

• Unauthorized access to systems or data
• Compromise of cryptographic keys
• Service disruption or availability issues
• Vulnerabilities in production systems
• Supply chain compromise indicators

Response Process:

1. Detect and report incident
2. Assess severity and scope
3. Contain the incident
4. Eradicate root cause
5. Recover services
6. Learn and improve controls

See: Incident Response Policy and Procedure

Non-Compliance

Violations of this policy may result in:

• Mandatory security training
• Access restrictions
• Disciplinary action
• Termination of access for contractors
• Legal action (for criminal violations)

Reporting Violations: Team members should report suspected policy violations to the ISMS Owner or Security Lead.

Policy Review and Maintenance

This policy is reviewed:

• Annually as part of quarterly management review cycle
• After significant security incidents
• When changes to ISO 27001 standard occur
• When significant business or technical changes occur

Review Process:

1. Security Lead proposes updates
2. ISMS Owner reviews and approves
3. All team members notified of changes
4. Training provided if needed

Exceptions

Security policy exceptions require:

1. Written justification and risk assessment
2. Compensating controls where possible
3. Approval from ISMS Owner
4. Time limit and review date
5. Documentation in risk register

No exceptions permitted for:

• Cryptographic algorithm standards
• Artifact signing requirements
• Incident reporting obligations
• Access to production signing keys

Contact

Security Questions: security@maelstrom.au

Policy Owner: ISMS Owner

Document Location: https://maelstrom.au/trust/security/information-security-policy

Document Information

• Version. 1.2
• Effective Date. 2025-01-13
• Last Updated. 2026-06-19
• Owner. ISMS Owner
• Review Frequency. Annually
• Next Review. 2026-11-21
• Classification. Public
• Approved By. ISMS Owner
• Approval Date. 2025-01-13
• Change (1.2). downpipes added as second in-scope platform; the legacy backup worker retired in favour of self-hosted downpipes.

Acknowledgment: By accessing Maelstrom AI systems or information, you acknowledge that you have read, understood, and agree to comply with this Information Security Policy.