security@autoscientia.com
Encrypted communication is available on request — say so in your first message and we will arrange a channel and a key. If you would rather not use email at all, tell us and we will find something that works for both sides.
Security
Report a vulnerability
An automated lab runs code it wrote, spends money without asking, and reaches conclusions on its own. If any of that can be manipulated from outside, we want to know — and we would rather hear it from you than discover it ourselves, later, expensively.
Start here
The address
What to include
How to report something
One email is enough. There is no portal, no form, and no triage bot that replies with a ticket number.
The five things that let us act quickly
- What you affected, as specifically as you can.
- The steps to reproduce it, including the environment.
- What you observed, and what you expected instead.
- An assessment of impact, even a rough one.
- How you would like to be credited — or that you would rather not be.
Please do not test against data that is not yours, and do not disrupt service for others. Proof of a vulnerability does not require reaching production data, degrading availability, or using a real person's account.
Scope
In scope
Out of scope
What interests us, and what does not
- autoscientia.com and any service we host on it.
- Authentication, authorisation and access-control weaknesses in our own infrastructure.
- Escape from an experiment sandbox or container.
- Anything that would let an experiment reach the outer boundary — spending beyond a ceiling, contacting a third party, publishing — without human approval.
- Exposure of objectives, held-out evaluations, baselines or run records that should be inaccessible.
- Tampering with run records or scores, including by our own tooling.
- Automated scanner output submitted without any analysis of whether it is exploitable.
- Denial-of-service, load testing, or anything that degrades the service for other people.
- Social engineering of our team, or physical intrusion attempts.
- Findings that depend on a compromised device, browser extension or account.
- Missing best practices with no demonstrated impact — including SPF/DMARC tuning, TLS version preferences, or version disclosure on their own.
- Third-party services we use, which should be reported to them directly.
In return
What we commit to
Reporting a vulnerability is unpaid work that benefits everyone who uses the system afterwards. These commitments are the least we can offer in return, and they are deliberately specific enough to be held against us.
| Commitment | Detail | Window |
|---|---|---|
| Acknowledge | A human confirms we received the report and gives you a named contact | 5 working days |
| Assess | We say whether we agree it is a vulnerability, and our severity assessment with reasoning | 15 working days |
| Plan | A fix timeline, shared with you, or an explanation of why a fix is deferred | With the assessment |
| Update | Progress notes while work is underway, rather than silence until it is done | At least every 15 working days |
| Fix and credit | Notification when the fix is deployed, and credit in our disclosure note if you want it | On deployment |
| Explain delays | If we miss a window, we say so with the reason rather than letting the deadline pass quietly | At the deadline |
Safe harbour
Good-faith research is welcome here
If you make a genuine effort to comply with this policy while researching, we will not initiate legal action against you, and we will say publicly that your work was authorised. Concretely, that means:
- No legal threats
- For research conducted within the scope above, we will not pursue civil or criminal action, nor ask a third party to do so on our behalf.
- No account penalties
- We will not suspend or terminate an account as a consequence of a report made in good faith.
- The honest limit
- This does not cover extortion, data theft, extortion-adjacent disclosure pressure, prolonged service disruption, or anything that harms a third party. Those are not research, and this paragraph does not pretend otherwise.
- Coordination
- We ask for a reasonable window — 90 days as a default — before public disclosure, so that people using the system can update. If we are slow, that window is a negotiation, not a gag.
Process
What happens after you write
Day 0
Your report arrives
Read by an engineer, not a queue. If your message suggests an urgent risk to real user data, it is escalated immediately rather than waiting for the next triage slot.
Day 5
Acknowledged, with a name attached
You get a human contact and a reference. If we need anything to reproduce the issue, we ask now rather than three weeks later.
Day 15
Assessment, in writing
Severity, the affected systems as far as we understand them, whether we agree with your finding, and a fix plan with dates we intend to keep.
Fix
Remediation, with progress notes
We work the fix like any other engineering task with an owner, and you hear about it as it moves — including when it slips.
Done
Disclosure note and credit
A dated note describing what was wrong, what changed, and who found it — published once affected parties have been informed, and after any coordinated window.
Record
Reports we have published
We would rather have an empty page here than a fictional one. This is a log of disclosed findings; if it is empty, nothing has been disclosed yet.
Nothing yet
No published findings
No vulnerabilities have been disclosed under this policy as of 18 September 2026. When one is, it will appear here with a date, a description of the impact, what was changed, and the credit that the reporter asked for — or an explicit note that they asked for none.
The absence of entries is not evidence that nothing exists. Most of what this system does is still being built, and the surface grows with it.
Found something? Tell us first
Give us the chance to fix it properly. We pay in speed, transparency and credit rather than in bug bounties.