See what Trussed catches that your current tool misses, live in your stack

    No migration, no commitment, just a direct comparison in your environment.

    Set up a technical evaluation
    Compliance Guide

    FERPA School Official Exception for AI Tools

    An AI tool can qualify as a FERPA school official under 34 CFR 99.31(a)(1) only if it performs an institutional function the school would otherwise handle internally, operates under the institution's direct control regarding use and maintenance of education records, and is contractually bound to use limitation and non-redisclosure. The regulation is technology-neutral, so agentic architecture, API access, or Model Context Protocol integrations do not change the legal test, but they do change how direct control and use limitation must be demonstrated in practice.

    Three FERPA Criteria for AI as a School Official

    An AI tool meets the school official exception only when it satisfies all three of the following conditions simultaneously.

    Institutional Function

    Performs a service the school would otherwise use employees to perform.

    Direct Control

    Institution controls how records are used and maintained, typically via contract terms.

    Use Limitation

    Data use is restricted to the disclosed purpose, with no unauthorized redisclosure.

    What the School Official Exception Actually Requires

    FERPA generally prohibits disclosure of personally identifiable information from education records without consent, but 34 CFR 99.31(a)(1)(i)(B) creates a narrow exception for outside parties treated as school officials. To qualify, a vendor or tool must perform an institutional service or function the school would otherwise use its own employees to perform, remain under the direct control of the institution regarding use and maintenance of the records, and be subject to FERPA's use and redisclosure limitations. Institutions are also required to state, in their annual FERPA notification, the criteria they use to determine who qualifies as a school official, including contractors and other outside parties. None of these requirements reference technology type. The test is functional: what the tool does with the data and who controls that use, not how the tool is built.

    Why AI Agents Complicate the Direct Control Analysis

    Direct control has historically been satisfied through contract language: purpose limitation clauses, security requirements, and data destruction or return obligations. That approach assumed a relatively static integration, where a vendor's system processed data in predictable, auditable ways. Agentic AI systems introduce a different pattern. An AI agent can autonomously decide which tools to call, which records to retrieve, and how to combine or forward that data across multiple steps or sub-systems. This tool-call decision layer did not exist in the vendor relationships that current FERPA guidance was written around. The legal standard has not changed, but the evidence required to satisfy it has. A contract stating that a vendor will limit use of student data is no longer sufficient on its own if the underlying system can dynamically expand its own data access or route information to services the contract did not anticipate.

    No AI-Specific FERPA Guidance Exists Yet

    There is no confirmed Department of Education, FPCO, or Student Privacy Policy Office guidance, rulemaking, or enforcement action that specifically addresses AI agents or automated tool-calling under FERPA. Existing SPPO guidance on online educational service providers predates the current generation of agentic and multi-step AI tools. This leaves an interpretive gap: institutions and vendors must apply a regulation and guidance written for simpler vendor relationships to systems capable of autonomous, multi-hop data access. In the absence of AI-specific rulemaking, the burden falls on institutions to demonstrate, through contracts and technical evidence, that direct control and use limitation are actually being enforced, not just documented.

    Governance Implications for Institutions and Vendors

    Legitimate educational interest must be tied to a defined institutional function. A broad or open-ended AI use case weakens the school official argument because it becomes harder to show the tool is performing a specific, bounded service the school would otherwise staff internally. Use limitation requires demonstrable enforcement, not just policy language, once an agent can dynamically determine what data to access or how to use it. Institutions should assign clear accountability for verifying, on a recurring basis, that vendor practices continue to satisfy direct control and use limitation, particularly as vendors update model capabilities or add new tool integrations. Multi-vendor AI stacks add further complexity: if an underlying model provider is separate from the primary EdTech vendor, each party's role in processing education records may need independent evaluation against the same criteria.

    In Short

    The legal test for AI as a school official is unchanged: institutional function, direct control, and use limitation. What has changed is the burden of proof. Contract language alone cannot demonstrate control over a system capable of making its own data access decisions; institutions need runtime evidence to back it up.

    Mapping FERPA Requirements to Runtime Controls

    These are the technical controls institutions and vendors can point to as evidence that direct control and use limitation are enforced in practice, not just promised in a contract.

    1. 1

      Permission Scoping

      Restrict an AI agent's data access to only the records and fields required for the specific institutional function it performs, mirroring the legitimate educational interest standard.

    2. 2

      Tool-Call Governance

      Require approval or policy checks before an agent invokes a tool that touches education records, rather than allowing standing, unreviewed access.

    3. 3

      Audit Logging

      Log tool calls and data retrievals so actual agent behavior can be compared against the contracted purpose and use limitation during a review or audit.

    4. 4

      Redisclosure Prevention

      Control data flow so agent outputs are not passed to third-party models, plugins, or external services outside the contracted school-official relationship.

    5. 5

      Session-Level Access

      Grant access per task or session rather than broad, persistent access, to demonstrate institutional control over each specific instance of data use.

    6. 6

      Retention Enforcement

      Apply deletion and retention rules to model context, caches, and logs, consistent with contractual data destruction and return obligations.

    Vendor Evaluation Checklist

    Questions institutions can use to evaluate whether an AI vendor's practices support the school official exception.

    • Can the vendor document the specific institutional function its AI tool performs, consistent with 34 CFR 99.31(a)(1)(i)(B)?
    • What technical controls demonstrate direct institutional control over AI agent behavior, not just contractual promises?
    • How does the vendor prevent agents from redisclosing student data to third-party models or external services outside the contracted purpose?
    • What retention and deletion mechanisms apply to AI processing artifacts, including logs, caches, and context data?
    • How will ongoing compliance with use limitation be audited as the vendor's AI capabilities or integrations change over time?

    Bring Runtime Enforcement to Your FERPA Compliance Program

    Contractual language alone cannot demonstrate direct control over autonomous AI agents. Runtime governance, permission scoping, and audit logging give institutions and vendors the evidence needed to support the school official exception in practice.

    Explore Runtime Governance