Security and Responsible Disclosure

If you believe you have found a security vulnerability in Proof, please tell us.

We welcome good-faith security research carried out responsibly and within the boundaries below.

Our priority is to protect people, farms, records and systems while making it straightforward for legitimate researchers to report problems.

1. How to report a vulnerability

Use ct@proof.ag with the subjectSecurity vulnerability.

Or use the secure reporting form below.

Include where possible

• the affected URL, service or component;
• the type of vulnerability;
• steps to reproduce it;
• what you believe the impact could be;
• whether you accessed any information;
• whether the issue appears to be actively exploited;
• screenshots or request information where useful;
• suggested remediation where you have one;
• how you would like us to contact you.

A clear proof of concept is useful.

Do not collect private information merely to make the report more convincing.

2. If private information is currently exposed

If you believe that:

• private farm information is publicly accessible;
• another user’s account can be accessed;
• permissions can be bypassed;
• credentials or secrets are exposed;
• a Proof Record has been altered without authority;
• a live breach may be occurring;

stop testing and contact us immediately.

Use ct@proof.ag with the subjectURGENT SECURITY ISSUE.

Do not publish the information or share it with anyone who does not need to know.

3. What is in scope

Unless a page or security notice states otherwise, this policy applies to systems owned or operated by PROOF AG LTD, including:

• proof.ag;
• www.proof.ag;
• Proof-controlled web applications;
• Proof-controlled APIs;
• authentication and account workflows;
• Proof Record interfaces;
• permission controls;
• public redaction controls;
• Proof-controlled integrations;
• Proof-controlled infrastructure exposed to the internet.

Unsure? Ask before testing.

Only test a system where it is clear that Proof owns or controls it.

4. Third-party services

Proof may use infrastructure or software supplied by another company.

A vulnerability in a third-party provider’s own service is not automatically within Proof’s authority to authorise you to test.

If you identify:

• a weakness caused by Proof’s configuration of a third-party service;
• exposure of Proof information through that configuration;
• a Proof integration that defeats Proof permissions;

you may report that to Proof.

If the vulnerability exists entirely within the third party’s product and is unrelated to Proof’s configuration, use that provider’s vulnerability-disclosure process.

Do not test another company’s infrastructure merely because Proof uses it.

5. Good-faith research

Proof considers security research to be good faith where you:

• act to improve security;
• test only systems within scope;
• minimise harm;
• respect privacy;
• access only what is necessary to confirm the vulnerability;
• stop if you encounter private information;
• report the issue promptly;
• do not exploit the vulnerability for commercial, personal or malicious advantage;
• give Proof a reasonable opportunity to investigate and remediate.

6. Authorisation and safe harbour

To the extent that PROOF AG LTD has authority over the relevant system, Proof considers research conducted in good faith and in accordance with this Policy to be authorised by Proof.

Where you comply with this Policy, Proof will not:

• initiate civil legal action against you solely for that research;
• seek prosecution or refer you to law enforcement solely because you performed that compliant research;
• assert that bypassing a Proof technical measure within the permitted research was itself malicious activity.

If your activity is consistent with this Policy but accidentally causes a minor unintended consequence, contact us promptly.

We will consider:

• your intent;
• whether you stopped;
• whether you reported promptly;
• whether you attempted to minimise harm.

Limits of this safe harbour

Proof cannot:

• authorise access to systems it does not control;
• waive another person’s rights;
• grant immunity from applicable law;
• bind law enforcement, regulators or third parties;
• authorise conduct prohibited by another organisation.

If you are uncertain whether planned activity is within scope, contact Proof before performing it.

7. Use your own test data

Where possible, conduct testing using:

• your own account;
• test accounts you created;
• test Proof Records you created;
• synthetic information;
• information expressly provided for security testing.

Do not deliberately target real farms, contributors, customers or private records.

8. Minimise access

If a vulnerability allows access to information you should not be able to see:

Stop once the issue has been confirmed.

Do not continue browsing to determine how much more data is available.

Do not:

• enumerate records;
• browse additional accounts;
• download datasets;
• copy complete files;
• inspect unrelated records.

Capture only the minimum information necessary to demonstrate the issue.

9. If you encounter personal or farm information

Do not:

• retain unnecessary copies;
• publish it;
• share it;
• use it for another purpose;
• attempt to identify additional people or farms.

Where evidence is needed for the report:

• redact sensitive values;
• use screenshots only where necessary;
• minimise captured data;
• tell us what was accessed.

After Proof confirms that the report has been received, securely delete unnecessary copies unless we ask you to retain specific evidence temporarily.

10. Do not re-identify protected records

Security research does not authorise unrestricted attempts to identify farms or people from privacy-protected Proof outputs.

Do not:

• combine outputs with external datasets to identify a farm;
• repeatedly filter groups to isolate a holding;
• use differencing attacks against real production data;
• reconstruct suppressed values;
• publish inferred identities.

If you discover a re-identification weakness incidentally or using synthetic/test data, report it.

If you believe responsible re-identification testing is necessary, ask Proof for written authorisation and a controlled test environment first.

11. Permitted testing

Subject to these Rules, reasonable testing may include:

• examining publicly accessible application behaviour;
• testing your own account;
• testing access controls between accounts you control;
• testing input validation;
• testing authentication and session handling;
• testing common web vulnerabilities;
• testing API authorisation using your own data;
• testing whether private/public boundaries work correctly using your own test records;
• reporting exposed secrets or configuration errors;
• testing rate limits at a low and non-disruptive level;
• testing redaction against synthetic information.

Use the least intrusive method capable of confirming the issue.

12. Prohibited testing

Do not conduct:

• denial-of-service attacks;
• distributed denial-of-service attacks;
• traffic flooding;
• resource-exhaustion attacks;
• destructive testing;
• deletion of real data;
• modification of real Proof Records without authority;
• ransomware;
• malware deployment;
• persistence;
• lateral movement beyond what is required to confirm the issue;
• phishing;
• social engineering;
• voice phishing;
• SMS phishing;
• physical attacks;
• attacks against Proof employees’ personal accounts or devices;
• bribery;
• extortion;
• threats;
• credential stuffing;
• use of leaked-password datasets;
• broad brute-force password attacks;
• spam;
• bulk account creation designed to impair the service;
• supply-chain compromise;
• third-party infrastructure testing without authorisation;
• extraction of real private farm datasets.

13. Automated scanning

Reasonable automated security tools may be used where they:

• operate at a conservative rate;
• do not impair service;
• remain within scope;
• do not automatically exploit discovered vulnerabilities;
• do not bulk-download data;
• respect authentication boundaries.

Do not run aggressive internet-scale scanning against Proof production systems.

If you need higher-volume testing, contact Proof first.

14. Authentication testing

You may test authentication using accounts you control.

Do not:

• attempt to take over another person’s account;
• perform broad password guessing;
• use stolen credentials;
• intercept another person’s authentication;
• bypass multi-factor authentication against a real user.

If you discover a route that appears to allow account takeover, stop after demonstrating it using accounts you control.

15. Access-control vulnerabilities

Access control is particularly important to Proof.

We welcome responsible reports involving:

• horizontal privilege escalation;
• vertical privilege escalation;
• insecure direct object references;
• Record ID enumeration;
• permission bypass;
• unauthorised file access;
• public/private record leakage;
• contributor-role bypass;
• organisation-boundary failures.

Demonstrate the issue using accounts and records you control wherever possible.

16. Proof Record integrity

Do not modify a real Proof Record merely to prove that modification is possible.

Use a test record.

Security issues of particular interest include:

• silent alteration of a locked version;
• incorrect version history;
• unauthorised Addendum creation;
• audit-event removal;
• Record ID collision;
• provenance modification;
• permission-history alteration;
• public/private state confusion.

If you discover that a real record has already been altered without authority, stop and report it immediately.

17. Permission-system vulnerabilities

We particularly want reports where:

• named access applies beyond its intended recipient;
• group-use permission exposes a private source record;
• withdrawn permission remains effective incorrectly;
• public publication occurs without explicit authority;
• one programme permission can be reused for another purpose;
• organisation users can cross account boundaries;
• a public view exposes private fields.

Do not expand access to additional real records merely to demonstrate scale.

18. Redaction vulnerabilities

Redaction failure can expose sensitive information.

Report issues such as:

• hidden text still present in a public document;
• metadata containing exact farm identity;
• EXIF exposure;
• private file URLs embedded in public views;
• exact coordinates leaking through maps;
• redacted text recoverable from document structure;
• cached unredacted content;
• search-engine exposure of private material.

If you discover an active redaction leak, treat it as urgent.

19. Secrets and credentials

If you discover:

• API keys;
• database credentials;
• access tokens;
• signing keys;
• cloud credentials;
• private environment variables;

do not use them beyond what is minimally necessary to determine that they appear valid and sensitive.

Prefer reporting the exposed secret without using it.

Proof will rotate or revoke affected credentials as appropriate.

20. Supply-chain vulnerabilities

If a Proof dependency appears vulnerable:

• identify the component and version where possible;
• explain how Proof may be affected;
• link to relevant public vulnerability information where available.

Do not compromise the dependency provider to prove impact on Proof.

21. Vulnerabilities already known publicly

You may still report a publicly known vulnerability where you have evidence that Proof is exposed.

Please include:

• CVE where applicable;
• affected component;
• affected Proof endpoint;
• evidence of the vulnerable state.

A generic automated report containing only a software-version guess may receive lower priority than a verified report.

22. Low-value reports

The following are generally not security vulnerabilities by themselves:

• missing security headers without meaningful exploitability;
• software-version disclosure with no known impact;
• generic best-practice observations;
• self-XSS requiring the same user to attack themselves;
• logout CSRF with no material consequence;
• email spoofing claims without relevant DNS or exploit context;
• public information intentionally published by Proof;
• rate limiting observations that create no practical security risk.

We may still appreciate useful hardening suggestions, but they may not be treated as vulnerabilities.

23. What to include in a report

A strong report includes:

24. Secure communication

The secure reporting form on this page is served over HTTPS.

For especially sensitive vulnerability information, Proof may provide encrypted communication.

If Proof publishes a PGP key, it must be:

• current;
• monitored;
• linked from this page;
• included in security.txt.

Proof does not currently publish an encryption key.

25. What happens after you report

Proof will:

26. Response targets

These are operational targets, not contractual service levels.

Proof aims to:

• acknowledge credible reports within 3 business days;
• begin triage promptly;
• prioritise critical and high-risk vulnerabilities;
• provide periodic updates where remediation takes time.

We may respond much sooner to an urgent vulnerability.

Complex vulnerabilities may take longer to resolve.

We would rather provide an accurate update than make an unrealistic remediation promise.

27. Severity

Proof may consider:

• exploitability;
• access required;
• data sensitivity;
• number of affected users or records;
• permission impact;
• record-integrity impact;
• persistence;
• detectability;
• availability impact;
• likelihood of re-identification;
• whether exploitation is already occurring.

Proof may use CVSS or another structured method as an input.

The final severity may also reflect Proof-specific context.

28. Critical issues

Examples that may receive critical priority include:

• unauthenticated access to private Proof Records at scale;
• compromise of production signing or administrative credentials;
• ability to alter locked records without detection;
• unrestricted cross-organisation access;
• widespread permission bypass;
• remote code execution affecting production systems;
• mass exposure of private farm identity or exact locations.

Severity depends on the actual circumstances.

29. Personal-data breaches

A vulnerability report may reveal that a personal-data breach has already occurred.

Proof will separately assess:

• what happened;
• what personal information was affected;
• how many people were affected;
• likely consequences;
• containment;
• whether notification to the ICO is required;
• whether affected people must be informed.

The vulnerability reporter is not responsible for making Proof’s regulatory determination.

Where a personal-data breach meets the reporting threshold, Proof must notify the ICO without undue delay and, where feasible, within 72 hours of becoming aware of it.

30. Security incidents

A vulnerability is not necessarily a security incident.

However, if Proof finds evidence that:

• the vulnerability was exploited;
• information was accessed;
• credentials were compromised;
• records were altered;
• service availability was attacked;

Proof will trigger its incident-response procedure.

The vulnerability-disclosure conversation may then continue alongside incident response.

31. Coordinated disclosure

Please give Proof a reasonable opportunity to:

• investigate;
• protect affected users;
• develop a fix;
• deploy remediation;

before publicly disclosing non-public vulnerability details.

Proof will not require indefinite secrecy.

Where public disclosure is appropriate, we will work with you in good faith to agree a reasonable timetable based on:

• severity;
• active exploitation;
• remediation complexity;
• user risk;
• dependencies.

The NCSC recommends ongoing communication with finders rather than ignoring reports or forcing researchers to sign unnecessary NDAs.

32. No mandatory NDA

Proof will not ordinarily require a good-faith researcher to sign a non-disclosure agreement before we will investigate a vulnerability.

We may ask for reasonable confidentiality while active remediation is underway.

A separate NDA may be appropriate only where both sides genuinely need one for additional work beyond ordinary vulnerability disclosure.

33. Retesting

Once Proof believes a vulnerability has been fixed, we may invite the reporter to retest it.

Retesting remains subject to this Policy.

Do not assume that a previous test authorises unrelated testing after remediation.

34. Recognition

Where a valid vulnerability materially improves Proof’s security, we may offer public acknowledgement with the reporter’s permission.

Recognition is optional.

We will not publish:

• your name;
• handle;
• organisation;
• report details;

without appropriate permission.

Proof may maintain an acknowledgements page in future.

35. Bug bounty

Proof does not currently operate a public bug-bounty programme.

Submitting a report does not create an entitlement to payment.

If Proof introduces:

• financial rewards;
• bounty amounts;
• eligibility requirements;

they will be published separately before they apply.

Proof may choose to provide discretionary recognition or reward, but no promise arises from this Policy.

36. Threats and extortion

This Policy protects good-faith research.

It does not protect:

• demands for payment in exchange for not exposing or exploiting a vulnerability;
• threats;
• extortion;
• deliberate persistence;
• sale of private Proof data;
• malicious exploitation.

Report the vulnerability.

Conditional demands are not protected by this Policy.

37. Responsible handling by Proof

Proof will treat vulnerability reports as security-sensitive information.

Access should be limited to people who reasonably need it for:

• validation;
• remediation;
• legal review;
• incident response;
• supplier coordination.

Proof will not publicly identify a reporter merely because they submitted a good-faith security report.

38. Reporter privacy

Proof may process:

• name or handle;
• email;
• organisation;
• vulnerability report;
• correspondence;
• technical information associated with the report.

We use this information to:

• investigate;
• communicate;
• remediate;
• maintain security records;
• protect legal rights.

Read the Website, Enquiries and Recruitment Privacy Notice.

Security reports may be retained for as long as reasonably necessary to:

• investigate and remediate the issue;
• recognise recurring vulnerabilities;
• demonstrate security handling;
• establish or defend legal claims.

Proof should align the exact retention period with its internal retention schedule and Privacy Notice.

39. If you want to remain anonymous

You may submit a report without giving your real name.

We need a workable contact method if you want:

• acknowledgement;
• questions;
• remediation updates;
• recognition.

Anonymous reports will still be assessed on their technical merits.

40. Changes to this Policy

Proof may update this Policy to reflect:

• product changes;
• new domains;
• changes in security practice;
• legal changes;
• experience from vulnerability reports.

The current version must show:

• version;
• effective date;
• last-reviewed date.

Previous versions will be available at /legal/archive.

A policy change does not retrospectively turn research that complied with the applicable published Policy at the time into prohibited conduct.

41. Contact