Transparency · Security
Security posture.
The Foundation holds some of the most sensitive data a platform can hold: private relationships, Circle messages, long-running conversations with the companion. This page is an account of how we protect that data, how we find problems, and how we respond when something is wrong.
We prefer specificity to vagueness. Where a commitment is not yet true, we mark it as forthcoming. We will not claim a posture we have not earned.
- Encryption
- At rest and in transit
- Pen test cadence
- Annual from year two
- Disclosure
- hello@elitesgen.org
- Incident history
- Published from year one
1
Encryption.
All network traffic is TLS-encrypted with modern cipher suites; HTTP is refused. All data at rest is encrypted on disk. Circle messaging, in particular, is designed for end-to-end encryption so only the participants can read the contents, not us. Where end-to-end is not yet feasible (for example, when the companion needs to reason about context, or when moderation review is required), the exception is documented, the scope is narrowed, and the reason appears in the privacy commitment.
2
Authentication.
Accounts support multi-factor authentication. Passkeys are the recommended primary method; time-based one-time codes are supported as a fallback. Sessions are rotated on sensitive events (password change, MFA change, suspicious login). Users can see and revoke active sessions from settings.
Passkey-first
Passkeys (WebAuthn) are the recommended sign-in. They are phishing-resistant and do not depend on a password reaching our servers.
MFA supported
Time-based codes via standard authenticator apps. SMS MFA is de-prioritised due to SIM-swap risk.
Session hygiene
Sessions are short-lived by default, extended by legitimate use, and rotated on credential changes. Dormant sessions expire.
Password hygiene
Passwords stored as modern-algorithm hashes. Breach-list checks on signup and password change.
3
Access controls.
Access to production systems follows least-privilege. Staff access is role-based, time-bound where possible, and logged in full. Sensitive operations (data access for support, account recovery, moderation review) require explicit approval from a second person and produce an audit trail available to the affected user on request.
Role-based access control
No shared accounts. Engineers, support, and moderators have distinct roles with distinct privileges.
Least privilege
Default role grants the minimum needed to do the job. Elevated access is requested, approved, scoped, and expires.
Full audit logs
Every sensitive action is logged with actor, timestamp, justification, and target. Logs are tamper-evident.
Human-in-the-loop for sensitive ops
Account recovery, data access for support, and moderation actions that affect an account require a second-person approval.
4
Vulnerability management.
We combine continuous automated scanning with periodic human review. Dependencies are scanned daily and patched on a risk schedule. Code is reviewed before merging, with security- sensitive changes reviewed by a second engineer. An independent third-party penetration test will be performed annually, beginning year two.
Dependency scanning
Automated scanning of our dependencies, daily. Critical vulnerabilities trigger an incident channel and a time-bound patch SLA.
Code review
Every change reviewed before merging. Security-sensitive changes require a second reviewer.
Static and dynamic analysis
Static analysis runs in CI. Dynamic analysis runs against staging pre-release.
Annual third-party pen test
Independent penetration test beginning year two, scoped to cover authentication, authorization, and data isolation. Findings summarised in the annual transparency report.
5
Incident response.
When a material incident happens, users affected are notified directly, not through a press release. A public post-mortem is published on a reasonable timeline; no post-mortem is sacrificed to speed. An incident history will appear on this page once the Foundation is operational. Pre-launch, there is no history to publish. We will not invent one.
Detection
Infrastructure alerting and anomaly monitoring across the platform. Reports from users and researchers are treated as first-class signals.
Communication
Directly to affected users. A timeline of known-at-the-time facts, what is not yet known, and what users should do.
Post-mortem
Root cause, timeline, remediation, and what changed in our systems so the same incident cannot happen the same way again. Published here.
Incident history
A running record will appear on this page from year one. Material incidents are disclosed; near-misses are disclosed when there is a useful lesson in them.
Pre-launch note
As of 2026, the Foundation is pre-launch. No incidents are recorded because no users have been served. The incident history will begin accumulating from the day we go live, including incidents that affect zero users but are worth learning from.
6
Responsible disclosure.
Security researchers are welcome. If you believe you have found a vulnerability, tell us at hello@elitesgen.org. We acknowledge receipt within three business days, commit to a reasonable timeline for remediation, and credit researchers in the transparency report with their consent. We do not pursue legal action against good-faith research that follows the guidelines below.
Scope
Production services operated by the Foundation and its subsidiary. Out-of-scope: social engineering, physical attacks, denial-of-service.
Good-faith guidelines
Do not access, modify, or exfiltrate user data beyond what is needed to demonstrate the issue. Do not disrupt service. Report promptly.
Bounty program
A paid bounty program is planned once the Foundation has a full fiscal year of operation and a budget for it. Until then, credit and public thanks.
PGP
A PGP key for encrypted reports will be published on this page alongside the first transparency report.
Read the transparency report.
The annual transparency report is where security incidents, government requests, and enforcement actions are accounted for. The first publishes at year one.