Technical Documentation
Document 06 of 12

Security & Compliance Framework

Dev Team March 2026 Grio AI Education Platform

Security & Compliance Framework

Grio AI Education Platform

Last Updated: March 2026 Audience: Developers, DevOps Engineers, School Administrators, Ministry Officials Scope: INTERNAL security practices and EXTERNAL government compliance readiness

1. Security Architecture Overview

Grio implements a defense-in-depth approach across multiple security layers:

┌─────────────────────────────────────────────────────┐
│                   Cloudflare (DDoS)                 │
├─────────────────────────────────────────────────────┤
│            Traefik Load Balancer (TLS)              │
├─────────────────────────────────────────────────────┤
│         UFW Firewall (Network Isolation)            │
├─────────────────────────────────────────────────────┤
│         K3s Cluster (Container Runtime)             │
│  ┌─────────────┬──────────────┬──────────────┐     │
│  │  Django API │  Web Frontend│  AI Service  │     │
│  │  (Auth)     │  (HTTPS)     │  (Sandboxed) │     │
│  └─────────────┴──────────────┴──────────────┘     │
├─────────────────────────────────────────────────────┤
│     PostgreSQL with RLS (Row-Level Security)        │
│     Encrypted Backups to Secure Storage             │
└─────────────────────────────────────────────────────┘

Security Layers: - Network: Cloudflare DDoS protection, UFW firewall, VPN-only admin access - Application: HTTPS/TLS 1.2+, JWT authentication, input validation, rate limiting - Data: Encryption in transit and at rest, RLS for tenant isolation, audit logging - Access: RBAC with 5 roles, session management, password policies, MFA-ready

2. Authentication & Access Control

Authentication Mechanism

All user authentication uses JWT (JSON Web Tokens) with OAuth 2.0 support:

Role-Based Access Control (RBAC)

┌──────────────────────────────────────────────────┐
│  SUPER_ADMIN                                     │
│  - Platform configuration & monitoring           │
│  - User role assignment                          │
│  - All school data visibility (audit only)       │
│  - Government data export                        │
└──────────────────────────────────────────────────┘

┌──────────────────────────────────────────────────┐
│  SCHOOL_ADMIN (Tenant Scoped)                    │
│  - School-level user management                  │
│  - Enrollment & student records                  │
│  - Teacher & class management                    │
│  - School analytics & usage reports              │
│  - Cannot access other schools' data             │
└──────────────────────────────────────────────────┘

┌──────────────────────────────────────────────────┐
│  TEACHER (School Scoped)                         │
│  - Class management & assignments                │
│  - Student progress tracking                     │
│  - Content creation & curriculum alignment       │
│  - AI tutor configuration & monitoring           │
│  - Cannot edit other teachers' classes           │
└──────────────────────────────────────────────────┘

┌──────────────────────────────────────────────────┐
│  STUDENT (Individual Scoped)                     │
│  - Access assigned classes only                  │
│  - Submit assignments & view feedback            │
│  - Learning analytics (own progress)             │
│  - Cannot view other students' data              │
└──────────────────────────────────────────────────┘

┌──────────────────────────────────────────────────┐
│  INDEPENDENT_LEARNER (Subscription)              │
│  - Access curated content by topic               │
│  - Progress tracking within subscription         │
│  - Limited AI tutor interactions (quota-based)   │
│  - Cannot access school resources                │
└──────────────────────────────────────────────────┘

Session Management

3. Multi-Tenancy & Data Isolation

Row-Level Security (RLS) in PostgreSQL

Every query is filtered by tenant context:

-- Example: Teachers can only see their school's students
POLICY teacher_see_own_school_students ON students
  USING (school_id = current_setting('app.school_id')::uuid)

-- Example: Students can only see themselves
POLICY student_see_self ON student_progress
  USING (student_id = current_setting('app.user_id')::uuid)

Tenant Types & Boundaries

School Tenants: - Separate namespace per school (school_id) - School admins cannot access other schools (enforced at DB and application layer) - Student data belongs exclusively to enrolling school - Teachers see only their assigned classes within their school

Independent Learners: - Individual tenant per subscription (user_id) - No school associations or data sharing - Complete data isolation from all school tenants

Admin Access Scoping

4. Data Protection

Encryption in Transit

Encryption at Rest

Sensitive Data Handling

Student PII Protected: - Student names, email, phone numbers, parent contact info - Academic records (grades, test scores, attendance) - AI interaction transcripts logged separately with access restrictions

Minimal Data Collection: - Only collect data necessary for learning & school operations - No tracking for advertising or third-party resale - Student data not used to train AI models without explicit consent

Data Retention Policies

Right to Erasure

Students and parents can request complete data deletion: 1. Request submitted via secure form or school admin 2. Verification of identity and authorization 3. Data anonymized/deleted within 30 days 4. Audit log entry created (for compliance verification) 5. Confirmation email sent to requester

5. Network Security

Firewall Configuration

UFW (Uncomplicated Firewall) Rules:

- Port 80 (HTTP):     ALLOW → redirects to 443
- Port 443 (HTTPS):   ALLOW → Traefik load balancer
- Port 22 (SSH):      ALLOW from VPN only (restrict to specific IPs)
- Port 5432 (DB):     DENY from internet, ALLOW from K3s cluster only
- All other ports:    DENY (default-deny policy)

VPN for Administrative Access

Load Balancer Architecture

DDoS Mitigation

6. Application Security

Input Validation & Sanitization

SQL Injection Prevention

XSS & CSRF Protection

Rate Limiting

Secure Headers

Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
X-XSS-Protection: 1; mode=block
Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline' (reviewed)

7. AI-Specific Security

Prompt Injection Prevention

Output Filtering & Age-Appropriateness

PII Protection in AI Responses

Topic-Locking as Security Boundary

Audit Trail for AI Interactions

8. Infrastructure Security

Container Image Scanning

K3s Cluster Hardening

Secret Management

Minimal Attack Surface

9. Government Compliance Readiness

Data Sovereignty

Comprehensive Audit Logs

Logs capture: - Who: user_id, role, authentication method - What: action taken, resource accessed, data modified - When: precise timestamp, timezone included - Where: IP address, user agent, session_id - Why: audit reason (for Ministry-initiated access)

Example log entry:

{
  "timestamp": "2026-03-24T14:32:00Z",
  "user_id": "admin-001",
  "role": "SUPER_ADMIN",
  "action": "export_student_data",
  "school_id": "school-123",
  "record_count": 500,
  "authorization": "ministry-request-2026-03-24",
  "ip_address": "192.168.1.100",
  "status": "success"
}

Ministry Data Export

Audit Trail for Sensitive Operations

All these events trigger audit logs: - User creation, role assignment, suspension - Student data access by admin/teacher - School configuration changes - AI service access & output review - Failed login/authentication attempts - Data export/deletion requests

Compliance Verification

10. Monitoring & Incident Response

Security Event Logging

All security events logged to centralized log store: - Authentication attempts (success/failure) - Authorization failures (permission denied) - Suspicious patterns (rate limit breaches, multiple failed logins) - Administrative actions (role changes, data access) - AI service anomalies (excessive requests, filter triggers)

Anomaly Detection (Phase 2)

Incident Response Procedure

  1. Detection: Alert triggered by monitoring or staff report
  2. Investigation: Examine logs, isolate affected systems, assess scope
  3. Containment: Revoke compromised credentials, reset affected accounts
  4. Remediation: Apply patches, update firewall rules, change secrets
  5. Notification: Inform affected users, parents, school admin (within 72 hours)
  6. Documentation: Post-incident review, update procedures

Breach Notification Process

Upon confirmed data breach: - Immediate notification to Ministry (if required by law) - Notification to affected school admins within 24 hours - Parents/students notified within 72 hours with details: - Type of data exposed - Steps taken to secure systems - Protective measures users should take - Contact information for questions

11. Compliance Checklist

RequirementStatusImplementationNotes
Data Protection
Encryption in transit (TLS 1.2+)✅ ImplementedHTTPS, Let’s EncryptAll endpoints secured
Encryption at rest✅ ImplementedLUKS disk encryptionHetzner native
Data minimization✅ ImplementedCollected only required fieldsPII restricted
Data retention policies✅ Implemented2yr active + 7yr audit logsAutomated purge scheduled
Right to erasure✅ ImplementedSecure deletion API30-day SLA
Access Control
RBAC with 5+ roles✅ ImplementedJWT + Django permissionsScoped to tenant
Session management✅ Implemented30-min timeout, token refreshLogout revocation
MFA for admin📋 PlannedPhase 2 Q2 2026TOTP-based
Audit logging✅ ImplementedComprehensive event log7-year retention
Admin access scoping✅ ImplementedExplicit audit trailSuper Admin restricted
Network Security
Firewall (UFW)✅ ImplementedDefault-deny, port whitelistReviewed quarterly
VPN for admin✅ ImplementedWireGuard VPN requiredSSH/DB access restricted
Load balancer (Traefik)✅ ImplementedTLS termination, routingSingle entry point
DDoS protection✅ ImplementedCloudflare free tierRate limiting configured
Application Security
Input validation✅ ImplementedServer-side whitelist validationAll endpoints protected
SQL injection prevention✅ ImplementedDjango ORM parameterizationCode review audits
XSS protection✅ ImplementedCSP headers, template escapingNo inline scripts
CSRF protection✅ ImplementedDjango CSRF middlewareToken validation
Rate limiting✅ Implemented100 req/min per IPConfigurable per endpoint
AI Security
Prompt injection prevention✅ ImplementedInput sanitization, isolationContainerized AI service
Output filtering✅ ImplementedAge-appropriate filterCurriculum-bounded
PII protection in outputs✅ ImplementedResponse scanningPlaceholder substitution
Topic-locking✅ ImplementedCurriculum scope enforcementOff-topic logging
AI audit trail✅ ImplementedComplete interaction logging7-year retention
Infrastructure
Container scanning✅ ImplementedTrivy vulnerability scanningEvery build
K3s hardening✅ ImplementedRBAC, network policies, PSPsQuarterly review
Secret management✅ ImplementedEnvironment variables onlyRotation quarterly
Data sovereignty✅ DesignedIn-country storage plannedMigration Phase 2
Compliance
Comprehensive audit logs✅ ImplementedWho/what/when/where/whyMinistry-exportable
Ministry data export✅ PlannedSecure API endpointPhase 2 Q1 2026
Incident response plan✅ Documented72-hour notification SLALegal review pending
Annual compliance statement📋 PlannedPhase 1 completionQuarterly thereafter

12. Security Roadmap

Phase 1: Foundation (NOW - Q2 2026)

Phase 2: Enhanced Hardening (Q2-Q4 2026)

Phase 3: Government Certification (Q1-Q2 2027)

Key Contacts & Escalation

Document Control

VersionDateAuthorChange
1.0Mar 24, 2026DevOps TeamInitial comprehensive framework

This document is intended for internal use and government compliance readiness. It should be reviewed and updated quarterly.

← Infrastructure & Deployment Guide
Grio AI — Project Documentation — March 2026
Executive Summary →