AI Agent Governance Checklist for School District Operations

Why AI Agent Governance Differs From General AI Policy in K-12

Most district AI policies to date address acceptable use of generative tools by staff and students. AI agents introduce a different governance problem. An agent that schedules meetings, processes records requests, or triages IT helpdesk tickets does not just generate text, it takes actions inside district systems, often through API-level access to student information systems and communication platforms. That action-taking capability is the distinct risk surface governance leaders need to address separately from content-generation policy. The U.S. Department of Education's Office of Educational Technology has encouraged districts to evaluate AI tools for data privacy, security, and bias before adoption, but this evaluation needs to extend specifically to what an agent can do once integrated, not only what it produces.

FERPA's School Official Exception and Third-Party AI Agents

FERPA restricts disclosure of personally identifiable information from education records without consent, subject to exceptions including the school official exception. Under this exception, a third party performing an institutional service, including a technology provider operating an AI agent, must remain under the direct control of the school regarding how education record data is used and maintained. The Family Policy Compliance Office has been explicit that districts remain responsible for FERPA compliance even when data processing is contracted to a vendor. This means governance leaders cannot treat vendor assurances as sufficient. Districts need documented control over what an AI agent can access, how long it retains data, and what actions it is authorized to take, independent of vendor claims. State student data privacy laws layer additional restrictions on top of FERPA in many states, so legal review specific to the district's state is a necessary step before granting any agent system access.

Runtime Oversight: The Gap Left by Pre-Deployment Review Alone

NIST's AI Risk Management Framework organizes AI risk management into govern, map, measure, and manage functions, and treats post-deployment monitoring as a distinct lifecycle stage from initial risk assessment. This distinction matters for districts. A one-time security review at procurement does not account for how an agent behaves in production, especially as it is connected to additional systems or given expanded permissions over time. CISA and NSA joint guidance on deploying AI systems securely recommends applying least-privilege access and logging AI system interactions specifically to detect anomalous behavior after deployment, not only to satisfy a pre-launch checklist. For district environments, this translates to runtime policy enforcement: continuously verifying that an agent's actual behavior, including which records it touches and which tool calls it makes, stays within its authorized scope, rather than relying solely on the permissions granted at setup.

Evaluation Criteria for Vendor AI Agents Touching District Data

• Confirm whether the agent operates under a distinct, auditable identity or shares credentials with other systems.
• Ask what specific student data fields and system actions the agent can access, and whether access is scoped to least privilege.
• Require evidence of logging for all tool calls and data access events, not just aggregate usage reporting.
• Review how the vendor's data handling aligns with the school official exception and any applicable state student privacy statutes.
• Clarify the process for modifying or revoking agent permissions after deployment, and how quickly access changes take effect.