Responsible Disclosure

If you find a security issue in Adjudon, we want to hear from you. This page tells you how to report it, what is in scope, what we promise back, and the safe-harbour conditions under which good-faith research will not be met with legal or operational pushback. We do not run a paid bug-bounty programme today. We do publish a coordinated-disclosure policy that meets the response cadence the EU Cyber Resilience Act expects of an in-scope manufacturer.

How to report

Send the report to [email protected] with the subject prefix [security]. Until the dedicated [email protected] channel publishes its PGP key (see What we are working on below), reports go in plaintext email or as a PDF attachment.

A useful report includes:

• A short title and a one-paragraph summary
• The affected surface (api.adjudon.com, app.adjudon.com, adjudon.com, an SDK, or the docs)
• Reproduction steps from a clean state
• The observed impact (data exposure, privilege escalation, integrity break, etc.)

We do not require a CVE, a CVSS score, or a threat model.

What is in scope

In scope	Out of scope
api.adjudon.com — the production API on Fly.io Frankfurt	Third-party-hosted services not operated by Adjudon (Stripe, Resend, Cloudflare, MongoDB Atlas) — report directly to the operator
app.adjudon.com — the dashboard	Customer-deployed agents using the SDK on customer infrastructure
adjudon.com — the marketing site	Social engineering of Adjudon staff or customers
docs.adjudon.com — the docs site	Physical attacks against Adjudon offices or hardware
Adjudon-published SDKs (adjudon, @adjudon/node, etc.)	Denial-of-service / volumetric load testing against production
Authentication and session-management flows	Spam, phishing, or scraping that violates a third-party site's terms
Server-side request forgery, IDOR, injection, deserialization	Reports requiring privileged-network access to reproduce

If you are unsure whether a finding is in scope, send it anyway.

Safe harbour

We will not pursue legal action or operational reprisals against researchers who:

1. Test only against accounts they own or against the free Sandbox tier; do not access another customer's data.
2. Stop the moment they confirm a vulnerability and do not exfiltrate data beyond what is necessary to demonstrate impact.
3. Do not perform denial-of-service or load testing against production.
4. Do not engage in social engineering of Adjudon staff or customers.
5. Coordinate disclosure with us under the timeline below before any public communication.

This safe harbour applies only to security research conducted in good faith. It does not authorise unrelated unlawful conduct. We extend the safe harbour to anyone, anywhere, who reports an issue in good faith.

Severity and response cadence

We acknowledge every report and commit to the following first-response times:

Severity	First acknowledgement	Initial assessment	Target patch
Critical — remote code execution, cross-org data exposure, audit-chain integrity break	within 24 hours	within 72 hours	EU CRA Art. 11 cadence: 14 days
High — authentication bypass, privilege escalation, single-account data exposure	within 48 hours	within 7 days	within 30 days
Medium — non-exploitable misconfiguration, business-logic flaw, weak rate limit	within 5 business days	within 14 days	within 60 days
Low — informational, defence-in-depth	within 10 business days	best-effort	best-effort

The Critical-severity 14-day patch target aligns with EU CRA Article 11 (Reporting obligations of manufacturers), which expects an actively exploited vulnerability or severe incident to be patched within the 14-day window. We hold ourselves to that cadence as a default; we do not yet make a contractual commitment outside it.

Coordinated disclosure

We follow a 90-day coordinated-disclosure window from the date we acknowledge a report:

1. Acknowledgement within the severity-table response time
2. Joint triage with the reporter; severity and impact agreed
3. Patch developed, tested, deployed; reporter invited to verify on Sandbox
4. Disclosure timing agreed jointly — default 90 days; shorter is fine, longer is negotiated for complex or industry-coordinated fixes
5. Public disclosure: CHANGELOG entry, advisory at /security/advisories when published, credit to the reporter unless they prefer anonymity

If we cannot meet the 90-day window, we tell you why before it closes and agree a revised timeline.

What we are working on (honest)

• [email protected] mailbox + PGP key. Coming with the next programme publication; until then [email protected] with [security] in the subject is the path. Watch this page for the fingerprint and switchover date.
• Public security advisories at /security/advisories. Will list resolved advisories with CVE assignments where applicable.
• Bug-bounty programme. No paid bug-bounty today. If launched, the policy will be linked from this page with scope and reward terms.
• CVE-assignment authority. We are not a CNA; CVE assignment is worked through MITRE or our coordinating CSIRT.

We document these honestly so reporters do not arrive expecting a paid programme or a 24-hour SLA we have not committed to.

See also

• Sub-Processors — the full vendor list with geography per row, encryption, and uptime
• Penetration Testing — the pen-test programme status and the scheduled-by date
• Audit Log & Security — the chain formula and the four-step verify algorithm
• Architecture Overview — the production stack and the HTTPS boundary