Security, privacy & governance
Put AI to work. Keep your district in control.
Quilt connects district systems and gives approved agents access to the information they need. Your district controls that access, the work agents can perform and the steps that require human review.
District control, built into the infrastructure
Check access before retrieving data
Quilt checks the user, agent and task before retrieving information. Permissions are enforced by software outside the AI model.
Keep ownership of your data
Your district owns its data. Quilt uses it for the purposes in your agreement, not advertising, sale, unrelated profiling or model training.
Separate each district’s information
District boundaries apply to stored records, documents, search indexes, caches and background work. Access controls and testing are designed to prevent cross-district exposure.
Retrieve what the task needs
Your existing systems remain the source of record. Quilt retrieves relevant information from approved sources without requiring a complete copy of every system.
Review access and actions
Authorized administrators can review agent activity and access decisions, including denials. Records identify the user, resource, purpose and decision.
Document the commitments
Your agreement defines approved uses, subprocessors, retention, deletion, incident notification and responsibilities. Review those terms before connecting private district information.
Privacy and contract review
Clear terms for your district’s review.
We work with district technology teams, counsel and county and regional offices to review the service, data flows and agreement. The review covers the information connected, who can access it and how it may be used.
| Review area | Topics to address | What to review with Quilt |
|---|---|---|
| FERPA | Authorized purposes and district oversight. | The service’s role, permitted uses, access controls and limits on disclosure. |
| AB 1584 · Education Code §49073.1 | Terms for contracts involving pupil records. | Data ownership, authorized use, access, security, incident notification and deletion provisions. |
| SOPIPA | Use and protection of student information. | Restrictions on advertising, sale and unrelated profiling, plus security and deletion commitments. |
| California Student Data Privacy Agreement | A documented agreement and supporting exhibits. | The CA-SDPA, covered data elements, subprocessors and the notice process for changes. |
| COPPA | Audience, collection practices and any consent requirements. | Quilt’s staff-facing scope. Any future student-facing service requires a separate privacy and consent review. |
| PPRA | Sensitive information and survey-related uses. | The sources and purposes your district authorizes. Quilt does not administer student surveys. |
| CCPA / CPRA | Applicable contractual restrictions on data use. | The parties’ roles and limits on retention, use and disclosure for the proposed service. |
| Accessibility | Accessibility requirements and supporting evidence. | The applicable accessibility standard, available assessment documentation, known gaps and remediation plans. |
Applicable requirements depend on the service and data involved. Your district and counsel review the agreement and supporting evidence before deployment.
Access control
Access follows the person, the relationship and the task.
A job title alone does not determine which records someone can see. Quilt checks district boundaries, assigned roles, current relationships and the purpose of each request.
Access rules use identity and relationship information from approved district systems. Changes take effect as those source records are updated through the configured connections.
- Access policies are versioned, reviewed and tested.
- Tools recheck authorization when they execute, including within multi-step agent tasks.
- Sensitive records can require additional restrictions and approvals defined by the district.
- Granted and denied requests are recorded for administrator review.
Keep district information separated
Quilt applies district boundaries across storage and processing, including the limited data retained for approved workflows.
- Database access is restricted by district.
- Document and search retrieval applies district and user permissions.
- Caches, stored files and background jobs are scoped to the district.
- Deployment-specific encryption and key-management options are reviewed during security assessment.
- Suspected cross-district access attempts are logged and investigated.
Control which AI providers receive data
Approved model providers receive only the context needed for a permitted task, under the terms and retention rules in your agreement.
- Enterprise or API agreements specify no training on district data and defined retention.
- A named subprocessor list includes model providers and the notice process for changes.
- Data classification and district policy determine eligible providers.
- Agent requests use approved endpoints rather than consumer AI accounts.
- Hosting locations and any regional restrictions are documented in the agreement.
Public information
Keep private records out of public searches.
An agent may need both district records and public research. Quilt handles those requests separately so public searches do not need identifying student information.
Threats and controls
Test the ways an agent could expose or misuse information.
Our threat model covers access failures, hostile instructions, misuse of tools and information leakage. Each category maps to preventive controls and tests. No individual control removes all risk.
Cross-district exposure
District boundaries across storage, retrieval and processing help prevent one district’s information reaching another.
Unauthorized access
Per-request and per-tool checks restrict records to the user’s and agent’s permitted scope.
Hostile user instructions
Instructions to bypass policy do not grant permissions. Access decisions remain outside the model.
Hostile documents and webpages
Retrieved content is treated as information, not authority to change permissions. Tool and outbound-access limits constrain its effects.
Misleading source material
Source classification, document provenance and administrator-defined authority help distinguish approved policy from untrusted content.
Tool misuse
Restricted tool sets, authorization checks and monitoring limit inappropriate combinations of otherwise permitted operations.
Connector attacks
Validated, typed parameters and bound queries reduce the risk of malicious input reaching source systems.
Outbound data leakage
Approved destinations, search controls and inspection of outgoing requests reduce exposure of private information.
Cached-answer exposure
District and user scope are included in cache controls to prevent answers being reused for an unauthorized audience.
Search-permission failures
Retrieval applies district and document-access restrictions before results are made available to the agent.
Unapproved AI providers
Provider selection follows data classification, district policy and the approved endpoint list.
Sensitive logs and traces
Redaction and separate retention rules limit identifying information in engineering diagnostics.
Runaway tasks and costs
Rate limits, budgets and limits on agent steps help contain expensive or repeated requests.
Independent testing
Request the current penetration-testing schedule, available findings and remediation status. Planned assessments are distinguished from completed work.
Testing and releases
Check permissions and answer quality before changes ship.
Model, prompt, tool and retrieval changes are evaluated against defined tests. Release review looks for changes in access behavior, accuracy, source support and task performance.
Material changes to model routing and supported behavior are documented for district review. New capabilities still require the access and approvals set for the district.
| Suite | What the tests check |
|---|---|
| Permissions | Requests without the required relationship or permission are denied, including cross-district attempts. |
| Accuracy | Answers agree with known results and source records. |
| Retrieval | Retrieval returns the permitted document, section and relevant version. |
| Citation | Sources support the statements attributed to them. |
| Prompt injection | Hostile instructions in requests, documents and webpages do not bypass controls. |
| Tool selection | Agents choose permitted tools and retrieve information appropriate to the task. |
| Statistics | Calculations follow district definitions, including edge cases and small-group handling. |
| Bias | Outputs are evaluated for inappropriate differences across demographic groups. |
| Regression | Changes are compared with prior behavior to identify regressions. |
Product boundaries
Your district approves the scope.
Quilt starts with a defined set of capabilities. Changes to access or permitted actions require the approvals and contractual steps established with your district.
Prebuilt and custom agents use the same controls. Adding an agent does not automatically expand its access or authorize new actions.
- Read-only in year one. Agents can retrieve, analyze, monitor and draft. They do not write to systems of record.
- Staff review and send communications. Agents prepare drafts rather than contacting families or staff independently.
- People make consequential decisions, including discipline, eligibility, placement, retention, identification, risk assessments and employee evaluation.
- Staff-facing use. No student-facing chatbot is included in the current scope.
- No model training on district data, including by approved model subprocessors.
- No identifying student information in public-search requests.
- Evidence must be reviewable. Outputs distinguish source-backed facts, calculations and interpretations, and flag missing support.
Security operations
Protect the service behind the agents.
Security also depends on how the service is hosted, developed, monitored and supported. Review these practices and deployment details with us during your vendor assessment.
Hosting and infrastructure
- Encrypt data in transit and at rest. Document key-management arrangements.
- Document hosting regions and any restrictions on data location.
- Restrict access to internal production services and administrative endpoints.
- Require multi-factor authentication for production access and log elevated activity.
- Encrypt backups and define recovery testing and expiration schedules.
Development and deployment
- Review code changes before deployment.
- Scan code, dependencies and repositories for vulnerabilities and secrets.
- Review new features and integrations for security risks.
- Use controlled deployments with a rollback process.
- Document independent assessment scope, timing and remediation status.
Vulnerabilities and incidents
- Monitor vulnerability disclosures and dependency alerts.
- Prioritize remediation by severity under documented timelines.
- Maintain an incident-response process with assigned responsibilities.
- Notify affected districts within the contractual timeframe and explain findings, response and next steps.
- Report a suspected vulnerability to security@quilt.education.
Employee access
- Grant access according to job responsibilities and remove it when no longer needed.
- Protect company devices with encryption, screen locks and remote management.
- Require multi-factor authentication and managed credentials.
- Apply personnel screening and confidentiality requirements for access to district data.
- Provide security training at onboarding and on a recurring schedule.
Before you sign
Quilt retains configuration, district context and activity records. Approved workflows may also retain indexes, caches, conversations or outputs. Your agreement defines what is stored, who may access it and the retention and deletion schedule.
Audit records document access, purposes, decisions and actions. Engineering traces support troubleshooting and performance analysis. They have separate retention rules, with identifying content limited or redacted.
Review the named providers that may receive district data, their roles, processing locations, retention terms and the process for notification and objections to changes.
Request current SOC 2 and independent-testing status, scope and available documentation. The review should identify what is completed, what is in progress and which controls or services are covered.
Export supported district content, configuration and audit records in the agreed formats. At the end of service, deletion of retained copies and backups follows the schedule in your agreement, with written confirmation.
Bring us your security requirements.
Request the security review packet or send your district’s questionnaire. We’ll review the architecture, data flows, provider terms and agreement with your team.