Vulnerability Disclosure Policy

• mindwiki.io and any subdomain we operate.
• api.mindwiki.io — the Vault API.
• ai.mindwiki.io — the MindWiki AI worker.
• inbox.mindwiki.io — the per-account email capture domain.
• The MindWiki iOS app (current TestFlight or App Store build).
• The MindWiki macOS app (current signed.dmg release from mindwiki.io/download).
• The MCP server at api.mindwiki.io/mcp.
• OAuth + Sign in with Apple flows associated with the above.

• Findings against third-party infrastructure (Cloudflare, Vercel, Apple, Stripe, etc.) that don't relate to a specific MindWiki configuration error. Report those directly to the relevant provider.
• Social engineering of MindWiki staff or customers.
• Physical attacks on MindWiki property or personnel.
• Denial of service through volumetric / DDoS traffic.
• Spam, abuse, or content moderation issues — these go through abuse@mindwiki.io instead, see Community Guidelines & Report Abuse.
• Self-XSS, missing security headers without a demonstrated impact, banner-grabbing, host headers reflected by upstream providers we don't control, exposed but unused source-map files, missing rate limits on non-sensitive endpoints, and other findings with no realistic exploit path.
• Issues affecting only outdated app versions where an updated version is already published.
• Findings that require the attacker to already control the victim's device, network, or account.

We won't pursue legal action against researchers who follow these rules in good faith. Anything beyond them — or any conduct outside Acceptable Use — is outside the safe-harbor commitment.

• Only test accounts you control. Don't access, modify, or exfiltrate data belonging to other users. If your proof-of-concept requires touching another user's data, stop and report; we'll create a controlled test environment.
• Use the minimum-impact test that demonstrates the issue. Don't dump databases, mass-download attachments, or pull more data than necessary to prove the issue.
• Don't run sustained automated scanners or fuzzing against production systems. Targeted manual testing is welcome.
• Don't install backdoors, persistence mechanisms, or any tooling that survives the test.
• Don't pivot beyond MindWiki infrastructure.
• Don't exfiltrate or publish vulnerabilities before we've had a reasonable opportunity to fix.
• Don't modify or destroy data. If you accidentally trigger writes, tell us immediately so we can clean up.

• Acknowledgement within 3 business days of your initial report.
• A triage decision within 10 business days — confirmed / duplicate / out-of-scope.
• Status updates at meaningful milestones (fix in progress, fix in staging, fix deployed).
• Coordinated disclosure— we'll work with you on a public disclosure date once a fix is shipped. We default to crediting the reporter unless you ask us not to.
• No legal action for reports made in good faith within the rules above.
• No NDA required for the basic report-and-fix flow. We may ask for an embargo on specifics until the fix is rolled out.

We do not currently offer monetary bug bounties. Recognition takes the form of:

• Public acknowledgement on a Security Researchers page (with your permission).
• MindWiki credit or perpetual Pro / Power entitlement at our discretion, scaled to the severity and impact of the finding.

1. Summary — one paragraph describing the issue, the affected endpoint / flow, and the impact.
2. Reproduction — step-by-step, including any prerequisites (account, device, network).
3. Proof — screenshots, request / response captures, or short videos. Avoid live data; use synthetic if possible.
4. Impact assessment— what an attacker can do, how feasible the attack is, and who's affected.
5. Suggested fix if you have one.
6. Your preferred name / handle for public credit (or your preference to remain anonymous).

We classify findings using a CVSS-aligned scale. Indicative response timelines:

• Critical — full account compromise, cross-tenant data access, unauthenticated RCE on production. Fix in 7 days; out-of-band patch where required.
• High — authenticated cross-account data access, sensitive PII exposure, privilege escalation. Fix in 14 days.
• Medium — single-account compromise paths requiring user interaction, meaningful information leak. Fix in 30 days.
• Low / informational — best- practice issues without clear exploit path. Fix on the regular release cadence.

Our security.txt file is published at /.well-known/security.txt. It points to this policy as the canonical Policy URL and to security@mindwiki.io as the contact. We keep it current.

• Security — overall trust posture.
• Acceptable Use Policy — including service-abuse rules and Coordinated security disclosure.
• System Status — live health if you suspect an active incident.