AIOrouter Responsible Disclosure Policy
Version: 1.0.0 Effective Date: 2026-05-04 Canonical URL: https://aiorouter.ca/docs/security/responsible-disclosure-policy References:
/.well-known/security.txt(RFC 9116)
§1 — Our Commitment
At AIOrouter, we take the security of our systems and our users' data seriously. We value the contributions of the security research community and are committed to working with researchers to verify and address legitimate security vulnerabilities.
This policy describes:
- What systems and vulnerabilities are in scope
- How to report a vulnerability to us
- What you can expect from us during the disclosure process
- Our commitment to protecting good-faith researchers
§2 — Safe Harbor
When conducting vulnerability research in accordance with this policy, we will not pursue legal action against you for:
- Accessing a system to test or investigate a potential vulnerability
- Circumventing security measures as necessary to demonstrate a vulnerability
- Making a good-faith effort to avoid privacy violations, data destruction, or service interruption
To qualify for safe harbor, you must:
- Report the vulnerability to us before disclosing it publicly
- Avoid accessing, modifying, or deleting data that does not belong to you beyond what is necessary to demonstrate the vulnerability
- Cease testing and notify us immediately if you inadvertently access user data
- Not engage in extortion, ransom, or demands for payment in exchange for vulnerability disclosure
Safe harbor does NOT extend to:
- Criminal acts (e.g., extortion, identity theft, fraud)
- Intentional destruction or corruption of data
- Violations of Canadian federal or Quebec provincial law
§3 — Scope
In-Scope Systems
| System | URL | Notes |
|---|---|---|
| API Gateway | api.aiorouter.ca |
Production API endpoints; all methods |
| Dashboard | dashboard.aiorouter.ca |
User-facing web application |
In-Scope Vulnerability Types
- Authentication/authorization bypass (including API key handling)
- Injection attacks (prompt injection, SQL injection, command injection)
- Cross-site scripting (XSS), cross-site request forgery (CSRF)
- Server-side request forgery (SSRF)
- Insecure direct object references (IDOR)
- Information disclosure (API keys, user data, internal configuration)
- Business logic flaws (pricing bypass, credit manipulation, quota evasion)
- Cryptographic weaknesses (weak ciphers, improper key management)
- LLM-specific attacks (OWASP LLM Top 10)
- Rate limiting bypass
- Cache poisoning
Out-of-Scope
| Category | Reason |
|---|---|
| Denial of Service (DoS/DDoS) | Testing DoS against production degrades service for all users |
| Social engineering | Phishing, pretexting, impersonation of AIOrouter staff |
| Physical security | Physical access to offices, data centers, or devices |
| Spam or mass messaging | Testing email/SMS delivery systems |
| Self-XSS | XSS that requires the victim to paste code into their own console |
| Missing HTTP security headers (without demonstrated exploit) | Informational — will be noted but not treated as a vulnerability |
| Email SPF/DKIM/DMARC configuration (without demonstrated exploit) | Email deliverability configuration |
| Clickjacking on static pages without sensitive actions | Low-risk pages |
| Third-party services | Vulnerabilities in GCP, Stripe, or provider APIs — report to them directly |
§4 — How to Report a Vulnerability
Primary: Email
Send your report to: security@aiorouter.ca
What to Include
For the fastest triage, please include:
- Vulnerability description — What is the vulnerability, and what is its potential impact?
- Steps to reproduce — Detailed, step-by-step instructions (including tools, payloads, and requests)
- Affected endpoint/component — Which URL, API endpoint, or system component?
- Proof of concept — Screenshots, request/response logs, or code that demonstrates the issue
- Your assessment of severity — P0/P1/P2/P3 per our Incident Response Plan
- Contact information — How can we reach you for follow-up? (Optional: PGP key)
PGP Key
If you prefer encrypted communication, our PGP public key is available at /.well-known/security.txt and via security@aiorouter.ca upon request.
Language
Reports accepted in English or French (中文 accepted for Chinese-speaking researchers).
§5 — What to Expect
Our Commitment
| Timeline | Action |
|---|---|
| Within 48 hours | Acknowledgment of receipt with incident tracking ID |
| Within 7 days | Initial triage and severity classification |
| Within 14 days | Status update (confirmed, investigating, or not applicable) |
| Within 90 days | Remediation and coordinated disclosure (from acknowledgment date) |
Severity Classification
We use the same P0–P3 severity levels as our Incident Response Plan:
| Severity | Examples | Reward (Hall of Fame) |
|---|---|---|
| P0 — Critical | RCE, mass data exfiltration, auth bypass to admin, API key compromise | 🏆 Top-tier acknowledgment |
| P1 — High | SQL injection, SSRF to internal services, significant PII disclosure | 🥇 High acknowledgment |
| P2 — Medium | XSS, CSRF on sensitive endpoints, minor information disclosure | 🥈 Standard acknowledgment |
| P3 — Low | Missing security headers, clickjacking on non-sensitive pages | 🥉 Basic acknowledgment |
If We Disagree on Severity
If you believe we have misclassified the severity of your report, please reply to the incident thread with your reasoning and additional evidence. We will re-evaluate and respond within 7 days.
§6 — Coordinated Disclosure
Public Disclosure Timeline
- Default: 90 days from acknowledgment date, or upon mutual agreement
- Extension: We may request up to 30 additional days if remediation requires complex infrastructure changes
- Early disclosure: By mutual agreement only
- Researcher may disclose early: If we fail to provide a status update within 30 days, or if we explicitly state we will not fix the vulnerability
Disclosure Guidelines
When publishing your research:
- Provide us 7 days advance notice of your intended publication date
- Share a draft so we can verify factual accuracy
- Do not include user data, API keys, or other confidential information obtained during testing
§7 — Hall of Fame
We publicly acknowledge researchers who have made responsible disclosures (with their consent). The Hall of Fame is maintained at:
https://aiorouter.ca/docs/security/hall-of-fame
To be listed, please indicate in your report whether you would like to be acknowledged and how you would like your name/alias to appear.
§8 — Legal
- Governing Law: This policy is governed by the laws of the Province of Quebec and the federal laws of Canada.
- PIPEDA Compliance: All vulnerability reports involving personal information are handled in accordance with PIPEDA breach notification requirements.
- No bounty payments: AIOrouter does not currently offer monetary bug bounties. We offer public acknowledgment in our Hall of Fame. This policy may be updated to include bounties in the future.
- Right to modify: We reserve the right to modify this policy at any time. Changes will be reflected in the version date and canonical URL.
Related Documents:
docs/incident-response-plan.md— Full incident response proceduresdocs/security/post-mortem-template.md— Post-incident analysis template/.well-known/security.txt— Machine-readable security contact (RFC 9116)