Security Practices

1 Infrastructure & Hosting

Kuliso runs on two primary cloud providers, both headquartered and operating in the United States:

Student data is never transferred outside the United States. All API calls to Google Gemini are routed to US endpoints and are contractually limited to US processing.

2 Encryption

In Transit

All connections to Kuliso use HTTPS with TLS 1.2 or higher. HTTP connections are automatically redirected to HTTPS. We do not support SSL 3.0 or TLS 1.0.

At Rest

• Database: Neon PostgreSQL encrypts all data at rest with AES-256. Backups are also encrypted.
• Passwords: User passwords are never stored. We store only a bcrypt hash (cost factor 12). Even if database credentials were compromised, raw passwords cannot be recovered.
• OAuth tokens: Third-party OAuth tokens (e.g., for LMS integrations) are encrypted with AES-256-GCM before storage.
• No sensitive data in logs: Our logging configuration explicitly excludes passwords, tokens, and student PII from server logs.

3 Access Controls

Application-Level Role Isolation

Every API endpoint in Kuliso enforces role-based access control. The four roles are:

• Student: Read-only access to their own session data. Cannot access other students' data or teacher configuration.
• Teacher: Full access to their own classrooms and students. Cannot access other teachers' classrooms.
• Parent: Access to their enrolled child's data only. Cannot access other families' data.
• Admin / District Admin: Scoped to their organization. Cannot access other districts' data.

Infrastructure Access

• Production database credentials are held by no more than 2 engineers at Polsia Inc.
• Access follows a least-privilege model: no engineer has more access than needed for their specific role.
• Production access events are logged.
• We do not use shared credentials — each engineer has a unique access identity.

Student Access Model

Students cannot create their own accounts. All student access is mediated by a teacher (via join code) or a parent (via Family Plan enrollment). This ensures no student under 18 can independently access the platform or create an account without adult oversight.

4 AI Data Handling

Kuliso uses Google Gemini (Gemini 2.5 Pro and Gemini 2.0 Flash) as its AI engine. Here's how student data is handled when it interacts with the AI:

• Session-scoped context only: AI prompts include only the current student's session content. No cross-student data is ever included in a prompt.
• No student identity in AI requests: Student names, email addresses, and user IDs are NOT included in API requests to Google. The AI receives only session transcripts and educational context.
• No AI training on student data: Per Google's API Terms of Service, data submitted through the Gemini API is not used to train or improve Google's models.
• US-only processing: Gemini API calls are routed to US endpoints. No student data is sent to non-US servers.
• Temporary retention by Google: Per Google's policy, API request data may be temporarily retained (up to 30 days) for abuse prevention only. It is not accessible to Google product teams.

5 Audit Logging (FERPA)

Kuliso maintains a FERPA-compliant audit log that records every access to student personally identifiable information. Each log entry captures:

• Who accessed the data (actor ID and type: teacher, admin, parent, system)
• What was accessed (resource type and ID)
• What action was performed (read, export, delete, etc.)
• When it happened (timestamp, UTC)
• IP address of the request (for security investigations)
• User agent (browser/device)

Audit logs are:

• Retained for 5 years, even after student data deletion
• Read-only: once written, audit entries cannot be modified or deleted
• Available to district administrators on request
• Scoped: teachers can only view audit logs for their own classrooms; only admins see school-wide logs

6 Incident Response

In the event of a security incident affecting student data, Kuliso follows this response procedure:

• Detection & triage (Hour 0–4): Identify the scope and nature of the incident. Isolate affected systems if needed. Preserve evidence.
• Containment (Hour 0–24): Stop the breach vector. Revoke compromised credentials. Patch the vulnerability.
• District notification (within 72 hours): Notify affected district administrators via email with: what happened, what data was involved, what we've done, and recommended actions for your side.
• Parent notification: Notify affected parents and guardians as required by applicable state laws (most states require notification within 30–60 days; we commit to doing so as quickly as practicable).
• Written incident report: Provide a formal written report within 5 business days of containment, suitable for your legal team and board reporting.
• Post-mortem & remediation: Root cause analysis and systemic fixes published in a follow-up report within 30 days.

To report a suspected security vulnerability, email support@kuliso.org with "Security Report" in the subject. We will acknowledge within 24 hours and respond within 72 hours.

7 Vulnerability Management

• Dependency updates: We actively monitor and update npm dependencies using automated tools. High-severity CVEs are patched within 7 days; critical CVEs within 48 hours.
• Input validation: All API inputs are validated and sanitized. SQL queries use parameterized statements exclusively — no raw string concatenation in database queries.
• Authentication: JWT-based session tokens with appropriate expiration. Tokens are invalidated on logout.
• Rate limiting: Privacy request endpoints and authentication endpoints are rate-limited to prevent abuse.
• CORS: Cross-origin requests are restricted to whitelisted origins.
• No security through obscurity: We do not rely on hidden endpoints or undocumented APIs for security.

8 Third-Party Vendor Security

We evaluate all third-party vendors before giving them any access to student data. Our requirements:

• Must have a published privacy policy and data processing agreement
• Must not use student data for advertising or AI training
• Must process data in the United States
• Preferred: SOC 2 Type II certified or equivalent

Current sub-processors with access to student data: Google (AI processing), Render (app hosting), Neon (database). Stripe does NOT receive student data — payment processing is limited to teacher/parent billing only.

We provide at least 30 days' notice before adding or replacing sub-processors. Our full sub-processor list is maintained in the Privacy Policy §8.

9 Student Data Isolation

• No cross-student data in AI prompts: Each AI request contains only the active student's session context.
• No third-party tracking on student pages: Student-facing pages (dashboard, tutor, assignments) do not load third-party analytics scripts, tracking pixels, or advertising SDKs.
• No behavioral advertising: We do not show ads to any users. We do not use student data to build marketing profiles.
• No sale of student data: We have never sold student data and never will. This is prohibited in our Privacy Policy, our DPA, and our internal policies.
• No disability data: Kuliso does not collect, store, or display IEP status, 504 plan status, ESOL designation, or any disability or accommodation classification. Learning supports are offered universally — not as accommodation flags.

10 Known Limitations & Security Roadmap

We believe in honest disclosure. Here's what we don't have yet, and when we plan to have it:

• Kuliso-level SOC 2 Type II: Our infrastructure providers are certified; Kuliso itself is pursuing certification in 2026.
• Third-party penetration test: Planned for 2026. We can share results with districts under NDA once complete.
• Formal VPAT for security: We have an accessibility VPAT at /vpat. A formal security assessment report for district IT is in progress.
• Multi-factor authentication (MFA): Not yet required for teacher/admin accounts. On our roadmap for Q3 2026.
• Single Sign-On (SSO) via SAML: Clever integration is live for school districts. Full SAML SSO for district identity providers is on our roadmap.

Contact & IT Review Requests