Security

This page is plain-language about how memo.tax is built to be safe to use. For our compliance posture (PIPEDA, OWASP Top 10, SOC 2 alignment, accessibility), see Compliance. To report a security issue, see §5 below.

We deliberately don’t publish detailed implementation specifics on this page. Enterprise procurement teams who need a security questionnaire response can request one at security@memo.tax.

1. Posture

• All traffic is encrypted in transit; the site is HTTPS-only with HSTS preloading.
• Account data, query history, and embeddings are stored on encrypted volumes.
• Passwords are stored as one-way hashes — we never see, log, or store your plaintext password.
• Sessions are signed and delivered as HttpOnly, Secure, SameSite=Lax cookies. They expire on a fixed schedule.
• Email verification is required before unlocking the full query allowance.
• A bot challenge guards the signup and login forms.

2. Hardening

• Strong security headers on every response: HSTS, Content-Security-Policy, X-Content-Type-Options, X-Frame-Options, Referrer-Policy, Permissions-Policy.
• Rate limiting on the AI endpoint and authentication routes.
• Input validation at the API boundary; output encoded by the templating layer.
• Database queries use parameterised statements throughout — no string concatenation of user input.
• State-changing forms are protected from cross-site posts via signed-cookie session checks and tight CSP form-action directives.

3. AI-specific safeguards

memo.tax is an AI product, but the AI is constrained:

• Citation verifier — fails closed. Every section reference the model produces is checked against the retrieved source chunks. Unsupported references cause the answer to be refused, not served.
• Truncation guard. If the model’s output is cut off mid-thought, we refuse and don’t cache it.
• Prompt isolation. System instructions are not echoed in user-visible output.

4. Operational practices

• Least privilege: production access limited to the operator. Admin operations require explicit authorisation, not just a signed-in session.
• Backups: daily, retained for 30 days, restore tested at least quarterly.
• Audit logging: sign-ins, admin actions, and authentication failures are logged with timestamp and source IP.
• Dependency hygiene: dependency versions are pinned, and security advisories on upstream packages are monitored. Critical CVEs patched within 7 days.
• Secrets management: all keys live in a gitignored environment file owned by the service account — never in source control.

5. Reporting a vulnerability

Found a security issue? We want to know. Email security@memo.tax with:

• A description of the issue and the impact
• Steps to reproduce
• (Optional) Your name and how you’d like to be credited

Our commitments to reporters acting in good faith:

• Acknowledgement: within 48 hours
• Critical issues: fix or mitigation within 7 days
• No legal action against researchers who follow this process and don’t access data beyond what’s necessary to demonstrate the issue
• Credit in our security acknowledgements (with your permission), once the issue is resolved

We do not currently run a paid bug bounty.

6. Out of scope

The following are out of scope for vulnerability reports (please don’t):

• Denial of service / volumetric attacks
• Social engineering of memo.tax staff or customers
• Physical attacks against our infrastructure providers
• Issues affecting users on out-of-date browsers (we support last two major versions of evergreen browsers)
• Reports from automated scanners without a working proof of concept
• Missing security headers on documents that don’t need them (e.g., static assets)