Section42 AI · Security
Section42 AI — Vulnerability Disclosure Policy
Version 2026-10-03. Section42 AI is run by a small team led by its founder. This policy says how to tell us about a security problem, what we will do and how fast, and what we ask of you. It is a promise we can keep at our size, stated plainly rather than a larger company's policy copied over.
1. How to report
Email info@aihousers.com with "SECURITY" in the subject line. You will reach the founder directly; there is no ticket queue in front of them.
Include what lets us reproduce it: the URL or route, the steps, what you expected and what happened, and the account or organization you used. Screenshots and request/response captures help. Do not include tenant documents or personal data from anyone's file in the report; a redacted example is enough.
If the report itself is sensitive, say so in the first line and we will arrange an encrypted channel before you send details.
2. What is in scope
- The product at section42ai.com: the console, the portals, every route under
/api/, sign-in and invitations, and the document pipeline behind an upload (scrubbing, de-identification, review, audit packet). - The hosted infrastructure we control: the application container, its volume, the database, the environment configuration.
- The regulatory data service at askhouser.com as used by this product.
Out of scope: our providers' own platforms (Railway, Supabase, Clerk, Anthropic, Resend, Sentry, Vercel) except for the way we have configured them; social engineering of the founder or of any customer; physical attacks; denial of service; anything that requires a leaked credential you were not given.
3. What we ask of you
- Do not access, alter or keep anyone's tenant data. If a bug exposes another organization's documents or findings, stop at the first proof (one record, one page) and tell us. Do not download, share or hold it.
- Test with your own account and organization, or one we set up for you.
- No denial-of-service, no automated scanning at a rate that degrades the service, no spam through our email notices.
- Give us the chance to fix before you publish: 90 days from your report, or sooner once we confirm the fix is live. We will ask for more time only if a fix genuinely needs it and will tell you why.
4. What we promise
| Step | Our commitment |
|---|---|
| Acknowledge | Within 2 business days of your email, from the founder |
| Triage and severity | Within 5 business days: what we understand the issue to be, how serious we think it is, and what we plan to do |
| Fix | Critical (tenant data of another organization exposed; authentication bypass; a document reaching the AI model in clear text when the organization's de-identification is on): fix started immediately, target 7 days. High (an authorization gap within an organization; a redaction miss on a stored copy): target 30 days. Medium and low: target 90 days. |
| Tell you | When the fix is live, and what it was |
| Credit | With your permission, by name in the changelog. There is no bounty programme; we say so rather than imply one. |
Good-faith research under this policy will not be met with legal action from us. If you followed section 3, you are covered.
5. What we do with a report
A confirmed vulnerability is handled as a security incident under docs/INCIDENT-RESPONSE.md: we work out which organizations and which documents could have been affected (the document access log and the review records make that a query, not a guess), contain it, fix it behind the regression gates, deploy, and write the incident record. If any customer's data could have been exposed, that customer is told, under the incident policy's notification rule, whether or not the report becomes public.
6. Accuracy problems are reportable too
A finding that wrongly accuses a tenant's file is a harm to that tenant. If you see the product state something a document does not support, report it the same way. It is triaged with the same seriousness as a security issue and fixed behind a keyed regression test, which is how every check in the engine already earns its place.
7. Machine-readable contact
The standard security.txt (RFC 9116) is published at https://section42ai.com/.well-known/security.txt with the contact address, a link to this policy at https://section42ai.com/security, and an expiry date one year out, so scanners and researchers find the right door without guessing. The page is rendered from this document.
Machine-readable contact: /.well-known/security.txt