Philterd

Talk to an Expert

Tell us about your stack and the privacy problems you're trying to solve. We typically respond within one business day.

Prefer to skip the form? Pick a time on our calendar →
or send a message

Please do not enter PII or PHI in this form. If you need to share an example, use a sanitized one.

← All industries

Education & EdTech

PII Redaction for Education & EdTech

Self-hosted redaction for K-12 districts, universities, education service agencies, and edtech vendors. FERPA-compliant student-record handling for analytics, research, AI-tutoring features, and inter-institution data sharing — runs in your VPC, no student data sent to a third-party API.

Or deploy Philter yourself →

The education PII problem

FERPA (20 USC 1232g) treats “personally identifiable information” broadly: not just name and SSN but also “other information that, alone or in combination, is linked or linkable to a specific student” that would allow identification by someone in the school community. That linkable-in-combination clause is the part most automated tools miss — the redaction has to handle context, not just patterns.

The deployment-shape constraint is just as strict. Sending student records to a third-party redaction API generally requires the API vendor to be a FERPA “school official” under the institutional-control test — a hurdle most SaaS vendors don’t clear. Self-hosting sidesteps the institutional-control question entirely: the data never leaves the school’s authorized environment.

How Philterd handles education

FERPA-aligned student-record redaction

Names, student IDs, dates of birth, contact info, and the linkable-in-combination identifiers that FERPA treats as PII. The FERPA policy is the starting point; tune for your SIS-specific identifier patterns.

Runs inside your authorized environment

K-12 districts, universities, and ESAs can’t hand student data to a third-party redaction service without triggering the FERPA school-official analysis. Philter runs in your existing cloud or on-prem environment — no new vendor, no new institutional-control question.

Research-data de-identification

Institutional review boards approve research on de-identified student data — learning analytics, retention research, intervention studies. Per-student consistent pseudonymization and date shifting preserve the analytical structure without preserving identifiability.

AI-tutoring guardrails

Edtech AI features routinely call hosted LLMs (OpenAI, Anthropic, Bedrock) for tutoring, feedback, and assessment. Philter AI Proxy redacts student PII from prompts before the LLM provider sees them — keeps the AI feature’s data path defensible under FERPA.

Inter-institution data sharing

Articulation agreements, transcript exchanges, longitudinal-data-system contributions, state-reporting submissions. Redact identifiers before the data leaves the institution; preserve the cohort and longitudinal structure the receiving party needs.

Open source — defensible to the registrar

When the registrar, compliance office, or counsel asks how a redaction decision is made, the answer is in source code you can read, not vendor assertions. FERPA reviewers reward auditability.

Ready-to-use policies

Apache 2.0 policies from the open source policy library — download and load into your Philter instance.

Education v1.0.0

FERPA Student Records Redaction

Remove personally identifiable information from student educational records per FERPA (20 USC 1232g; 34 CFR Part 99).

FERPAeducationK-12higher-ed

Browse all redaction policies →

Recent writing on education

Why API-Based Redaction is a Security Antipattern

Sending sensitive data to a third-party redaction API creates the security holes you're trying to close. Here's why true data sovereignty requires a self-hosted engine — and how Philter delivers it.

Building a Privacy-Aware RAG System

RAG pipelines have two distinct PII leak vectors: ingestion and inference. A defense-in-depth blueprint with code, using Philter, Philter AI Proxy, and the rest of the Philterd toolkit.

All blog posts →

Where education teams start

  1. Inventory the student-data surfaces. SIS exports, LMS interaction logs, advising notes, financial-aid correspondence, behavioral-incident records, transcript-evaluation files. Each one has a different shape and a different downstream consumer.
  2. Deploy Philter inside your environment. District-managed AWS / Azure / GCP account; or on-prem if that’s the policy. No third-party data path.
  3. Start from the FERPA student-records policy and tune for your SIS’s identifier patterns — student IDs, state IDs, federal IDs (FAFSA, NSLDS) where applicable.
  4. For research data, layer per-student consistent pseudonymization so an IRB-approved researcher can do cohort and longitudinal work without ever holding identifiers.
  5. For AI features, sit Philter AI Proxy between the application and the LLM. The tutoring product team owns the application; the proxy owns the FERPA defensibility of the data path.

Common deployments

1. Learning-analytics data warehouse. A university or district wants to run learning-analytics on student interaction data from the LMS, the SIS, the advising system, and the early-warning platform. Redact identifying fields at warehouse-ingest so the analytics team works on a FERPA-de-identified corpus; the operational systems retain the original records under their own access controls.

2. AI-tutoring product for K-12 or higher-ed. An edtech vendor (or an in-house product team) builds an AI-tutoring feature that calls a hosted LLM. Student work, free-text questions, and conversation context all flow through the LLM. Philter AI Proxy sits between the tutoring application and the model provider; PII gets redacted before the prompt leaves the institutional environment.

3. IRB-approved research on student data. A faculty researcher proposes a study on intervention efficacy, retention patterns, or learning outcomes. The IRB approves on the condition that the researcher works on de-identified data. Philter is the de-identification step; per-student consistent pseudonymization keeps cohort and longitudinal analyses intact; date shifting handles the temporal structure.

What teams need to be careful about

  • The directory-information opt-out. FERPA allows institutions to designate certain fields (name, address, phone, photo, major, dates of attendance) as “directory information” that can be released without consent — unless the student has opted out. Redaction policies need to honor the opt-out at the document level, not just the field level. Track the opt-out state alongside the data.
  • PII-by-combination. FERPA’s “linkable in combination” clause means a small class size + a specific grade level + a specific demographic can identify a student even with name removed. The redaction layer handles direct identifiers; the disclosure-review process handles the residual re-identification risk. Both are needed.
  • K-12 vs higher-ed differences. K-12 districts answer to state education agencies and follow more prescriptive data-handling rules; higher-ed institutions have more autonomy but more complex consent regimes (FERPA + HIPAA crossover for student health services, GLBA for financial-aid records). The redaction layer is the same; the policy layered on top differs.

Build PII redaction into your education pipeline

FERPA conversations get faster when the answer to “where does the data go?” is “nowhere — it stays in our environment.” Talk to engineers about the deployment shape that makes the institutional-control question disappear.

Or deploy Philter yourself →