Security is the product.
One microVM per session. Target-site code never reaches your device.
No cache, cookies, or history persisted. MicroVM storage is destroyed, not reused.
All data in transit encrypted. HSTS preload enabled. Data at rest encrypted.
1. Our commitment
Webatrisk is a security product. Every architectural decision we make starts with the question: "Does this reduce risk for our customers?"
We built Webatrisk on the principle that browsing sessions should be ephemeral and isolated. Your users' devices never execute untrusted code. Target-site content lives and dies inside a hardware-isolated microVM that is destroyed the moment the session ends. No caching, no persistence, no exceptions.
This page is an honest summary of our security architecture, practices, and where we stand on certifications. We update it as our posture evolves. If anything here raises questions, email us at support@webatrisk.com.
2. Architecture
2.1. Session isolation
Each browsing session runs inside a dedicated, hardware-isolated microVM. The microVM has its own kernel, its own filesystem, and its own network namespace. There is no shared state between sessions, and no session can access another session's memory or storage.
2.2. Verified rendering stream
The user's device never executes target-site JavaScript or loads target-site resources directly. Instead, a verified rendering stream strips tracking, rewrites URLs, blocks known-malicious destinations, and delivers a sanitized visual output to the viewer. This is the core of the isolation model.
2.3. Ephemeral storage
All storage within the microVM is session-scoped and ephemeral. When a session ends, the microVM and its entire filesystem are destroyed. There is no reuse of storage between sessions. Each new session starts with a clean slate.
2.4. AI URL classifier
Before a session navigates to a destination, the URL passes through an AI-powered classifier that flags phishing, malware distribution, and other threat categories. Administrators can configure policy-based allow and block lists.
3. Encryption
- In transit: All connections to and from Webatrisk use TLS 1.2 or higher. We enforce HSTS with preload on all domains and subdomains.
- At rest: Account data and billing records stored in our database are encrypted at rest using AES-256.
- Session content: Exists only in microVM memory during the session. Never written to persistent storage, so there is nothing to encrypt at rest.
4. Authentication
- Email one-time passcode (OTP): Users authenticate by entering a code sent to their email. There are no passwords anywhere in the system.
- Session management: Web portal sessions have a 30-minute idle timeout and a 24-hour absolute expiry. Native clients (browser extensions, mobile apps) use OAuth2-style refresh tokens stored in the platform keychain. Sessions are revocable by administrators at any time.
- API keys: Partner and enterprise accounts authenticate API requests with scoped API keys. Keys are stored as salted hashes. Administrators can rotate or revoke keys instantly.
5. Admin security
- Zero-trust access gateway: The admin portal is accessible only through a cloud-based zero-trust access proxy. Operators must authenticate with a verified identity before reaching the portal.
- Allowlisted operators: Only pre-approved individuals can access administrative functions. There is no shared admin account.
- Audit logging: All administrative actions are recorded in an immutable audit log, including who performed the action, when, and from which IP address.
6. Email authentication
- DMARC: Policy set to
p=rejectwith strict alignment. Emails failing DMARC are rejected, not quarantined. - DKIM: All outbound emails are signed with 2048-bit DKIM keys.
- SPF: Published SPF records restrict which servers can send email on behalf of webatrisk.com.
7. Vulnerability disclosure
If you believe you have found a security vulnerability in Webatrisk, please report it responsibly:
- Email: support@webatrisk.com
- We will acknowledge your report within 2 business days.
- We will keep you informed of our investigation and remediation progress.
- We follow a 90-day coordinated disclosure timeline. We ask that you do not publicly disclose the vulnerability before we have had a reasonable opportunity to remediate (90 days, or sooner by mutual agreement).
- With your permission, we will publicly credit you after a fix ships.
8. Incident response
In the event of a confirmed security breach involving personal data, we will:
- Notify affected customers within 72 hours of confirmation, in accordance with GDPR Article 33 and our contractual commitments.
- Provide a clear description of the incident, the data affected, and the remediation steps taken.
- Report to the relevant supervisory authority where required by law.
- Conduct a post-incident review and publish a summary (without compromising ongoing security) to affected customers.
9. Compliance roadmap
- GDPR: Operational today. Privacy-by-design architecture with zero target-site retention, data minimization, and documented processing activities.
- SOC 2 Type II: Planned. We are building toward the Trust Service Criteria for security, availability, and confidentiality.
- ISO 27001: Planned. Information security management system design is underway.
We are honest about where we stand. As a young product, we prioritize shipping real security controls over collecting certificates. Certifications will follow as we scale.
10. Sub-processors
A detailed table of our sub-processors, their purposes, and their locations is published in our Privacy Policy. We review sub-processors at least annually and notify customers before adding new ones.
11. Continuous hardening
- Secret rotation: API keys, tokens, and certificates are rotated on a regular schedule. Rotation is automated where possible.
- Dependency monitoring: We continuously monitor all software dependencies for known vulnerabilities and apply patches promptly.
- CAA records: DNS CAA records restrict which certificate authorities can issue TLS certificates for our domains, reducing the risk of unauthorized certificate issuance.
- Immutable infrastructure: Production systems are deployed from versioned artifacts. There is no SSH access to production workloads in normal operation.
12. Contact
For security questions, vulnerability reports, or compliance inquiries:
Webatrisk FZ-LLC (registration pending)
Email: support@webatrisk.com