Runtime Controls for University AI: PHI, PII, and Student Records

Why Application-Level Permissions Are Not Enough

Most universities control access to student information systems, health platforms, and financial aid databases through application-level permissions set at login. AI agents change this model. An agent authenticated once can chain multiple tool calls across systems in a single task, and application permissions do not evaluate each individual action against the data category it touches. Runtime controls address this gap by evaluating every tool call an agent attempts, not just the session it operates in, against a policy that reflects whether the underlying data is a FERPA education record, PHI, or other PII. This distinction matters because FERPA and HIPAA impose different obligations, and a single agent identity with broad access can create exposure under both statutes simultaneously.

Tool-Call Interception as the Enforcement Point

The most direct way to enforce least privilege for an AI agent is to intercept each tool call before it executes, rather than logging the action after the fact. This mirrors the zero trust model described in NIST SP 800-207, where every request is treated as untrusted until it is authorized against current policy, regardless of the agent's prior actions in the same session. For a university, this means an agent requesting a student's grades, an agent requesting a student's health record, and an agent requesting financial aid data should each be evaluated as separate authorization events, even if a single workflow triggers all three. Interception at this layer also creates the record needed to demonstrate, after the fact, that an agent's access was authorized under a specific policy rather than assumed from broad application permissions.

FERPA and HIPAA Obligations at the Agent Layer

FERPA protects personally identifiable information in education records and restricts disclosure without consent, regardless of the technology used to process it. HIPAA's Privacy and Security Rules require access controls, unique user identification, and audit controls specifically over protected health information. Joint guidance from HHS and the Department of Education confirms that a university's student health records may fall under FERPA, HIPAA, or both, depending on whether the campus health service operates as a HIPAA covered entity and how records are maintained. This means an agent accessing student health data may need to satisfy both regimes at once, and audit controls built only for FERPA accountability will not automatically satisfy HIPAA's Security Rule requirements. Where a third-party AI tool accesses education records, FERPA's school official exception permits this only if the institution retains direct control over how the data is used, which requires documented oversight of the agent's behavior rather than a general vendor agreement.