Security, privacy & compliance

The answer to “is this safe?” should be architecture, not assurance.

Any vendor can tell you they take privacy seriously. This page is written for the people whose job is to check.

Request the security review packet Jump to the threat model

Five commitments everything else follows from

Authorization is never a prompt

A deterministic policy engine decides what each person may see, before a model is handed anything. Instructions in a system prompt are guidance. They aren’t a security control and we don’t treat them as one.

Your data is yours

Your district owns and controls its data at every point. No training on it, no secondary use, no advertising, no selling, no sharing outside the subprocessors named in your agreement.

Isolation is structural

Every row, file, index entry, cache key, background job and log line carries a tenant. A cross-district query isn’t merely blocked. It isn’t expressible.

Minimum necessary, always

Requests carry the least data required to answer them. Identifying information never leaves for the public internet. Sensitive categories sit behind additional gates even for district administrators.

Everything is inspectable

Every access decision (granted and denied) is logged with user, resource, purpose and reason, and is visible to your administrators. Not on request, and not by exception, by default.

And

We’ll put it in the contract

If a commitment on this page matters to your district, it belongs in your data privacy agreement, not in our marketing. Ask us to write it down.

California obligations

The specific laws your counsel is going to name.

California districts operate under a stack of student privacy obligations that goes well beyond FERPA. Here is each one and what we do about it.

Obligation	What it requires	How Quilt meets it
FERPA 20 U.S.C. §1232g	Education records may be disclosed to school officials with a legitimate educational interest, under district direction and control.	Quilt operates as a school official under your direct control. “Legitimate educational interest” is enforced per request by the authorization engine, relationship, org scope and purpose, not assumed from a job title.
AB 1584 Cal. Ed. Code §49073.1	Specific contract provisions for any third party handling pupil records, district ownership, access, deletion, breach notice, prohibition on secondary use.	Every required provision is in our standard agreement. We don’t ask districts to negotiate them back in. District ownership, export, deletion certification and breach notification are default terms.
SOPIPA Cal. B&P Code §22584	No targeted advertising, no student profiling for non-educational purposes, no selling student information, reasonable security, deletion on district request.	We have no advertising business and never will. No profiling outside the educational purpose you direct. Deletion on request, certified in writing.
CA-SDPA California Student Data Privacy Agreement	The standardized agreement most California districts and county offices use, with exhibits covering data elements and subprocessors.	We sign it. We maintain the data element exhibit and a current subprocessor list, and we notify you before that list changes.
COPPA Children under 13	Verifiable parental consent for online collection from children under 13, with narrow school-consent conditions.	Quilt is staff-facing. We don’t collect information directly from students, and we aren’t shipping a student-facing chatbot as a feature. If we ever build one it will be a separate product with its own consent architecture.
PPRA Protection of Pupil Rights	Limits on surveys and collection in protected categories.	We ingest only what your district already holds and directs us to connect. We don’t administer surveys or collect new categories of information about students.
CCPA / CPRA	Consumer privacy rights, with an exemption pathway for information covered by FERPA and student privacy law.	We act solely as a service provider under your direction, with contractual restrictions on retention, use and disclosure that satisfy the service-provider requirements.
Accessibility Section 508 / WCAG 2.1 AA	District technology must be usable by staff and community members with disabilities.	We build to WCAG 2.1 AA and will provide a current VPAT/ACR on request. Accessibility defects are treated as product defects, not enhancement requests.

This table describes what we build into the product and what we will sign. It isn’t legal advice, and it doesn’t replace your district’s own review with counsel and your county office.

Authorization

Roles are too crude. We use relationships.

“Teacher” isn’t an access level. The question is always whether this person has a current, legitimate relationship to this student, for this purpose, at this moment.

Quilt uses attribute-based access control evaluated per request. Relationships come from your systems of record and expire on their own when a schedule changes, an enrollment moves or a role ends.

Policies are code, versioned, reviewed, and covered by an automated test suite.
Every tool re-authorizes at execution. Chaining tools can’t escalate.
Special education, health, counseling notes and Title IX material sit behind separate consent gates even for district administrators.
Denials are logged as carefully as approvals, and your administrators can review both.

policy / student_record.read

allow read student_record

if  user.tenant == student.tenant

and (
      teacher has active instructional
        relationship with student
   or counselor is assigned to student
   or principal manages student.school
   or admin has district_wide_privilege
   or guardian is verified for student
    )

and purpose in permitted_purposes

and effective_date within relationship.window

deny otherwise, and log the attempt.

Tenant isolation, obsessively

The failure that would end this company is one district seeing another district’s students. So isolation isn’t a filter applied late. It’s a property of every layer.

Row-level security in the database, enforced beneath the application.
Tenant-scoped vector and keyword indexes. Retrieval can’t cross a boundary.
Tenant-scoped cache keys, object-storage namespaces and background jobs.
Per-tenant encryption keys available for larger deployments.
Cross-tenant access attempts are a monitored, alerting security event.

Model providers are a routing constraint

“We use enterprise AI” isn’t a privacy architecture. You should be able to ask which provider received which request, under what terms.

Enterprise/API terms only, with no training on your data and defined retention.
A named subprocessor list, with advance notice before it changes.
Data classification determines eligibility, not every class of data is routable to every provider.
Consumer AI products, browser extensions and unapproved endpoints are never in the path.
US data residency by default. Regional constraints configurable per district.

The public internet

Two rooms, and nothing walks between them.

When a superintendent asks Quilt to compare district reading performance against current research, that’s two separate operations that meet only at the end.

Private operation, never leaves your tenant

get_assessment_results(grade=4, subject=reading)
→ 41st percentile, district cohort

Public operation · through the search broker

search_public_web("structured literacy evidence
grade 4 reading intervention")

Broker strips or rejects: names, student IDs, emails, phone numbers, dates of birth, addresses and identifying student–school combinations.

Then, and only then, the two results are synthesized inside your tenant. The public web never learned that a student exists.

Threat model

The thirteen ways this could go wrong.

We publish these because a vendor who can’t name its own failure modes hasn’t thought about them. Each is an explicit red-team category we test against before every release.

Cross-district leakage

A user in one district retrieves another district’s student. Mitigated by isolation at every layer, plus continuous automated probing.

Privilege escalation

A staff member reaches students they have no relationship with. Mitigated by per-request ABAC and per-tool re-authorization.

Direct prompt injection

A user tries to talk the model into ignoring its rules. The rules aren’t in the model, so there’s nothing to talk out of.

Indirect prompt injection

A malicious PDF or webpage instructs the agent. External content is treated as untrusted data with no authority, and the agent has no tool capable of exfiltration.

Knowledge poisoning

An uploaded document falsely claims to be authoritative policy. Mitigated by source classification, upload provenance and administrator-controlled authority levels.

Tool abuse

Tools invoked in unintended sequences to assemble something no single call would return. Mitigated by scoped tool sets, per-call authorization and sequence monitoring.

Injection into connectors

Malicious parameters reaching a data source. Mitigated by typed, bound, validated parameters. There’s no path from chat text to a query string.

Data exfiltration

Private context leaking into an outbound request. Mitigated by the public-search broker, egress controls and DLP inspection.

Cache leakage

One user served another user’s cached answer. Mitigated by tenant- and principal-scoped cache keys with no shared answer cache.

Vector leakage

Semantic retrieval crossing a tenant or ACL boundary. Mitigated by pre-filtered retrieval, permission before ranking, never after.

Provider leakage

Data reaching an unapproved model or endpoint. Mitigated by classification-driven routing and an allowlisted egress path.

Log & trace leakage

Sensitive content living forever in an observability tool. Mitigated by redaction at the trace boundary and separate retention for audit versus telemetry.

Cost attacks

Expensive agent loops triggered at scale. Mitigated by per-tenant budgets, rate limits, loop bounds and anomaly alerting.

Independent testing

Third-party penetration testing before general availability and annually thereafter. Findings and remediation status are shared with district partners under NDA.

Evals

Nothing ships because it seemed better.

Model and prompt changes are the highest-risk events here, and they are invisible unless the vendor makes them visible. Every change runs a full suite first, and regressions block the release.

Frontier models get upgraded constantly. Quilt never upgrades blindly, and your district gets a release note when the routing changes.

Suite	What it proves
Permissions	Teacher asking about another teacher’s student, parent asking about another child, principal asking about another school, cross-district attempts. All must deny.
Accuracy	Questions with known answers, verified against source systems.
Retrieval	The correct district document, section and effective version was found.
Citation	Every citation actually supports the claim attached to it.
Prompt injection	Thousands of direct and indirect attacks, including hostile documents and webpages.
Tool selection	The agent chose the right tool and didn’t over-fetch.
Statistics	Metrics computed correctly against your definitions, including edge cases and small-n suppression.
Bias	Recommendations don’t shift improperly when demographic variables change.
Regression	Model A to model B, what got worse?

Boundaries

What Quilt won’t do, and how that changes.

Constraints are only meaningful if loosening them is a visible, governed event. These boundaries are enforced in the product, written into your agreement, and can’t be changed by us unilaterally.

Any expansion of scope requires a written amendment, a district administrator’s configuration change, and notice to the district. There’s no setting we can flip on your behalf.

How a district turns capabilities on over time

No writes to your systems of record in year one. Read-only, and not “read-only by default”. Read-only.
No outbound communication without a human. Quilt drafts. A person reviews and sends.
No autonomous decisions on high-stakes matters. That covers discipline, special education eligibility, placement, retention, gifted identification, student risk labeling, employee performance or threat assessment.
No student-facing chatbot. It is staff-facing only.
No training of any model on your data. Contractual, with every subprocessor.
No identifying student information sent to the public internet. Enforced by the broker, not by policy alone.
No claim without a source. Output validation blocks unsupported assertions.

Running the company

Most of a security review isn’t about AI.

It’s about how a company builds, patches, hosts and hires. Districts ask those questions of every vendor, so here are our answers before you have to ask.

Where it runs

Encrypted in transit and at rest, with per-tenant keys for larger deployments.
US data residency by default. Your data doesn’t leave the country unless your agreement says it can.
Private networking. Production has no ports open to the public internet.
Production access needs multi-factor authentication, and every elevated command is logged.
Backups are encrypted, restored on a test schedule, and expire on the timeline in your agreement.

How we build it

Every change gets peer review before it reaches production.
Static analysis, dependency scanning and secret scanning run on every build.
New surfaces get a threat model before anyone writes the code.
Deploys are automated and reversible, so a bad change takes minutes to undo.
Third-party penetration testing before general availability, and every year after.

When something is wrong

We watch public vulnerability feeds and our own dependency alerts daily.
Severity sets the clock. Critical fixes ship on a documented timeline, not next sprint.
Documented incident response with named severity levels and a real on-call rotation.
If district data is involved you hear it from us inside the window in your agreement, with what was reached, what we did, and what changes.
Found something? Write to security@quilt.education. We answer researchers.

The people with the keys

Access follows the job. Granted on start, removed on departure, reviewed on a schedule.
Company laptops are encrypted, screen-locked and remotely wipeable.
Multi-factor authentication and a password manager are required, not encouraged.
Anyone who can reach district data is background checked and under a confidentiality agreement.
Security training at hire, and again every year.

Chat history is sensitive too

A conversation that summarizes a student’s attendance, reading struggles and referrals can be more sensitive than any single source record. Conversations are encrypted, retained on your district’s schedule, exportable, deletable and available in a no-history mode for sensitive roles.

Two logs, different lifetimes

The security audit log records who accessed what, why and whether it was allowed, retained per your agreement and visible to your administrators. The AI trace records models, tools and latency for engineering, with identifying content redacted at the boundary.

Subprocessors

A current, named list of every subprocessor with access to district data, including model providers, with advance notice before it changes and a mechanism to object.

Certification status

We’re an early-stage company and we won’t overstate this. Independent SOC 2 Type II audit is underway ahead of general availability. We’ll share current status, scope and any bridge letter under NDA. Ask, and we’ll tell you exactly where we are.

Exit

Full export of your data, documents, metric definitions and audit log at any time, in open formats. Deletion of our copies on the schedule in your agreement, certified in writing.

Send us your security questionnaire. We would rather answer it early.

We’ll complete your standard vendor review, sit with your county office, and put every commitment on this page into your data privacy agreement.

Request the security packet Email us directly