A school district needs Claude to summarize IEPs with different visibility for teachers versus admins. What must requirements capture?

School-district Claude summarization of IEPs involves highly sensitive student education records with different visibility for teachers versus admins. Requirements must capture authorization boundaries mapped into Claude application design so role-based access control governs which fields, documents, and summary depths each role may retrieve or see. Conceptually this works because authorization is not a UI garnish—it must shape tools, retrieval filters, prompt-time data injection, and logging so teachers do not receive admin-only content and admins do not overshare into teacher channels.

Using one shared admin key pasted into every teacher client fails by concept: shared secrets destroy accountability and collapse role boundaries. Echoing full student PII to every role and relying on UI-level masking for privacy fails because client-side masking does not stop the raw data from being transmitted or inspected; the privacy failure happens before any mask is ever drawn. Assuming sharing is safe because administrators already approved the system fails because a one-time approval is not an access-control mechanism; it says nothing about which role should see which IEP fields on any given request, so unrestricted sharing still reaches teachers or admins who should not see that content.

Exam caveat: education/PII items reward authorization-boundary requirements over convenience sharing. Shared admin keys are a classic wrong answer. Keep IEP teacher-versus-admin framing. Operational check: define role matrices for IEP fields, enforce server-side filters before Claude context assembly, prohibit shared admin credentials in teacher clients, and audit summary outputs by role during UAT.