Security

Last updated: 2026-05-27

Security is part of how we earn and keep our customers' trust. This page tells security researchers how to reach us, what we commit to in return, and what's out of bounds.

Responsible Disclosure: Our Promise

If you believe you've found a security vulnerability in our service, we want to hear from you. We commit to:

• Acknowledge your report within two business days.
• Investigate and respond with an initial assessment within seven days.
• Fix confirmed issues on a timeline appropriate to severity: critical within 72 hours, high within 30 days, medium in the next release cycle.
• Credit you publicly (if you wish) once the issue is resolved.
• Not pursue legal action against good-faith security researchers who follow this policy.

We take coordinated disclosure seriously and will work with you through the process.

How to Reach Us

Pick whichever channel you're most comfortable with.

Email (PGP-encrypted preferred)

[email protected]

PGP fingerprint: Available on request. Email [email protected] and we will reply with our current key fingerprint and public key over your preferred secure channel.

Plain email (for anyone who doesn't use PGP)

Plain email to [email protected] is fine. We understand not every researcher has PGP set up and we'd rather hear about issues in the clear than not at all.

What to Include in a Report

Help us help you:

• What you found: a description of the vulnerability
• Where: affected URL, component, or system
• How to reproduce: step-by-step, ideally with a proof-of-concept we can run safely
• What an attacker could do: impact assessment, even if just your guess
• How you found it: helps us identify patterns and close similar issues

If you want public credit, include the name/handle you want us to use. If you want to remain anonymous, say so and we'll respect it.

Safe Harbour

We welcome good-faith security research. If you:

• follow this policy;
• make a good-faith effort to avoid violating privacy, destroying data, or degrading our service;
• stop testing as soon as you identify a vulnerability (or are instructed to stop); and
• do not disclose the vulnerability publicly before we've had a reasonable opportunity to fix it (we'll discuss timing with you),

then we will:

• treat your actions as authorized conduct under applicable computer-misuse laws;
• not pursue legal action or report you to law enforcement;
• work with you as a good-faith partner.

This safe harbour applies only to activity permitted by this policy. It does not extend to researchers acting in bad faith, attacking our customers' data, or causing deliberate damage.

Scope

In scope:

• email.achieveit.ca: the client portal (and email.achieveit.ca/admin for the admin console during pilot phase)
• The Railway-hosted public API for email.achieveit.ca (auto-generated *.up.railway.app host during pilot; api.email.achieveit.ca once provisioned)
• achieveit.ca: our marketing site and any subdomains referenced above
• Vulnerabilities in our AI safety controls (prompt injection that successfully bypasses our guardrails, but see "AI-specific rules" below)

Out of scope:

• Our vendors' infrastructure: report directly to them (Railway, Cloudflare, Clerk, Stripe, etc.). Their security pages are linked on our subprocessors page.
• Denial of service: do not test DoS or attempt to disrupt service availability.
• Social engineering: against our staff, contractors, or customers.
• Physical attacks: on our offices, hardware, or personnel.
• Reports from automated scanners without human analysis and a viable exploit path.
• Spam, phishing, or scam content sent through customer mailboxes: report as abuse ([email protected]) rather than security.
• Self-XSS, issues requiring physical access, or issues in out-of-date browsers.
• Missing security headers or best-practice misses with no demonstrated impact: we track these internally.
• Customer misuse: if a customer is using our service in ways that violate our Acceptable Use Policy, report it to [email protected].

AI-Specific Rules

Prompt injection testing is welcome but must be done carefully:

• Use your own test tenant. Do not send injection payloads into mailboxes of other customers.
• Attack your own data. If you're probing whether the agent can be tricked into exfiltrating data, seed the data yourself in your test tenant.
• No real exfil. If your proof-of-concept requires sending data out, send it to an address you control, not a third party.
• Stop at "it worked." The goal is to demonstrate the vuln, not to keep going.

We're actively interested in novel prompt-injection classes, memory-poisoning patterns, and cross-tenant leakage paths.

What We Won't Offer (Today)

• No bug bounty program or cash rewards at MVP. We will consider launching one once we have the triage capacity to handle volume fairly. In the meantime: a thank-you, public credit (if wanted), and sometimes a swag gift.
• No extended response windows for researchers who demand them. We'll work with you in good faith; we won't negotiate under pressure.

Our Own Security Posture

If you're researching us and want to understand our posture before engaging:

• Application security: web-app-security.md
• Supply chain: supply-chain.md
• Prompt injection defense: prompt-injection-defense.md
• Incident response: incident-response.md
• Backup and DR: backup-dr.md
• Admin access: admin-access.md

We publish our architecture and security thinking in the open because a service handling your email should be inspectable.

Hall of Fame

Security researchers who have made responsible disclosures to us:

(Empty at launch. We'd love for yours to be the first entry.)

Contact Summary