Athena Beta · Evaluation Sandbox

Beta Data Handling Commitments

What Athena stores, where it is stored, who at Aristos can read it, how long we keep it, how to have it deleted, and what happens to the Prague sandbox when the evaluation ends.

Version 0.1 (draft) Status Draft — pending legal review Applies to Athena beta (evaluation sandbox)

Scope

This page covers the Athena beta only. It sits alongside the Privacy Notice, which sets out your rights under the Privacy Act 1988 (Cth), and the Data Flows register, which sets out which countries your data travels to.

1. What Athena stores

Data	Where it is stored	Notes
Conversation history your messages and Athena's replies	Application database on the VPS (Sydney, Australia)	Retained until you delete the conversation or your account is purged. Deleting a conversation in the interface removes it from the active database
Uploaded files documents, spreadsheets, images	Application storage on the VPS	Extracted text may also form part of prompts sent offshore for inference
Audio recordings plus transcripts and summaries	Application storage on the VPS; processed on the GPU server in Czechia	See the warning in Data Flows — audio always leaves Australia
Stored memory facts Athena retains about you or your work	Application database on the VPS	Viewable and deletable by you in the Memory panel. Included in prompts, so it also reaches the inference provider
Account details name, email, password hash, role	Application database on the VPS	Passwords are stored as Argon2id hashes, never in plain text
Authentication audit trail sign-ins, failures, session revocations, IP addresses	Application database on the VPS	Kept as a security record. IP addresses are personal information
Usage and token logs model used, token counts, cost	Application database on the VPS	Used for capacity and billing. Does not contain message content
Security event log blocked prompt-injection attempts	Application storage on the VPS	May contain fragments of the prompt that triggered the block

2. Who at Aristos can access it

Athena has two roles: user and admin. Administrators can manage accounts, view aggregate usage and cost data, and access the server. Because the application database sits on a server we control, an administrator with server access is technically capable of reading any stored conversation, recording or uploaded file. We would rather state that plainly than imply a technical barrier that does not exist.

Administrator accounts are held by the two co-founders only: Vishaal Singh (CTO) and Steeve Poligadu (Operations). No other person has admin or server access.
We access conversation content only where necessary to operate or fix the service, to investigate a security incident, or where you ask us to.
Administrative actions on accounts are recorded in the audit trail.
Content access requires a specific operational justification before it occurs — fault diagnosis, a security investigation, or your explicit request — and the reason is noted at the time. There is no casual browsing of user content.

Not end-to-end encrypted

Athena is not end-to-end encrypted and is not zero-knowledge. Your conversations are stored in a form the operator can read. Any protection here is administrative and contractual, not cryptographic.

3. Retention

Conversations, uploads, recordings and memory: retained until you delete them, your account is purged, or the beta ends, whichever is first.
Account records: retained until the account is closed, plus any period the law requires.
Authentication and security logs: retained for 12 months — longer than content, so that incidents can be investigated.
Usage and billing records: retained for 5 years as required by Australian tax and corporate record-keeping law.
Backups: daily backups are taken on the Sydney VPS. Because backups live on the same host, a deletion request is actioned in the live database immediately and in backups as they cycle. Off-site backup replication does not yet exist and is listed as a known gap below.

4. Deletion on request

Beta participants can ask us to delete their data at any time, for any reason, without giving a justification.

Email support@aristosai.com from the address associated with your account, or ask your agency contact to relay the request.
We will acknowledge within 5 business days and complete deletion within 30 days.
We will confirm in writing what was deleted, and identify anything we are required to retain and why.

What we cannot delete: prompts already transmitted to Frontier Access or to third-party model providers are subject to those parties' own retention practices and are outside our control. This is one of the reasons the beta must not receive sensitive material.

5. The Prague sandbox

Commitment

When the evaluation ends, or when inference migrates to Australian infrastructure, we will decommission the Prague GPU sandbox and destroy all beta data held on it — including cached prompts, audio files, transcripts, generated images, and any model or service-level logs on that host.

We will provide written confirmation of destruction to participating agencies on request, stating what was destroyed, when, and by what method, signed by the Chief Technology Officer.

We should be candid about a limitation: the Prague server is rented bare-metal infrastructure hosted in a data centre operated by VSHosting s.r.o. (Prague-Hostivař), which is part of the Contabo Group. Our destruction commitment covers all data written by the application layer, but our ability to guarantee physical media destruction depends on the hosting provider's processes rather than our own.

6. Security measures actually in place

Stated plainly, without inflation, so that an agency reviewer can calibrate:

TLS for browser-to-application traffic; WireGuard (via Tailscale) between the application and the GPU server.
Argon2id password hashing; passkey (WebAuthn) sign-in available; minimum 12-character passwords.
Session hardening: HttpOnly and SameSite cookies, session regeneration, optional IP binding, server-side session revocation.
CSRF tokens on all state-changing requests; Content Security Policy; per-IP rate limiting.
Pattern-based prompt-injection filtering with logging of blocked attempts.
An internal codebase change ledger recording every modification to the application, with author, timestamp and line-level diff.
Role separation between user and administrator accounts.

Known gaps

No independent penetration test has been performed. One will be commissioned before any government beta cohort is admitted.
No security certification or assessment of any kind — no ISO/IEC 27001, no SOC 2, no IRAP.
Encryption at rest: full-disk encryption is enabled on both servers.
Multi-factor authentication: phishing-resistant passkeys (WebAuthn) are available to all accounts. Time-based one-time codes (TOTP) are not implemented, and a second factor is not currently enforced for beta accounts — passkey enrolment is recommended, and enforcement is under review ahead of any government beta.
The application runs on a single server with no high-availability arrangement. Daily backups are taken on the same VPS; off-site backup replication and a documented disaster-recovery procedure do not yet exist.