How Microsoft Copilot's data access model creates FERPA exposure
Microsoft 365 Copilot does not apply independent access logic to student data. It surfaces content that the signed-in user already has permission to access under existing Microsoft 365 permission models, including SharePoint, OneDrive, Teams, and Exchange. This means Copilot's FERPA exposure risk originates primarily from pre-existing over-permissioned repositories and mailboxes rather than from any AI-specific access mechanism.
Student information systems and learning management systems are not natively indexed by Copilot. Access to SIS or LMS data requires an explicit connector, built through Microsoft Graph connectors or a Copilot Studio agent, which introduces a separate governance surface with its own permission and vendor-terms review requirements.
FERPA (34 CFR Part 99) requires written consent before disclosing personally identifiable information from education records, subject to enumerated exceptions. The school official exception under 34 CFR ยง99.31(a)(1) permits disclosure to a contracted service provider only when the institution retains direct control over that party's use and maintenance of education records for authorized purposes. No primary Microsoft or U.S. Department of Education source confirms that Microsoft 365 Copilot is inherently FERPA compliant. Outcomes depend on tenant configuration, license tier, and how connectors to SIS or LMS platforms are governed. Department of Education PTAC guidance on online educational services predates generative AI and does not directly address AI summarization or retrieval behavior, leaving institutions to map Copilot activity against existing FERPA obligations rather than an AI-specific standard.
Where native controls leave gaps
Point-in-time configuration does not by itself provide continuous verification that Copilot's behavior stays within FERPA-permitted boundaries as staff roles change, new connectors are added, or sensitivity labeling drifts out of alignment with actual repository contents. Native Microsoft 365 and Purview controls are configuration-based: Restricted Content Discovery operates at the SharePoint site level, sensitivity labeling depends on comprehensive and current tagging, and audit logging availability varies by license tier. These mechanisms establish the boundaries within which Copilot operates once configured, but they do not enforce policy at the moment Copilot attempts to access or summarize a specific piece of content.
This is the gap that runtime governance addresses as a category: enforcing agent permissions and tool access at the point of use, rather than relying solely on upstream permission configuration and periodic audit review. Trussed AI provides runtime governance and security for enterprise AI agents, including runtime policy enforcement, agent identity and permissions management, and audit logging for AI agent activity. For institutions running Copilot alongside Copilot Studio agents or other AI tools connected to SIS or LMS platforms, this kind of runtime oversight complements Microsoft 365 admin and Purview controls rather than replacing the underlying permissions and labeling work described below.
Configuration is necessary, not sufficient
Restricted Content Discovery, sensitivity labels, and Purview Audit set boundaries. Runtime policy enforcement helps keep agent behavior inside those boundaries as connectors, roles, and content change over time.