Effective date: May 17, 2026
We welcome reports of security issues from independent researchers, customers, and anyone who runs into something that does not look right. This policy explains how to report, what we commit to in response, and the legal protections that apply when a researcher follows it. If a procurement reviewer is looking for the answer to “does this vendor have a documented VDP with safe harbor?” — this is it.
1. How to report
Email security@lovex.dev with as much detail as you can share without exfiltrating customer data. A useful report typically includes:
- A clear description of the issue and its security impact.
- Steps to reproduce, with screenshots or a short video if helpful.
- Affected URL, endpoint, or component.
- The account or workspace you used during testing, if applicable.
- Your suggested severity (CVSS or rough “critical / high / medium / low”).
We do not currently publish a PGP key. If end-to-end encryption is a hard requirement for your disclosure, mention that in an unencrypted intro email and we will agree on a channel out of band.
2. What you can expect from us
Our commitments to a researcher who reports a finding in good faith:
- Acknowledgment within two business days (Stockholm time) confirming we received the report.
- Triage decision within five business days — we will confirm reproducibility, assign a severity, and tell you whether it is in scope and what we plan to do about it.
- Status updates as we work the fix and at landing.
- Public credit on request after the fix lands. We do not yet maintain a public hall of fame; we will add one when there is enough volume to make it meaningful. Until then, credit appears in release notes if you want it.
- No legal action against you for the testing covered by this policy (see Section 5).
3. Severity and target fix windows
We use CVSS 3.1 as the baseline for severity, adjusted up or down for context (data sensitivity, blast radius, exploitability in our specific architecture). Target timelines from confirmed triage to fix released in production:
- Critical(CVSS 9.0–10.0, or any active exploitation, or anything that exposes another customer’s data) — 7 days, with interim mitigations within 48 hours.
- High (CVSS 7.0–8.9) — 30 days.
- Medium (CVSS 4.0–6.9) — 90 days.
- Low (CVSS 0.1–3.9) — best effort, typically the next scheduled release.
These are targets, not contractual SLAs. If a fix is going to slip a target window, we will tell the reporter and explain why. Customer-specific contractual remedies live in the SLA and individual Order Forms.
4. In scope and out of scope
In scope:
- lovex.dev and every app served from it (
lovex.dev/lova,lovex.dev/pact,lovex.dev/studio). - The agent API at
/lova/api/agent/*and the hosted MCP endpoint at/lova/mcp. - Our DNS, mail (DMARC/DKIM), and TLS configuration on lovex.dev.
Out of scope — testing the following is grounds for us to decline a report and is not covered by safe harbor:
- Denial-of-service, volumetric, or load-based testing against production. If you suspect a DoS issue, describe the theoretical attack rather than demonstrating it.
- Social engineering of staff, customers, or sub-processor employees.
- Physical attacks on offices, datacenters, or personnel.
- Third-party services we depend on (our hosting provider, database provider, payment processor, AI providers, email provider). Report those to the third party directly under their own policy.
- Account takeover or data accessbeyond your own test account. If your finding requires viewing another user’s data to prove, stop and describe the path without executing it.
- Spam, phishing, or anything that interferes with the user experience of real customers.
- Best-practice findings without a security impact — missing security headers on static marketing pages, version disclosures, banner grabbing, weak ciphers on TLS 1.2-only redirects, and similar. We may still appreciate the report; triage timeline does not apply.
5. Safe harbor
When a researcher follows this policy, we treat their testing as authorized and:
- Will not pursue legal actionunder the Swedish Computer Crimes Act (Brottsbalken 4 kap. 9 c §), the EU NIS2 Directive transposed into Swedish law, the U.S. Computer Fraud and Abuse Act, or any equivalent statute in the researcher’s jurisdiction.
- Will not file abuse reportswith the researcher’s hosting provider or ISP for testing covered by this policy.
- Will work with the researcherif a third party (a sub-processor, a customer’s security team) raises a complaint about activity that fell within this policy.
Safe harbor is conditioned on the researcher:
- Reporting the finding to security@lovex.dev before disclosing it anywhere else.
- Not accessing, modifying, or retaining data that is not their own beyond what is necessary to demonstrate the issue.
- Not degrading the service for other users, exfiltrating data, or pivoting from the finding to additional unauthorized access.
- Respecting an embargo while we fix the issue. We aim for the timelines in Section 3 and will agree publication timing with you in writing.
- Acting in good faith.
Safe harbor does not extend to actions taken before this policy was published, to researchers attempting to extort Lovex AB, or to anyone targeting individuals rather than the platform.
6. Coordinated disclosure
We default to coordinated disclosure: the researcher and Lovex ABagree on a publication date that gives us time to fix the issue and customers time to update. For most findings, that’s either the fix-release date or 90 days, whichever is earlier. We will not unilaterally extend an embargo beyond what is needed to ship a fix; researchers may publish if we miss the agreed date without explanation.
7. Changes to this policy
We may revise this policy as our infrastructure or process evolves. Material changes are announced on /trust and dated above. The policy in effect at the time a researcher submitted a finding is the one that governs that report.
8. Contact
Reports: security@lovex.dev
Mailing address: Lovex AB, Sweden. Full registered address available on request at security@lovex.dev.