Objectives & harnesses
The measurement definitions a campaign is judged against — including held-out objectives the loop is not permitted to see. If these leak to the proposer, the science stops being science.
Trust
Security is part of the experiment
An autonomous lab is a system that runs code, spends money and reaches conclusions without a person watching each step. That makes its security properties part of its scientific validity, not a separate department. This page describes what we protect, what controls are always on, and how to report a problem to us.
Assets
01
02
03
04
What we protect
Four categories, in the order we think about them.
Experiment records
Run logs, artefacts, scores and baselines. Valuable because they are the only complete account of what was tried, including everything that failed.
Credentials & access
Keys to compute, storage and third-party services. These are the assets with the shortest path from a mistake to real-world impact.
Capacity & spend
Compute is the loop's fuel and its budget. Unauthorised consumption is both a security and an integrity problem.
Controls
Always-on, not best-effort
Each control below is a system property rather than a policy. Where we cannot enforce something technically, we say so instead of describing an intention as a guarantee.
| Control | How it works | What it prevents |
|---|---|---|
| Isolated execution | Every trial runs in a fresh container with no shared writable state and no inherited credentials | Cross-trial contamination and one experiment reaching into another's files |
| Least privilege | Trials receive the narrowest role that can complete them; nothing long-lived is mounted into a run | Credential sprawl when thousands of runs execute in parallel |
| Budget ceilings | Compute, time and spend limits are attached before dispatch and enforced by the scheduler | A runaway campaign consuming capacity without anyone deciding to spend it |
| Egress control | Outbound network access from a trial is deny-by-default and explicit per workload | Exfiltration through an experiment that was never meant to reach the internet |
| Immutable records | Run records, scores and failure classifications are written append-only | Silent rewriting of results, including by our own tooling |
| Pinned dependencies | Code, data references and dependency digests are fixed per trial | Results that cannot be replayed because the environment moved underneath them |
| Human gate | Any action with an effect outside the environment requires explicit approval, logged with an identity | Automated systems acting on the world because it was technically possible |
| Audit trail | Who approved what, when, and against which evidence level | Unattributable decisions — the failure mode that makes every later question unanswerable |
Non-negotiable
Two boundaries we do not blur
The inner loop may run without a human between its steps. Nothing may cross the outer boundary without one. Keeping those two statements true at the same time is most of the security design.
- Inner boundary
- Propose, run, evaluate, iterate — automated, sandboxed, budget-limited, fully logged.
- Outer boundary
- Publication, spending beyond a ceiling, contacting a third party, touching real-world systems — human approval, always.
Data
What we hold, and for how long
We deliberately hold very little about people. Most of what we store is about experiments.
- Website visitors
- No analytics, no advertising identifiers, no cross-site tracking. See the Cookie Policy.
- Contact messages
- Held only as long as needed to answer, then deleted — 24 months maximum, usually far less.
- Applicants
- Retained for the duration of the hiring process and up to 6 months afterwards, then deleted unless we agree otherwise in writing.
- Partner research data
- Governed by the specific agreement. Default position: it stays in the partner's environment and we process only what the campaign requires.
- Location
- Primary infrastructure in the European Union. Where a specific workload requires otherwise, it is named in the agreement rather than assumed.
- Your rights
- Access, correction, deletion, restriction and objection — one request to privacy@autoscientia.com is enough.
Supply chain
Sub-processors
We do not publish invented vendor lists. The table below is the current structure of our stack; rows marked to complete are being finalised and will be named here before any partner data is processed in them.
| Function | What it touches | Location | Status |
|---|---|---|---|
| Cloud & compute | Experiment workloads, artefacts, run records | EU | to complete |
| Object storage | Run artefacts and frozen baselines | EU | to complete |
| Contact and hiring correspondence | EU / US | to complete | |
| Font delivery | Visitor IP and user agent, via Google Fonts CDN | Global edge | in use — see Cookie Policy |
Where a sub-processor operates outside the EU/EEA, transfers rely on an adequacy decision or the European Commission's Standard Contractual Clauses with a documented transfer assessment.
Reporting
How to report
Our commitments
In scope
Out of scope
Responsible disclosure
If you believe you have found a vulnerability in anything we operate, we want to hear about it — and we would rather hear it early than read about it later.
security@autoscientia.com
Encryption available on request. If you need a channel other than email, say so in your first message and we will arrange one.
Please include what you affected, the steps to reproduce it, and any evidence you can share safely. Do not test against data that is not yours.
What you can expect
- Acknowledgment of your report within 5 working days.
- An initial assessment, including whether we agree it is a vulnerability, within 15 working days.
- A fix timeline, shared with you, and notification when the fix is deployed.
- Credit in our disclosure note if you want it — and anonymity if you do not.
- No legal action for good-faith research conducted within the scope below.
What we would like tested
- autoscientia.com and the services we host on it.
- Authentication and access-control weaknesses on our own infrastructure.
- Sandbox escape from an experiment container.
- Anything that would let an experiment reach the outer boundary without approval.
- Exposure of objectives, baselines or run records that should be held out.
What is not covered
- Automated scanner output submitted without analysis.
- Denial-of-service testing, load testing, or anything that degrades service for others.
- Social engineering of our team, or physical access attempts.
- Findings that depend on a compromised device, browser extension or account.
- Best-practice observations without a demonstrated impact.
Incident response
If something goes wrong
Five steps, in order, each with a named owner. We would rather publish a boring process now than improvise one later.
01
Detect
Alerting on anomalous spend, failed authorisation, unexpected egress and integrity-check failures on run records.
02
Contain
Revoke credentials, halt affected campaigns, isolate the environment. Containment does not wait for a full understanding.
03
Assess
Establish what data or capability was involved, who is affected, and whether any result produced during the window can still be trusted.
04
Notify
Affected parties and, where the law requires it, the competent supervisory authority — within 72 hours of confirming a personal-data breach.
Step five is learn in public: a dated note describing what happened and what changed, written once the affected parties have been informed. An incident that produces no visible change is an incident we have mishandled.
Honesty
What we do not claim
Security pages are the easiest place on a website to overstate. These are the limits of what the page above means.
- No certification yet. We are not currently certified to ISO/IEC 27001 or audited under SOC 2. If that changes, the certificate and its scope will appear here rather than an implication.
- No independent audit. The controls described are our own account of our own systems. We would like to change that, and will say when we have.
- No guarantee of absence. Nothing here means we cannot be breached. It means we designed for the assumption that we can be.
- No substitute for an agreement. For partner engagements, the security terms in the signed agreement govern, not this page.
Found something that looks wrong?
Tell us before you tell anyone else, and give us the chance to fix it properly.