Security at Detections

Detections is built around explicit trust boundaries, least privilege, isolation between workspaces, and operations that leave evidence. These are architectural controls and product practices, not an independent certification.

Last updated: 25 August 2026
Applies to: The Detections service at detections.app

Security principles

Explicit trust boundaries

Public, authenticated, privileged and service operations are subject to differentiated access policies.

Workspace isolation

Access to resources is authorized server-side and reinforced by isolation controls in the data layer.

Controlled publication

Public interfaces expose only information intended for publication. Private content, drafts and internal data remain subject to access controls.

Auditable operations

Operations that change state require explicit authorization and leave audit evidence.

Vulnerability disclosure

Report a vulnerability

If you believe you have found a vulnerability in Detections, we want to hear about it. Write to the address in the panel beside this page; the rest of this section is what makes a report easier to act on, and what is out of bounds while you look.

What to include

A useful report explains what you did, what happened, what you expected to happen instead, and what the impact could be. Where it applies, it helps to have:

the URL or endpoint affected;
the steps to reproduce it;
the relevant request and response;
a screenshot or a log extract;
the preconditions — the account, role or settings the issue needs;
what an attacker would be able to achieve.

Include only what is needed to show the issue. A report does not have to carry a dump of data to be convincing, and one that does is harder for us to handle safely.

While testing

Test against your own account and your own workspace. The lines below are the ones that separate a report we can act on from an incident we have to respond to.

Test against accounts, workspaces and resources you created and control.
Do not deliberately access information belonging to anyone else.
Do not copy, download or retain other people's data.
Do not modify or delete anything you did not create.
Do not attempt to establish persistence on systems or accounts you do not control.

If you reach another workspace

If you find a flaw that gives you access to another account or another workspace, stop at the point where you have shown that it does. Demonstrate the minimum: do not keep exploring, do not enumerate resources, do not copy or retain what you can see, and do not use the access to reach anything further. Then report it, and say in the report exactly how far you went.

Out of scope

These are not in scope, and testing them is not something this policy covers:

Denial of service, distributed denial of service, load testing and request flooding.
Credential stuffing and brute-force campaigns against accounts.
Spam, and anything that degrades the service for other people.
Social engineering or phishing of our users, our staff or our providers.
Physical attacks against people or premises.
Services, repositories and infrastructure that belong to third parties, including the public repositories detection content comes from.

Coordinated disclosure

If you intend to publish anything about the issue, say so in your report so we can coordinate where that is reasonably possible. We will not ask you for an indefinite embargo, and we will not offer a resolution date we have not shown we can meet.

Detections does not currently operate a vulnerability rewards programme. We appreciate reports made in good faith and will review reproducible findings that affect the service.

What this policy covers

This policy describes how to report a vulnerability in the Detections service and how we ask you to test while you look for one. It does not authorize access to accounts, data or systems belonging to other people, or any activity outside the scope described above.