Last updated: August 20, 2026
This statement describes how Athens AI Technologies Inc. (“Athens,” “we,” “us,” or “our”) protects information in the Athens web application, related course workspaces, and associated services (together, the “Service”).
It accompanies the Athens Terms of Service and the Athens Privacy Notice and uses the same definitions: Athens is offered as a limited, instructor-led pilot, in which an individual Instructor creates a course and invites Students, and in which an Instructor's participation does not by itself establish that their Institution has authorized, sponsored, endorsed, or contracted for the Service.
This statement is informational. Except for the security-research permission described in Section 9, which Section 6 of the Terms refers to for procedure, this statement is not incorporated into the Terms and is not a representation, warranty, or contractual commitment. It is not a certification, an audit result, or a guarantee of security.
Athens is an early-stage product, and its security practices will continue to mature during the pilot. That is a statement about depth and independent evidence, not about whether Athens has obligations: the safeguards described below are in place now, and Athens' duties under applicable law and its Privacy Notice are not deferred to a later release.
1. Shared responsibility
Athens is responsible for the security of the Service: its infrastructure, application code, access controls, and the safeguards below.
An Instructor is responsible for deciding what belongs in Athens: which Students to add or invite, which materials to upload, whether their Institution permits it, and whether the content is appropriate for an early-stage tool. Athens does not review uploads and cannot make those judgments.
Users are responsible for protecting their credentials and invitation links.
2. Infrastructure and encryption
The Service runs on Amazon Web Services. Web, API, and background worker services run as containers in private subnets. The application database is Amazon Aurora PostgreSQL and is not publicly accessible. Uploaded files are stored in private Amazon S3 storage that is not publicly readable. Only the web surface is publicly reachable, through Amazon CloudFront and a web application firewall; the API is reachable over private networking behind an internal load balancer. Infrastructure is defined as code and changed through reviewed configuration.
Traffic between your browser and the Service is encrypted in transit over HTTPS, and plain HTTP is redirected to HTTPS. The database has storage encryption enabled, and file storage uses server-side encryption.
3. Accounts, authentication, and sessions
Sign-in is handled through Amazon Cognito. Session cookies are set HttpOnly
and Secure with a restricted SameSite policy. Only a hash of a session
identifier is stored in the database, never the raw session cookie.
Programmatic API tokens are stored only as hashes, shown once at creation,
scoped, and revocable. Signing out revokes the stored session record.
State-changing requests authenticated by cookie also require a signed
double-submit cross-site request forgery token and a trusted origin.
Athens does not currently require multi-factor authentication. Whether MFA is available to you depends on the identity provider configured for your sign-in path; the managed identity service Athens uses supports optional MFA, including time-based one-time passwords, in the selected configuration. Athens does not mandate MFA or verify that it is enabled.
4. Authorization and separation
Athens checks authorization on the server for each request rather than by hiding options in the interface. Course, material, roster, invitation, policy, retrieval, chat, and analytics routes confirm that the caller belongs to the relevant organization, course, and section and holds the required role.
Three separations are treated as strict:
- Between courses and organizations. Access to one course or section is not intended to grant access to any other.
- Between students. A Student's private workspace content is scoped to that Student.
- Between students and instructors. Instructors do not receive Students' raw private workspace content by default. Where course analytics are available they show aggregate patterns, and an aggregate derived from fewer than five distinct learners is suppressed.
An automated test suite covering cross-course access and student-private exposure runs in continuous integration. Automated tests raise confidence; they do not prove the absence of flaws, and no independent party has verified these boundaries.
5. AI features, providers, and grounding
Athens does not train or fine-tune models on Student or course content, and configures its approved providers so that content sent for a request is not used by them for training.
AI features send an approved provider only what the request requires: the prompt, the relevant course or workspace content, policy instructions, retrieved source excerpts, and limited operational metadata. Retrieval is scoped at query time to the requesting User's course and the material that User is permitted to see, so a grounded answer is not intended to be able to draw on another course or another Student's private material. Providers and models are constrained by server-side allowlists.
Athens treats uploaded documents, extracted text, and imported content as untrusted input; instructions embedded in that content are not permitted to change Athens policy or authorize an action. AI features do not autonomously publish, change course policy, submit work, or grade; consequential actions require User confirmation and server-side authorization.
An automated evaluation suite tests prompt-based exfiltration, cross-course leakage, student-private leakage, and citation spoofing. Athens has not completed independent adversarial testing of its AI features, and does not claim its grounding boundaries cannot be circumvented.
6. Course materials and uploads
Uploads are validated for file type and size, stored privately, and served through scoped, expiring links rather than public URLs. Background processing messages carry internal identifiers only, never file contents. Instructor-uploaded materials remain drafts until the Instructor releases them. Imported course packages are inspected before extraction, and archives are rejected for unsafe entry paths, encrypted entries, oversized contents, invalid manifests, or unsupported entry types.
Uploaded files are not currently scanned for malware. A scan gate exists in the pipeline, but Athens has not yet selected or deployed a production malware and sensitive-data scanner. Athens also does not inspect uploads to determine whether they contain personal information or material the uploader lacks rights to.
7. Logging, access, and vendors
Athens records audit events for security-relevant operations, including authentication, course and material access, roster and invitation operations, policy changes, and retrieval and chat activity. Audit records are metadata-only and exclude session and invitation tokens, authorization codes, prompt text, AI response text, and provider credentials.
Administrative access to production is limited to a small number of Athens personnel using individual identities and least-privilege roles. Application secrets are held in a managed secrets service and resolved at runtime rather than stored in source control. Athens does not operate a support role that can read Student-private workspace content through the application.
Athens uses a limited set of providers for cloud hosting, storage, database, queueing, email delivery, and AI model inference. The pilot is intended for Users in the United States and default provider paths are intended to use U.S. regions. The current list of provider categories is available on request.
8. Secure development, backups, and incidents
Changes land through version control with review. Automated security checks run
on pull requests and scheduled scans and include static analysis, dependency and
infrastructure scanning, container scanning, and secret scanning. Secret scanning
also runs on pushes to dev and main. No external penetration test and no
authenticated dynamic application security testing have been performed.
The database is backed up and file storage retains prior object versions. Backups are access-restricted and expire on a schedule. As the Privacy Notice explains, deleting information from the active Service does not immediately remove it from backups, and a restore may reintroduce previously deleted content. Athens has not completed a live restore drill and does not commit to a recovery time or recovery point objective.
Athens maintains an internal incident response procedure covering roles, severity, escalation, containment, and evidence handling. That procedure is still a pre-pilot draft. If Athens determines that a security incident affected your information, Athens will notify affected parties as required by applicable law, by any applicable agreement, and by its approved incident process, and will provide what is known about the scope and what to do. Athens does not commit in this statement to notifying every affected person, or to a specific notification deadline, because it is a small team without 24/7 on-call coverage and a commitment it could not reliably meet would be worse than stating the limit plainly.
9. Reporting a security problem
If you believe you have found a vulnerability or a security or privacy problem
in the Service, report it to admin@athenslabs.ai with enough detail to
reproduce it.
Safe harbor. Section 6 of the Terms of Service permits good faith security research conducted under this section, and Athens will not pursue action against you under those Terms for it. To stay within this permission you must:
- act in good faith and avoid privacy violations;
- avoid degrading or disrupting the Service for other Users;
- not access, modify, retain, or exfiltrate data that is not your own beyond the minimum needed to demonstrate the issue, and delete any such data afterwards;
- report promptly to
admin@athenslabs.ai; and - give Athens a reasonable opportunity to investigate and fix the issue before disclosing it publicly.
This safe harbor is limited to Athens and cannot waive the rights of third parties, including Athens' hosting and infrastructure providers, whose terms continue to apply to you.
Athens will acknowledge a good faith report and keep the reporter informed of material progress. Athens does not currently operate a paid bug bounty.
If you suspect your own account or credentials have been compromised, contact
admin@athenslabs.ai immediately.
10. Current control maturity
Athens is an early-stage pilot. This section lists, in one place, the controls that are not yet independently verified or fully implemented, stated plainly rather than obscured, together with the related safeguards in place today and the direction of travel. A safeguard listed under “Today” is what currently exists nearby; it is not a substitute for the missing control, and where it does not reduce the underlying risk this section says so.
No third-party certification or audit. Athens does not hold SOC 2, ISO
27001, or a comparable attestation, and no independent party has verified the
controls in this statement. Today: infrastructure is defined as code and
changed through reviewed configuration; an automated test suite covering
cross-course access and student-private exposure runs in continuous integration;
and automated security checks run on pull requests and scheduled scans, covering
static analysis, dependency and infrastructure scanning, container scanning, and
secret scanning, with secret scanning also running on pushes to dev and
main. Planned: independent review and a recognized attestation as the pilot
matures.
No external penetration test. Athens has not commissioned an external penetration test or authenticated dynamic application security testing. Today: the automated security checks above run continuously, and an automated evaluation suite tests the AI features for exfiltration and leakage. Planned: engage a qualified external tester before broad scaling.
MFA is not required by Athens. Athens does not mandate multi-factor
authentication or verify that it is enabled. Today: sign-in runs through a
managed identity service that supports optional MFA, including time-based
one-time passwords; sessions use HttpOnly, Secure, restricted-SameSite
cookies; only a session hash is stored; and state-changing requests require a
signed cross-site request forgery token and a trusted origin. Planned:
evaluate requiring MFA for instructor and administrative accounts.
Uploaded files are not yet scanned for malware. Today: uploads are validated for type and size, stored privately, and served only through scoped, expiring links rather than public URLs; imported packages are inspected and rejected for unsafe paths, encrypted entries, oversized contents, or invalid manifests; and a scan gate already exists in the processing pipeline. None of these detect malicious content inside an otherwise well-formed file, so they limit exposure and do not compensate for the absent scanner. A file uploaded to a course can be downloaded by others with access to that course. Planned: select and deploy a production malware and sensitive-data scanner at that gate.
No independent AI red-teaming. Athens does not claim its grounding boundaries cannot be circumvented. Today: retrieval is scoped at query time to the material a user is permitted to see; approved providers are configured not to train on submitted content; instructions embedded in uploaded content are treated as untrusted and cannot change policy or authorize actions; AI features take no consequential action without user confirmation and server-side authorization; and an automated suite tests for prompt-based exfiltration, cross-course leakage, student-private leakage, and citation spoofing. Planned: independent adversarial testing of the AI features.
No completed live restore drill, and no committed recovery objective. Today: the database is backed up and file storage retains prior object versions; backups are access-restricted and expire on a schedule. Planned: perform a live restore drill and define recovery time and recovery point objectives.
Incident response is a pre-pilot draft, and no notification deadline is committed. Today: Athens maintains an internal incident response procedure covering roles, severity, escalation, containment, and evidence handling, and records audit events for security-relevant operations; if an incident affects your information, Athens will notify affected parties as required by applicable law and any applicable agreement. Planned: finalize the incident response procedure and set defined notification targets.
No complete self-service export or account-deletion workflow. Today:
in-product deletion paths exist for courses, materials, and some student
content. There is no account-wide deletion workflow: deleting an account and
everything associated with it is handled manually by Athens and is not
complete. Access, correction, export, and deletion requests are made to
admin@athenslabs.ai and are satisfied using available in-product tooling
together with operator action, subject to verification and to legal and
technical limits. Planned: build complete self-service export and
account-wide deletion.
No published retention schedule with specific periods. Today: the Privacy Notice describes how each category of information is retained, including invitations, roster records, account and course content, security and audit logs, and backups, and records are kept in minimized form. Planned: publish defined retention periods for each category.
An Instructor's participation is not an institutional security review. An Instructor choosing to pilot Athens does not by itself mean their Institution has reviewed, authorized, or approved the Service. For an institutional deployment, Athens will complete a security review with the Institution and formalize a school-appropriate agreement covering data handling, consent, and the items above.
Athens will update this section as items close. Nothing here is a commitment to a delivery date.
11. Institutional reviewers and school-led pilots
An Institution evaluating Athens may request additional detail, including
architecture and data-flow documentation, access-control and subprocessor
information, AI data-use documentation, and the current status of the items in
Section 10. Contact admin@athenslabs.ai.
Secondary-school pilots require prior coordination with Athens. Athens
distinguishes two models. In higher education a pilot may be instructor-led,
subject to the Instructor's own authority and their Institution's policies. For
a course offered through a K–12 school or district, the Instructor must contact
Athens at admin@athenslabs.ai and receive written confirmation before entering
Student information, importing a roster, sending invitations, or uploading course
Appropriate school or district authorization is required for every K–12
pilot. Athens may additionally require a school-appropriate pilot agreement
or data-protection addendum depending on applicable law, district policy, and
the pilot's data scope. Such an agreement would cover authorization,
permitted use, subprocessors, security, retention and deletion, incidents, and
student and parent rights. An individual Instructor's acceptance of the Terms,
and any written confirmation from Athens, do not replace the school's or
district's own authorization.
This requirement is currently administrative: the Service does not yet technically prevent an Instructor from adding Students before contacting Athens. Athens intends to add an approval gate.
12. Changes to this statement
Athens may update this statement as the Service, the pilot, or applicable law changes. When a change is material, Athens will provide notice through the Service, by email, or by another reasonable channel. The date at the top shows when this statement was last updated.
13. Contact
Questions about this statement or about Athens security may be sent to:
Athens AI Technologies Inc.
1007 N. Orange Street, 4th Floor, Suite 1382
Wilmington, DE 19801
Email: admin@athenslabs.ai

