Field Notes  /  Security

Information security for campus AI — a framework for CIOs and CISOs.

The campus AI conversation is dominated by pedagogy and policy. The information-security conversation is quieter and, in some ways, more consequential. Here is the framework we use with security leaders to translate AI deployment decisions into a defensible risk posture.

May 14, 2026 | 12 min read | By Hamza Qureshi, Founder
AI Security Privacy FERPA Compliance

The campus AI conversation is dominated by pedagogy and policy. The information-security conversation is quieter and, in some ways, more consequential. A single data exposure traceable to a poorly-governed AI tool is the kind of incident a campus spends two years explaining to its accreditor, its state attorney general, and the parents of every student in the affected dataset.

This is the framework we use with CIOs, CISOs, and general counsel to translate the AI deployment conversation into a defensible risk posture.

Five threat surfaces unique to AI

Traditional infosec frameworks anticipate most of what AI introduces. A few categories are genuinely new and deserve named attention.

1. Prompt-pasting exfiltration

The default failure mode. A staff member, trying to be efficient, pastes a roster, a financial aid file, an advising note, or a transcript into a public AI tool. The data is now on a vendor's training-eligible logs (or, with default consumer accounts, training-eligible by design).

This is not exotic. It is happening on every campus right now. The mitigation is a combination of policy + a sanctioned alternative. Banning ChatGPT does not stop pasting; offering an enterprise-licensed equivalent with strong default settings does.

2. Retrieval-augmented data leakage

Once an institution stands up its own RAG-based agents, the security frontier moves. A poorly-scoped retrieval system can return information across role boundaries — a student-facing agent surfaces faculty payroll data because both lived in the same vector store with no access control on retrieval.

The fix is retrieval-time authorization, not document-level filters applied after the fact. Build the access control into the retrieval layer; do not assume the model will respect it.

3. Model-as-confused-deputy

An AI agent has been granted permissions to act in the institution's name — send an email, update a record, post to a channel. A cleverly-crafted prompt convinces the agent to use those permissions inappropriately. The agent is the confused deputy; the attacker borrowed its authority.

The mitigation is narrow, auditable tool scopes, human-in-the-loop on any consequential action, and rate-limiting that catches anomalous patterns.

4. Training-data contamination

If the institution is fine-tuning or training models on its own data, a poisoned input — accidental or adversarial — can produce a model that misclassifies, leaks, or recommends incorrectly. This is rarer for most campuses (few are training their own models), but it is real for institutions building custom AI in research contexts.

5. Vendor subprocessor sprawl

The AI vendor uses a foundation model from a different company, hosted on a third cloud, with logs reviewed by a fourth contractor. Your data lives across four subprocessors, three of which you didn't sign a contract with. The audit pathway across them is unclear.

The mitigation is written subprocessor disclosure in every AI vendor contract, plus a contractual right to terminate if subprocessors change.

The data-classification map every campus needs

Before any AI tool is procured, the institution needs a current, authoritative classification of its data. We use a four-tier model that has held up across institution types.

Marketing copy, public web content, course catalog, published research, press materials. Free to use in any AI tool.
Tier 1 — Public
Strategy docs, financial models in draft, HR planning, vendor evaluations. Use only in an enterprise-licensed AI tool with zero-retention configuration.
Tier 2 — Internal
FERPA-protected student records, GLBA-protected financial aid data, HIPAA-adjacent health center records, personnel files. Use only in a contracted AI tool with a BAA / DPA, named subprocessors, US data residency, and audit logging.
Tier 3 — Confidential
Export-controlled research, IRB-governed human-subjects data, classified research, attorney-privileged communications. Default: not approved for any general-purpose AI tool. Approved only with explicit, named exceptions.
Tier 4 — Restricted

Every employee should be able to recite which tier their work falls in without thinking. Every AI tool should be tagged in the procurement system with the maximum tier it can handle. The two should be enforced by access controls, not by hope.

FERPA, GLBA, HIPAA — the practical reality

These three frameworks are the floor, not the ceiling.

  • FERPA. Student records are protected by default. An AI vendor that processes student records is a "school official" with a "legitimate educational interest" only if there is a written agreement, the vendor is under direct institutional control, and the vendor is restricted from secondary use of the data. Most consumer-grade AI tools fail at least two of those tests out of the box.
  • GLBA. Financial aid records are GLBA-protected. The Safeguards Rule was updated in 2023 and has specific requirements for vendor management, encryption, and incident response. An AI tool touching aid data needs to be inside the Safeguards Rule perimeter.
  • HIPAA. If the campus has a health or counseling center, HIPAA applies to that data. An AI tool touching that data requires a Business Associate Agreement. Almost no consumer AI tool will sign one.

The implication: a campus running on consumer-tier AI is, in many cases, already out of compliance. The cheapest path to compliance is an enterprise license of a major model with the right contractual posture — which is now widely available at a per-seat cost most CIOs can absorb.

The procurement checklist we use

For every AI vendor that will touch Tier 2, 3, or 4 data, the following items must be answered in writing before signature.

  1. SOC 2 Type II report, current within the last 12 months, provided under NDA.
  2. Data residency, named region(s), with contractual restriction against movement.
  3. Training-data carveout — explicit, written, that institutional data is not used to train or fine-tune any model.
  4. Subprocessor list, named entities, with notification rights on changes.
  5. Audit log access — inspectable by the institution, exportable, retained for a contractually-defined period.
  6. Incident response SLA — under 24 hours for known incidents, with support for the institution's downstream notification obligations.
  7. Data extraction and deletion — 30-day extraction window on termination, cryptographic deletion with certificate.
  8. DPA / BAA / FERPA addendum — as applicable to the data tier.
  9. Insurance — cyber liability, named coverage levels, institution listed as additional insured where appropriate.
  10. Right to audit — contractual, with reasonable notice, at the institution's discretion.

A vendor that pushes back on more than two of these is signaling they are not ready for higher-ed procurement. Move on.

Shadow AI is the actual risk

Almost every campus we audit has more shadow AI than sanctioned AI. Staff and faculty using consumer accounts with institutional data, because there is no sanctioned alternative or because the sanctioned alternative is poorly rolled out.

The mitigation is not a stronger ban. It is a better default. The institutions that meaningfully reduce shadow AI do four things:

  1. License an enterprise platform that is good enough that staff actually prefer it.
  2. Make access frictionless — SSO from day one, no separate signup, available on day-one for new hires.
  3. Communicate aggressively about what data is and is not allowed where.
  4. Audit, periodically and visibly, for unsanctioned use — and lead with education, not discipline, on first contact.

You will not eliminate shadow AI. You can move it from 90% of usage to under 20% in twelve months with a credible default.

The board-level conversation

A CISO bringing an AI security framework to the board should bring four artifacts.

  1. A current threat picture. What is the campus exposed to, ranked by likelihood and impact.
  2. A current usage picture. What AI is in use across the institution, sanctioned and unsanctioned.
  3. A 12-month investment plan. Platform, training, governance, audit.
  4. A measurable target. "Shadow AI under 20% of total usage by Q4," "100% of sanctioned tools under audit by year-end," "0 confirmed data-class-3 exposures."

Boards do not need every technical detail. They need a credible owner, a credible plan, and a credible target. The institutions that produce all three on the same page are the ones whose boards are confident in the AI conversation.

Bottom line

AI security is not a separate domain from the rest of campus information security. It is the same discipline applied to a faster-moving threat surface. The framework above — five new threat surfaces, a four-tier data classification, a ten-point procurement checklist, and a shadow-AI mitigation strategy — is what we see hold up across institution types.

The campuses that get this right will be invisible to the public. No headlines. No incidents. Just the steady, durable adoption of capability that compounds quietly.

The campuses that get it wrong will be the ones whose CIO gets quoted in their state's higher-ed newsletter, exactly once.