AthenaLegal & Transparency

Athena Beta · Evaluation Sandbox

Incident Response & Breach Notification

How to report a security problem, how we respond, and what we commit to doing if data in the Athena beta is exposed.

1. What counts as an incident

• Unauthorised access to an account, session or the underlying server.
• Exposure of conversation content, recordings or uploaded files to anyone not entitled to it.
• Loss, corruption or unavailability of data.
• A vulnerability in Athena that could lead to any of the above.
• Material being entered into Athena that should not have been — including classified or OFFICIAL: Sensitive material, or personal information about members of the public. This is an incident even though it is a misuse rather than an attack, because it results in that material being disclosed offshore.
• Compromise of any subprocessor listed in the Data Flows register.

2. How we respond

1. Acknowledge — we confirm receipt of your report within 4 business hours.
2. Contain — revoke sessions, disable affected accounts, isolate the affected host, or take the service offline if that is the safest option.
3. Assess — establish what happened, what data was involved, whose data it was, and whether it is likely to result in serious harm.
4. Notify — see section 3.
5. Remediate — fix the cause, verify the fix, and confirm the codebase change ledger records exactly what was altered.
6. Report — provide affected participants and their agencies with a written post-incident report covering cause, impact, timeline and corrective actions.

3. Notification commitments

Notifiable Data Breaches scheme

Part IIIC of the Privacy Act 1988 (Cth) establishes the Notifiable Data Breaches scheme. Where there is unauthorised access to, unauthorised disclosure of, or loss of personal information that is likely to result in serious harm to any affected individual, and we cannot prevent that harm through remedial action, we must notify both the affected individuals and the Office of the Australian Information Commissioner (OAIC) as soon as practicable. Where we suspect an eligible data breach may have occurred, we must complete an assessment within 30 days.

What we commit to for the beta

• Affected participants and their agency will be notified within 24 hours — and never later than 72 hours — of us becoming aware of an incident affecting their data. This applies whether or not the incident is an "eligible data breach".
• The OAIC will be notified where the NDB scheme requires it.
• Notification will include what happened, when, what data was involved, which jurisdictions it was in, what we have done, what we recommend the recipient do, and who to contact.
• We will not delay notification to complete our own investigation. Partial information delivered promptly is more useful to an agency than a complete report delivered late.
• We will notify even where we are not certain harm will follow. If we are weighing it up, you will hear from us.

4. Offshore incidents

Because inference runs in Czechia and some models are reached through Frontier Access in the United States, an incident may occur at a subprocessor rather than in our own systems. In that case:

• We remain accountable to you under APP 8 — see the Privacy Notice. We will not treat a subprocessor's breach as somebody else's problem.
• Our visibility depends on that subprocessor telling us, and our contractual leverage over them is limited. We are stating this openly because it is a genuine weakness of the current architecture rather than a hypothetical one.
• An incident at a Czech or US provider may also engage that jurisdiction's own breach notification regimes, including the GDPR for the EU-hosted infrastructure. Our assessment is that the GDPR is unlikely to apply to the beta itself — its territorial scope turns on offering services to people in the EU, not on where a server sits, and Athena is not offered to EU data subjects. That position is kept under legal review, and any GDPR obligations of the EU providers themselves are theirs to manage under their own regimes.

5. Reporting a vulnerability

We welcome reports from security researchers and from agency security teams. Please email support@aristosai.com with enough detail to reproduce the issue.

• We will acknowledge your report and keep you informed of progress.
• We will not pursue legal action against anyone who reports a vulnerability in good faith, who does not access or exfiltrate data beyond what is necessary to demonstrate the issue, and who gives us a reasonable opportunity to fix it before disclosing publicly.
• We do not currently operate a paid bug bounty.

6. Known limitations of this plan