Security Handling
Effective July 8, 2026
In plain English: we assume every uploaded email is dangerous and handle it that way — parsed only inside an isolated, locked-down worker, never executed, and deleted after analysis. This page explains how we protect you and your data.
Every upload is treated as hostile
Suspicious emails frequently contain malicious links and attachments, so we assume every uploaded file is hostile and design around that assumption. The public website never parses an uploaded file; it only talks to our API.
Isolated, least-privilege analysis
- Files are parsed only inside an isolated analysis worker, separate from the website and API.
- The worker runs as a non-privileged user with strict CPU, memory, and time limits, and a hard per-job timeout.
- Attachments are never executed and Office documents are never opened normally — we use static, read-only inspection only.
Safe network checks (SSRF protection)
When we look up domains or check whether a site loads, we guard against server-side request forgery: requests to localhost, private and link-local IP ranges, cloud metadata endpoints, and internal addresses are blocked, and redirect chains are bounded. Reconnaissance is read-only.
Data minimization
- The raw uploaded file is deleted after analysis.
- We store only extracted evidence, file hashes, defanged URLs, and the report.
- We do not store credentials or secrets found inside an email.
- Suspicious URLs are always defanged — never shown as live, clickable links.
Transport, storage, and access
- All traffic is encrypted in transit (HTTPS); stored data is encrypted at rest by our cloud provider.
- Uploaded files go to private storage that is never publicly readable.
- Downloads and uploads use short-lived signed URLs issued only after the server authorizes the request.
- Your data is scoped to your organization, and within it, to you: the reports you submit are visible only to you — not to other members. Access by another organization, or by another member, is denied (a request for someone else's report is indistinguishable from one that doesn't exist). Administrative access to a customer report is limited, justified, and logged.
Accounts and abuse controls
- Registration and email verification are required; multi-factor authentication is supported.
- We apply rate limits, concurrency caps, and quota controls, and we can disable abusive accounts.
- Security-sensitive actions are recorded in an audit log.
Expert-reviewed, continuously updated detection
Our detection is built and tuned by experienced security engineers and refined as new phishing techniques appear, so the answer you get reflects current, human-vetted judgment rather than a static or black-box score. Changes to detection are human-confirmed: a customer's submission never silently and automatically changes how the Service scores anyone else's messages, and our AI narration layer explains evidence but does not decide verdicts or write detection rules on its own.
Responsible disclosure
We welcome reports from security researchers. If you believe you have found a vulnerability, please email security@noetis.us with enough detail to reproduce it. Please give us a reasonable opportunity to fix the issue before public disclosure, and do not access or modify other users' data, degrade the Service, or run automated attacks. We will not pursue good-faith research that respects these guidelines.
Limitations
No service is perfectly secure, and our analysis is an assessment based on available evidence — not a guarantee. Noetis Phish Report complements, and does not replace, your email-security tooling and your own judgment.
Contact
Security questions or reports: security@noetis.us.