Security
Protection Built In, Not Bolted On
Security was foundational to Village design. Your community's data stays protected, isolated, and under your control.
Our Security Philosophy
We believe security comes from architecture, not promises. Village was designed from day one to protect your community's data through technical measures, not just policies. Here's what that means in practice.
What We Protect
🔐 Your Stories & Content
Family narratives, photos, and documents are encrypted in transit and protected at rest through tenant isolation, access controls, and server-side encryption for stored files. Only your community members can access them.
👥 Your Membership
Member information is visible only within your Village. Other Villages cannot see your member list.
💬 Your Conversations
Chat messages and video calls stay within your community. Video calls use encrypted WebRTC transport with optional end-to-end encryption.
🗳️ Your Decisions
Governance votes and polls are private to your community. Voting records are protected.
What We Don't Do
Understanding what we refuse to do is just as important as understanding our protections.
Vendor Exclusions
- No Google services anywhere (no Docs Viewer, no Fonts, no Analytics)
- No Facebook/Meta integration or tracking pixels
- No third-party analytics that track your behaviour
- No advertising networks or data brokers
- No tracking CDNs on public pages. Member media loads from the Village's own servers, same-origin, so the member's session applies to every request and no CDN sees it
Data Practices We Refuse
- We never sell your data to anyone
- We never share data with third parties for marketing
- We never use your content to train AI models
- We never mine your data for insights to sell
- We never track you across websites
Federation Security
When Villages connect through Federation, security remains paramount. Federation enables collaboration without compromising independence.
How Federation Protects You
- Each Village controls exactly what they share with partners
- Federation agreements are explicit and documented
- Either party can adjust or revoke access at any time
- Shared content is clearly marked as federated
- Dispute resolution processes protect both communities
Think of it like neighbours agreeing to share a garden path, not handing over house keys. Each Village remains sovereign over their own space while choosing specific, controlled connections with others.
Access Controls
Who Can Access Your Data
- Your Members: Full access to content they're authorised to see
- Your Moderators: Administrative access within your Village only
- Platform Operators: Infrastructure access only, never content access
Technical Security Measures
We implement industry-standard security practices across our infrastructure.
Encryption in Transit
All connections use TLS 1.3. Your data is encrypted between your device and our servers.
Data Protection at Rest
Data is protected at rest through multiple layers including application-level encryption for sensitive credentials, server-side encryption for file storage, and infrastructure access controls.
Secure Authentication
Passwords are hashed with bcrypt. Session tokens are cryptographically secure and time-limited.
CSRF & XSS Protection
All forms use CSRF tokens. Content Security Policy headers prevent script injection.
Threat Response: April 2026
In April 2026, Anthropic disclosed a model capable of discovering software vulnerabilities at scale across every major operating system and writing working exploits for them. The capability class will proliferate within 12–18 months. This changes the security landscape for every organisation that stores data on infrastructure it does not control.
Village’s architecture — small attack surface, sovereign hosting on EU and NZ infrastructure, no US cloud dependencies — means we are not in the blast radius of the mass-exploitation scenarios this capability enables. We have taken specific steps to strengthen an already defensible position.
Encryption at Rest
All data on both production servers (EU and NZ) is encrypted using AES-256-CBC via Percona Server for MongoDB. Physical access to the hardware would not yield readable data without the encryption keys. Completed April 2026.
48-Hour Patch Cycle
When vulnerabilities are disclosed in Linux, Node.js, MongoDB, or Nginx, we apply patches within 48 hours on both servers. Our two-server architecture makes this tractable — we can patch both servers in hours, not the months that large enterprises require.
File Integrity Monitoring
Both servers run AIDE (Advanced Intrusion Detection Environment) with daily automated integrity checks against established baselines. Unauthorised file modifications are detected rather than assumed absent.
No US Cloud Dependencies
The US CLOUD Act gives US authorities the power to compel disclosure of data held by US companies, regardless of where the data is physically stored. No US-owned cloud hosts Village or holds its data. Hosting on EU (OVH France) and NZ (Catalyst Cloud) sovereign infrastructure addresses both legal compulsion and the security risks that now compound it.
For a detailed analysis of the threat landscape, read Mythos and the Economics of Cyberattack and the AI Governance series.
What We Have Introduced
Following an independent security assessment, three features have been added to strengthen the security of every Village.
Two-Factor Authentication (2FA)
A second verification step when you log in — a code from an authenticator app on your phone. Even if your password is compromised, your account remains protected.
- Easy setup — scan a QR code with any authenticator app
- Backup codes — eight single-use recovery codes in case you lose your device
- Village policy — your administrators can set 2FA as optional, recommended, or required
Security Awareness Check
A brief five-question questionnaire each quarter when you log in. Topics include recognising phishing emails, password management, shared device safety, and suspicious links.
- Educational, not punitive — no consequences for wrong answers
- Takes about two minutes — five questions, one from each category
- Earn a badge — completing the check awards a quarterly security awareness badge
AI-Moderated Discussions
For important community decisions, AI provides neutral, factual context to help inform the debate.
- AI briefing — a neutral summary of background information, approved by a moderator
- Comment classification — labels comments as factual claims, opinions, or questions
- Discussion summary — a neutral summary of the debate, generated and approved by moderators
- Guardian Agents — every factual claim is verified against source material and labelled with a confidence badge before you see it
What We Don't Disclose
Transparency is important, but so is operational security. We deliberately don't publish certain details.
This page tells you what we protect and what principles guide us. The how remains appropriately confidential.
Email Decision Record
Email Decision Record, our service for deciding on outgoing email and recording each decision, has its own security page. It covers the keys each organisation holds, signed and timestamped receipts, checking records without us, the exact mailbox permissions it asks for, and where its data is held.
Email Decision Record security · Email Decision Record service status
Reporting Security Issues
We take security reports seriously. If you discover a potential vulnerability:
Responsible Disclosure
- Email security concerns to: security@mysovereignty.digital
- Include detailed reproduction steps if possible
- Allow reasonable time for us to address the issue before public disclosure
- We commit to acknowledging reports within 48 hours
Questions About Security?
We're happy to discuss our security approach. Contact us for more details about how we protect your community.
Security is an ongoing commitment, not a one-time achievement. We continuously review and improve our practices.
Last updated: March 2026