Security Overview

1. How CampusLayer works

CampusLayer is a web application at app.campuslayer.app. Sign-in happens at id.campuslayer.app. The application runs on Vercel and stores its data in a Supabase Postgres database in the United States. Staff can connect their own Microsoft 365 and Canvas accounts. CampusLayer Assistant, an AI assistant for staff, can read from those connected accounts when a staff member asks, through one gateway that applies the district’s data policy before anything reaches the AI model. The companies involved are listed on the Subprocessors page.

2. District isolation

Each district or independent school is a separate workspace. Every record of school data carries its workspace, and the database itself enforces row-level security: each read and write is checked against the signed-in person’s active membership and role in that workspace. Sensitive tables, including credentials, conversations, usage, and audit logs, are not reachable through the application’s data API at all; they are accessed only through server functions that check permission explicitly. CampusLayer maintains automated database tests for these rules and runs them when database changes are developed.

3. Accounts and access control

• People sign in to their own accounts. There are no shared logins.
• Access is role-based (district administrator, school administrator, teacher, counselor, staff, student, guardian) and scoped to a district or school. Access ends when a membership is turned off or reaches its end date.
• District administrators invite staff, turn access on and off, and set the district AI policy. Every one of those actions is recorded.
• Session tokens are signed with an asymmetric key (ECC P-256) and expire after one hour.
• Single sign-on through a district’s identity provider is not yet available.

4. Encryption

• All traffic to CampusLayer uses HTTPS (TLS).
• Data is encrypted at rest by the database and storage provider.
• Tokens for connected systems (Microsoft 365, Canvas) are additionally encrypted by CampusLayer with AES-256-GCM before they are stored, and are never shown again after they are saved.
• The real names and email addresses behind AI placeholders are stored encrypted, per conversation, and restored only for the person who owns that conversation.

5. AI data handling

• Assistant is available only to staff roles the district enables. Students and guardians cannot be given access.
• Assistant reads connected systems only when the person asks. It can save an email draft but never sends one; sending, answering a calendar invitation, or any other change happens only after the person reviews and confirms it in CampusLayer, and each confirmation is logged. It cannot change grades or records.
• The district AI policy is enforced by CampusLayer’s code on every request, not by instructions to the AI model. Fields holding identifiers, addresses, guardian contacts, and credentials are never sent. Names and email addresses are replaced with placeholders. Sensitive student records are withheld unless the district changes that setting. What staff type, and free text the district allows such as email subject lines and message text, is screened for the names of people in the district’s records, email addresses, phone numbers, and identifier numbers, which are replaced before the model sees them. Names that are not in CampusLayer’s records may not be recognized.
• Requests go to the AI provider with response storage turned off. Zero data retention is not yet in place; see the Subprocessors page.
• CampusLayer does not use school data to train AI models.

6. CampusLayer staff access

CampusLayer staff can enter a district’s workspace only while it is being set up, and only until a date fixed when the workspace is created (no more than 90 days). Completing setup ends that access immediately. Each entry is logged and shown to the district’s administrators, with the staff member’s account, on the Data controls page. CampusLayer’s own administrative console is a separate, restricted application.

7. Logging and monitoring

Security-relevant actions, including invitations, access changes, policy changes, and CampusLayer staff access, are written to an append-only audit log. Application error logs record error codes and types, not school records, Assistant content, email addresses, or credentials. Assistant usage is metered by request and token count only; the usage record never contains what was asked or answered.

8. Data retention and deletion

Data read from connected systems is not stored by CampusLayer beyond the conversation in which it was used. Staff can delete their own conversations and files. On a district’s written request, or when its use of CampusLayer ends, CampusLayer deletes the district’s data within 90 days, as set out in the Data Processing Addendum. Automated, scheduled deletion by district-set retention periods is not yet built; deletion is currently carried out on request.

9. Development practices

• Every code change runs automated type checking, linting, and unit tests before it can be released.
• Database security tests are run when database changes are developed. They are not yet an automatic gate on release.
• Database changes are versioned migrations, reviewed before they are applied to production.
• Production secrets are held in the hosting provider’s encrypted environment settings, never in source code.

10. Incident response

If CampusLayer suspects a security incident, it contains the issue, investigates its scope, and fixes the cause. If an incident affecting a district’s data is confirmed, CampusLayer notifies the district without undue delay and no later than 72 hours after confirmation, and supports the district’s own notification obligations, as set out in the Data Processing Addendum.

11. What is not yet in place

• CampusLayer does not hold SOC 2 or ISO 27001 certification. Its hosting and database providers do.
• Zero data retention with the AI provider.
• Automated deletion on district-set retention schedules.
• Single sign-on with district identity providers.

CampusLayer does not claim FERPA or COPPA certification; no such certification exists. The Data Processing Addendum describes how CampusLayer supports a district’s obligations under those laws.

12. Reporting a vulnerability

If you believe you have found a security vulnerability in CampusLayer, please report it through the CampusLayer contact page. Please do not access data that is not yours, and give us a reasonable time to fix the issue before disclosing it.