Responsible Disclosure

AKADATA LIMITED welcomes responsible disclosure concerning software and products for which AKADATA is actually responsible.

We actively use AI in engineering, testing and investigation, and we recognise that AI-assisted security research can be useful.

However, AI does not turn indiscriminate scanning, automated red-team activity, unsolicited penetration testing, destructive testing, or irresponsible public disclosure into responsible security research. The distinction is made on behaviour, not on the tool used.

AI is a tool. Responsibility still belongs to the person using it.

We are not attacking AI itself, and we do not describe all automated scanning as criminal or unlawful. We are describing what counts as responsible research.

The normal coordinated process is straightforward:

1. Determine who actually maintains the affected component.
2. Report privately to the responsible maintainer or vendor.
3. Provide enough evidence to reproduce and understand the issue.
4. Avoid unnecessary access to systems, accounts or data.
5. Avoid destructive testing, persistence, credential collection, denial of service or disruption.
6. Give the maintainer a reasonable opportunity to investigate and remediate.
7. Coordinate any eventual publication rather than publishing exploitable details immediately.
8. Minimise disclosure of personal data, credentials, secrets and unrelated infrastructure information.
9. Stop testing once sufficient evidence of the vulnerability has been obtained.

AKADATA has not set a fixed 30/60/90-day disclosure deadline. The recognised process is coordinated disclosure, not “find something and post it immediately.”

Irresponsible disclosure can harm:

• • users already running the affected software
• • downstream distributions
• • upstream maintainers
• • infrastructure operators
• • people whose data may be exposed
• • the wider open-source community

A public exploit demonstration before the responsible maintainer has had a reasonable chance to act can turn useful research into additional risk.

Finding a vulnerability is useful. Publishing a weapon before the people responsible have had a chance to repair it is not.

AKADATA uses AI extensively and regards it as a valuable engineering tool, including in security work. That position is stable.

What AKADATA does not approve of:

• • pointing autonomous security agents at systems without permission
• • mass AI-generated exploit attempts
• • unsupervised vulnerability probing
• • treating public internet presence as permission to penetration-test
• • automated credential attacks
• • destructive proof-of-concept testing
• • collecting data merely to demonstrate that it could be collected

“The model did it” is not a security methodology and it is not a transfer of responsibility.

A researcher remains responsible for what their tools do. Conversely, passive observation and legitimate normal use should not be falsely labelled as penetration testing.

Unless separately authorised, do not:

• • run denial-of-service tests
• • perform volumetric testing
• • brute-force credentials
• • send phishing or social-engineering attempts
• • install persistence
• • alter or destroy data
• • download data belonging to other people
• • access accounts that are not yours
• • upload malware
• • pivot to other hosts
• • intentionally degrade services
• • conduct physical attacks
• • test third-party infrastructure merely because Saphira uses it

This is a statement of what lies outside the disclosure process, not a legal claim.

Not every unexpected result is a vulnerability.

Saphira cannot eliminate:

• • incorrect administrator configuration
• • deliberately weakened permissions
• • exposed passwords
• • open firewall rules created by the operator
• • unsupported modifications
• • ignored warnings
• • insecure application configuration installed by the user

Some problems remain, in traditional BOFH terminology, between chair and keyboard.

That is not an excuse to dismiss reports. Genuine evidence is still reviewed on its merits, and a real Saphira defect is a real Saphira defect regardless of how the reporter found it.

Please include:

• • affected Saphira release and version
• • affected component or package
• • package version
• • concise description
• • reproduction steps
• • expected behaviour
• • observed behaviour
• • security impact
• • relevant logs or output
• • minimal proof of concept where necessary
• • whether upstream has already been contacted
• • upstream issue or advisory identifier where one exists
• • reporter contact details
• • any desired attribution name

Do not send:

• • stolen credentials
• • unnecessary personal information
• • bulk database dumps
• • unrelated customer data
• • destructive exploit output

Redact secrets where practical.

AKADATA LIMITED does not operate a bug bounty programme.

Reports are welcome. There is no payment entitlement for:

• • finding a vulnerability
• • reporting a vulnerability
• • running automated scanners
• • sending AI-generated findings
• • providing unsolicited penetration-test results

A report is not commissioned work and does not create a contract or support engagement. Submitting a report is not an invoice.

Non-responsible disclosure will take its course.

Activity outside this policy is not covered by the responsible-disclosure process and may instead be handled through the ordinary security, abuse, provider, contractual or legal processes appropriate to the circumstances. This is a description of where a report stops being coordinated disclosure — not a threat, not a promise of prosecution, and not a claim under the Computer Misuse Act.

Use /bugs for ordinary faults such as:

• • package bugs
• • broken functionality
• • documentation errors
• • regressions
• • service failures

Use Responsible Disclosure when premature public reporting could materially increase security risk. A genuine security issue should not be filed in the public bug tracker.

Report an ordinary bug →

Use the address below for private reports, and follow the process above. Do not copy exploitable details into the public bug tracker or elsewhere.

Security contact
security@akadata.ltd

A machine-readable policy will be published at /.well-known/security.txt; its Policy field will point to this page.

Security overview →