Security

Security is a design requirement of AISAC Academy, not an afterthought. This page transparently describes the technical and organisational measures we adopt to protect the platform and our users' data, and how security researchers can report vulnerabilities. It complements our Privacy Policy and Terms of Use.

1. Infrastructure and Hosting

• The application runs on Vercel infrastructure and data is stored on Supabase (managed PostgreSQL, authentication and file storage), both with data centres in the United States and their own security certifications (SOC 2 Type II).
• Encryption in transit: all traffic uses HTTPS with TLS 1.2 or higher. HTTP connections are redirected and the HSTS header with preload is enabled.
• Encryption at rest: databases, backups and files are encrypted at rest by the providers (AES-256).
• Backups: the database has automatic backups maintained by the provider.
• Infrastructure as code: database configuration (versioned migrations), deployment and security configuration live in the repository and go through review.

2. Authentication and Sessions

• Authentication is operated by Supabase Auth. Passwords are stored exclusively as bcrypt hashes; never in plain text and never written to logs.
• Sign in with Google via OAuth 2.0 / OpenID Connect, with minimal scopes (openid, e-mail, profile). We do not store Google access tokens.
• Magic link by e-mail, plus confirmation and password-reset flows using single-use, short-lived tokens.
• Sessions are kept in HttpOnly, Secure and SameSite cookies and refreshed server-side on every request.
• Rate limiting on sensitive flows: 5 login attempts per 15 minutes and 3 registrations per hour per origin, with 429 responses and progressive blocking.
• Authentication events (login, logout, password change, role change) are recorded in an audit trail without unnecessary personal data.

3. Access Control and Isolation

• The platform is multi-school: each School (tenant) has its data isolated. Access to courses, students and settings is restricted by centrally defined roles (owner, admin, instructor and student).
• Every application table has Row-Level Security (RLS) in PostgreSQL: even if the application layer fails, the database prevents a user from reading another School's data.
• High-privilege keys exist only on the server and are never exposed to the browser. The application follows the principle of least privilege per module and per role.
• The check order on every protected route is fixed: authentication → authorisation → input validation → business logic.

4. Data Protection

• Third-party integration credentials configured by Creators are encrypted in the application with AES-256-GCM before being written to the database.
• We do not store card numbers. Payments are processed by Stripe (PCI DSS Level 1); the platform keeps only transaction identifiers and the last four digits.
• Logs are structured and contain no personal data (e-mails, passwords, tokens or message content); users are referenced by internal identifier.
• Data sent to AI providers is limited to lesson content and the questions asked to the tutor; e-mail, password and payment data are never sent.
• Retention periods and secure deletion are described in section 8 of the Privacy Policy.

5. Application Security

• Security headers on every response: Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options, X-Frame-Options (DENY), Referrer-Policy and Permissions-Policy.
• Input validation with typed schemas at every external boundary (forms, APIs, webhooks), with size limits.
• User-submitted HTML content (lessons, comments) is sanitised before rendering, mitigating XSS.
• Database queries are parameterised; there is no SQL string concatenation.
• Third-party webhooks are signature-verified before any processing.
• Dependencies are regularly audited (SCA) with versions pinned by lockfile; secrets live only in environment variables and are never committed to the code.
• Changes go through automated lint, type-checking and build (CI) before deployment.

6. Access by AI Assistants (MCP)

Students can authorise compatible AI assistants to access the content of the courses they are enrolled in through the MCP protocol. This access uses OAuth 2.1 with PKCE, short-lived access tokens (1 hour) and revocable refresh tokens, limited to the user's active enrollments and subject to rate limiting. Authorisation can be revoked at any time and is cancelled automatically when the enrollment ends.

7. Monitoring and Incident Response

• Structured logs and production error alerts.
• An incident response plan covering containment, eradication, recovery and lessons learned.
• In the event of a security incident that may cause relevant risk or harm to data subjects, we will notify the ANPD and affected users within the deadlines and in the manner set out in art. 48 of the LGPD and ANPD regulations and, where applicable, art. 33 of the GDPR.

8. Responsible Vulnerability Disclosure

We value the work of security researchers. If you identify a vulnerability in AISAC Academy, we ask that you report it responsibly.

How to report: e-mail contact@aisac.global with the subject "Security", including a description of the vulnerability, steps to reproduce, potential impact and, if possible, a proof of concept. Do not include other users' personal data in the report.

Rules of engagement:

• Do not access, modify or delete data that is not yours; use test accounts you created.
• Do not carry out denial-of-service attacks, large-scale brute force, spam or social engineering against users or staff.
• Do not exploit the vulnerability beyond what is necessary to demonstrate it.
• Give us reasonable time to fix the issue before any public disclosure.

Our commitment:

• We will acknowledge receipt of your report within 5 (five) business days.
• We will keep you informed of the fix's progress and, with your permission, give public credit for the discovery.
• We will not take legal action against researchers who act in good faith and within these rules.

Out of scope: third-party services (Vercel, Supabase, Stripe, Google, Resend, etc.), which have their own programmes; denial-of-service attacks; social engineering; physical security; reports generated solely by automated scanners without proof of impact.

9. Limitations and Roadmap

In the interest of transparency: AISAC Academy does not yet hold its own SOC 2 or ISO 27001 certification (we rely on the certifications of the providers listed above), and two-factor authentication (2FA) for user accounts is on the roadmap. This page will be updated as these measures are implemented.

10. Contact

• Security reports: contact@aisac.global (subject "Security")
• Privacy and data protection (DPO): dpo@aisac.global
• Postal address: Av. Cristóvão Colombo, 2144, Sala 408, 3º andar — Floresta, Porto Alegre/RS, postal code 90560-001, Brazil