After the term rollover, staff can see students who are not theirs

When a teacher, advisor or administrator can open a student who is not theirs, the role model is usually correct and the recomputation is missing. Access was granted when somebody was assigned to a section, a caseload or a faculty, and nothing took it away when that assignment ended. Every term adds a layer, and the rollover is simply when a year of accumulated grants becomes visible at once — often because a teacher opens last year's class list and finds this year's names in it, or the reverse.

That distinction decides the remedy. If the roles were wrong, you redesign roles, which is weeks of work and a migration. If the grants were never recomputed, you change when the decision is made — from write time to read time — and the roles survive untouched. The diagnosis takes an afternoon and it is worth doing before anyone reopens the permissions model.

Diff one staff account across the rollover boundary

Take a single account with a long history — a head of year, a counsellor, a teacher who has moved between departments — and enumerate everything it can reach, before and after the boundary. In a school of 1,200 students, an account that should reach 150 and reaches 900 is the whole finding, and the diff shows you which grants did it.

1. Generate the expected set from the roster: the students this person should be able to see today, derived only from current enrolments, assignments and relationships. This is the ground truth and it has to be computed, not asked for.
2. Generate the actual set by calling the API as that user, paginating fully. Do not sample. The extra students are always at the end of a list nobody scrolls.
3. Diff the two. Every student in actual and not in expected is a grant to trace.
4. For each extra student, find the grant that allows it: a role assignment, a section membership, a group, an override, a support role, or a report the user can run.
5. Record when each grant was created and what was supposed to end it. In most systems the answer to the second half is nothing.
6. Repeat the whole exercise against the reporting layer, separately. A user who is correctly scoped in the application and unscoped in a dashboard has full access, and the dashboard is usually nobody's idea of a permissions surface.

Grant-on-assignment versus scope-at-query-time

Underneath the individual leaks there is one architectural choice, and most products make it early and by accident, in the first sprint where somebody needed a permissions check on a Friday.

The second column is the safer default because its failures are loud. A staff member who cannot see a student they need will tell you within the hour; a staff member who can see 400 students they do not need will never mention it. Where query-time evaluation is too slow, keep an entitlement table as a cache — but then treat it as a cache honestly: enumerate every event that invalidates it, and accept that a nightly rebuild leaves a mid-term transfer wrong for up to 24 hours.

The four leaks that survive a correct role model

• Stale section membership. The roster import adds new sections and never removes old memberships, so a teacher accumulates every class they have ever taught. It is invisible until somebody counts.
• Support and impersonation roles. Broad by construction, held by your own staff, and rarely time-boxed or logged at the read level. A school's security reviewer will ask about this one specifically, and the acceptable answer involves an expiry, a recorded reason and a read log.
• Reporting views. A Power BI, Looker or Metabase dashboard connected straight to the database applies none of the application's row-level scope. This is also the path by which student work leaves the boundary and reaches tools nobody scoped, which is the argument in where the line sits on training with student work.
• Exports and downloads. A correctly scoped export is still a file that leaves your control the moment it is saved, emailed or uploaded elsewhere — and a vendor's promise about what it does not keep is narrower than most teams assume, as what a no-retention term actually covers sets out.

There is a fifth surface that behaves like staff access but is not: guardian access. It is derived from the same graph, with relationships that change more often and more messily than staff assignments, and it needs the same date-aware evaluation. The consequences of getting that wrong reach families rather than staff — the scenario worked through in half the parents never install the app shows why the fallback channels matter as much as the app permission.

Former students, and the ambiguity nobody resolves

Some over-access is not a bug at all. Should a counsellor keep access to a student who left in March? Should a teacher be able to reopen last year's marks to answer an appeal, or write a reference in October for a student who graduated in June? Every institution has a real answer to these and almost none has it written where an engineer can implement it.

• Ask for the decision explicitly, per role and per record type, and record who made it. Software that quietly picks the permissive option is making policy on the institution's behalf.
• Implement the answer as a time-boxed grant with a review date rather than an indefinite one. Something like 90 days after the enrolment ends is a common shape, and any figure the school has actually agreed beats an unbounded default.
• Log reads for anything outside the current enrolment. The read log is what turns an awkward question into a factual answer six months later.
• Note that access scope also carries the data-protection argument for European operations: a legitimate-interests case rests on staff seeing only what their role requires. Which basis a school app should rely on is argued in consent or legitimate interest for a school app.

Over-permission does not generate complaints. It generates one incident, years later, in which every grant that was never revoked is read aloud in the same meeting.

What to build, in the order that pays

1. The access predicate as one function, date-aware, used by every read path including search and reporting.
2. A generated expected-set test that runs in continuous integration for 20 or 30 staff across a rollover boundary, seeded with the awkward cases: a teacher who changed department, a counsellor on leave, a student who transferred mid-term.
3. Expiry on every temporary grant, with no way to create one without an end date. The absence of that field is why cover access is permanent.
4. Read logging on records outside the current enrolment, retained deliberately and shown to the institution.
5. A rollover runbook that includes permission recomputation as a named step with a verification query, rather than assuming the import handles it.
6. The same predicate applied to anything an assistant retrieves. A retrieval layer that ignores row-level scope hands a staff member records their account cannot open, and where the model runs changes how provable that is — the deployment question in private LLM deployment.

Single sign-on sits deliberately outside this page: authentication decides who somebody is, and everything above is about what that identity may reach, which is a separate system and a separate failure mode. Building the predicate, the tests and the retrieval-side enforcement is the kind of work we scope under AI agents and automation when an assistant is involved. The rest of this silo sits under student data privacy, engineered, within our education and edtech work.

• access control
• student privacy
• term rollover
• system design