Implementation evidence
Code-accessible review
The capstone did not stop at policy analysis. It checked actual backend and API behavior against expected security and privacy claims.
Public capstone excerpt
Threat modeling a real AI tutor
A public excerpt from my master's capstone: building an AI tutoring system, attacking its real trust boundaries, and turning the findings into remediation work.
Application signal
I built the AI product, threat-modeled how it could fail, attacked the assumptions in the code, and converted the work into fixes and a governance framework.
Builder -> attacker -> remediator
Paper Length
99 pages
Threat Scenarios
13
Attack Chains
4
Control Framework
28 controls
Summary
The full paper is a 99-page FERPA-focused framework for generative AI deployment in K-12. This public version keeps the strongest application signal: code-accessible threat modeling, compound attack-chain analysis, and governance controls that connect security work back to product decisions.
Published
May 2, 2026
Case BriefFindingsVisual ExplainerControlsReferences
01
Built the system
AskTA gave the capstone a real implementation surface: authentication, tutoring flows, API boundaries, logging, model calls, and product constraints.
02
Audited the code path
The review checked whether the architecture claims matched implementation behavior, then scored concrete STRIDE/DREAD scenarios.
03
Modeled compound failures
The strongest findings came from chaining ordinary product choices into larger AI security and privacy failures.
04
Turned findings into controls
The result is a 28-control framework tied to governance, deployment review, monitoring, and product remediation.
Why this artifact exists
Rolling out generative AI in K-12 is not just a prompt-quality question. The real risk lives where student data, vendor policy, identity systems, classroom workflows, model behavior, and district governance meet.
This capstone turns that problem into something reviewable. I used AskTA as a code-accessible case study, checked whether documentation claims matched implementation behavior, scored 13 threat scenarios, and converted the findings into a 28-control deployment framework.
What the paper does
- Treats FERPA as a system-design constraint, not a legal footnote.
- Puts threat modeling next to code review, procurement, vendor review, and day-to-day operations.
- Connects product choices like authentication, authorization, logging, safety controls, key management, and retention to deployment risk.
- Shows four compound attack chains without publishing raw exploit instructions.
Why it matters
District teams do not need another abstract AI debate. They need a way to ask better rollout questions: what data moves where, who can trigger risky flows, what gets logged, which controls are real in code, and how governance shows up in the actual product experience.
That is the gap this artifact tries to close.
Security method
STRIDE plus DREAD
Thirteen scenarios were scored by spoofing, tampering, repudiation, information disclosure, denial, privilege escalation, damage, reproducibility, exploitability, affected users, and discoverability.
AI-specific surface
Model safety controls
The review treated safety settings, prompt/response handling, student context, and review workflows as first-class security boundaries.
Governance output
28-control LKGCF
The framework maps deployment expectations to Govern, Map, Measure, and Manage functions instead of leaving risk as a launch memo.