amber.systems security research and vulnerability disclosure policy

Version 2026-08-18 - last updated 18 August 2026

1. Purpose

amber.systems welcomes good-faith security research. This policy defines the systems we authorise researchers to test, the safeguards that protect customers and other people, how to report vulnerabilities, and the commitments amber systems ltd makes to researchers who follow it.

This policy is intended to remove ambiguity. It authorises techniques, not access to other customers’ accounts or data.

2. In-scope systems

Subject to this policy, amber systems ltd authorises good-faith security research against:

• the public website at amber.systems and public endpoints directly used to serve it;
• console.amber.systems, including authenticated functionality, APIs and workflows;
• publicly documented first-party API endpoints and API hostnames operated by amber.systems; and
• any other asset expressly identified as in scope in this policy, our public documentation or our security.txt file.

You may create and use multiple accounts, tenants, resources and test datasets that you control. You may test whether one account or tenant you control can access another account or tenant you control.

3. Authorised techniques

The authorisation includes reasonable:

• manual and automated scanning, crawling and enumeration;
• fuzzing and malformed-input testing;
• request, header, token and protocol manipulation;
• testing of authentication, authorisation, session handling, tenant isolation and rate limits;
• attempts to bypass access controls using only accounts, identifiers, objects, credentials, sessions, resources and data that you own or have express permission to use;
• interoperability and reverse-engineering work; and
• creation of test accounts, integrations, API clients and controlled test data.

Testing must remain non-destructive and proportionate. A technique is not prohibited merely because it bypasses or attempts to bypass a technical control. The boundary is whether the activity affects accounts, systems, resources or data outside your permission, causes material harm, or breaches another condition of this policy.

4. Customer and third-party data

You must:

• confine authenticated, authorisation-boundary and data-access testing to accounts, tenants, resources and data that you own or have express permission to use;
• never intentionally query, enumerate, inspect, retrieve, use, alter, delete, copy, retain or disclose another customer’s or another person’s account, tenant, resources, secrets, content or data, even where doing so would provide stronger proof of impact;
• never use another person’s credentials, authentication tokens, sessions or accounts without express permission; and
• never intentionally change another person’s account, permissions, settings, data or resources.

If another customer’s or another person’s data is returned or displayed unexpectedly:

1. stop the relevant test immediately;
2. do not inspect the data beyond recognising that it is not yours;
3. do not make further requests to expand or confirm the access;
4. do not copy, screenshot, retain, publish or disclose the data;
5. promptly delete any incidental local copy, capture or log entry containing it; and
6. report the exposure using redacted technical evidence, such as the endpoint, method, timestamps, request or trace identifiers, response structure, and reproduction steps using accounts and data you control.

An unsolicited or unavoidable display of another person’s data will not by itself place you outside this policy where you did not intentionally seek it and immediately follow the steps above. This does not authorise access to that data.

5. Out-of-scope and prohibited activity

This authorisation does not extend to:

• accounts, tenants, resources, secrets, content or data belonging to another customer or person;
• systems, networks or data belonging to our clients, suppliers, hosting providers, payment providers or other third parties;
• subdomains, IP addresses or infrastructure merely because they use the amber.systems name or are technically connected to an in-scope system, unless expressly listed;
• denial-of-service, destructive or high-volume testing likely to impair availability;
• credential stuffing, password spraying or brute-force attacks against accounts you do not control;
• persistence, lateral movement, malware deployment, botnets or code intended to spread or retain access;
• social engineering, phishing, harassment, threats or physical intrusion;
• interception of communications not addressed to you;
• testing that materially degrades or disrupts a service; or
• conduct affecting a third party’s systems or rights without that third party’s permission.

You may test authentication controls using accounts and credentials you control at a non-disruptive volume.

6. Reporting

Report vulnerabilities to security@amber.systems.

Include, where available:

• the affected asset, endpoint and feature;
• a clear description of the issue and likely impact;
• reproduction steps using accounts and data you control;
• relevant request, response, trace or correlation identifiers;
• timestamps and your source IP addresses, where useful for log correlation;
• a minimal proof of concept; and
• any suggested mitigation.

Do not send live credentials, unredacted personal information, malware or large data extracts by ordinary email. Tell us what you need to send and we will agree a secure channel.

We aim to acknowledge a complete report within five Business Days, but this is a target rather than a guarantee. We may ask proportionate questions, request a retest or provide status updates. We will not require you to sign a non-disclosure agreement merely to receive acknowledgement or safe-harbour protection.

7. Coordinated disclosure

Give us a reasonable opportunity to investigate and remediate before public disclosure. Unless we agree otherwise, 90 days after we acknowledge a complete report will normally be considered reasonable.

Earlier disclosure may be appropriate where a vulnerability is already being actively exploited or creates an urgent risk to others. Contact us first where reasonably possible so that we can coordinate protective action.

You may publish accurate research after the coordinated-disclosure period. Do not publish personal information, credentials, secrets, exploit material that creates an avoidable immediate risk, or claims that materially misrepresent our response.

8. Safe harbour and authorisation

Where your activity complies with this policy, amber systems ltd regards it as authorised by us, including for the purposes of the Computer Misuse Act 1990, to the extent that we have legal authority to grant that authorisation.

In such cases:

• we will not initiate or support civil proceedings against you solely because of that activity;
• we will not make a criminal complaint, voluntarily report the activity to law enforcement, or ask law enforcement or another person to investigate or prosecute you solely because of it; and
• we will not ask a hosting provider, platform, employer or other third party to take enforcement action against you solely because of it.

We do not control decisions made independently by the police, Crown Prosecution Service, regulators, courts, infrastructure providers, customers or other third parties. If an authority or third party investigates, charges, prosecutes or otherwise takes action in relation to activity that complied with this policy, we will, where lawfully able, state truthfully and in writing that:

• we authorised the activity under this policy;
• we regard it as good-faith security research; and
• we did not request enforcement action in relation to it.

On reasonable request, we will provide the researcher with a copy of that statement.

Nothing in this policy prevents us from complying with a legal obligation, court order, mandatory regulatory or data-breach notification, or lawful requirement to provide accurate information. We cannot authorise conduct affecting systems, accounts, data or rights over which we lack authority.

9. Requests to stop or change testing

If we reasonably believe testing is causing or creates a credible risk of material harm, we may ask you to pause, stop or modify it. You must comply with a clear request directed to you. The request does not make earlier compliant activity retrospectively unauthorised.

A general rate limit, automated block or technical control does not by itself revoke this policy or make earlier compliant activity unauthorised.

10. Rewards, credit and expenses

This is not a bug-bounty programme. A report does not create an entitlement to payment, reimbursement, employment, a contract or public credit.

Where appropriate, we may offer credit or another acknowledgement with the researcher’s consent. We will not publicly identify a researcher without permission unless required by law.

11. Policy changes

We may update this policy prospectively. The version in force when an activity began applies to that activity, provided the activity continues without a material break and remains compliant with that version. Check the current policy before starting a new testing session or materially changing the nature of your testing.

A change will not retrospectively withdraw authorisation for activity that complied with the policy in force when it occurred.

12. Contact

• Security reports: security@amber.systems
• General enquiries: hello@amber.systems
• Telephone: 01223 230001