Adversarial Scenario Simulations

Three attacks on a simulated adaptive-learning system: an attacker who keeps scaffolding at maximum, a prerequisite graph that is wrong, and a verifier with a valid token who over-approves.

PurposeProbe three attack scenarios for design questions.

StatusDetermined by setup — in each script the headline number comes from a value the script itself sets.

Touches NCFCA codeNo. Self-contained numpy simulations. None implements the verifier rate limit or any other mechanism from a specification.

AttributionCode AI-generated (tool not recorded). Run in the lab; results unchanged.

ReviewedBy no outside party. The reading below was done when this page was built, directly from the code and CSV.

1. I-channel starvation (denial of state)

An attacker fixes the friction signal at “high”, so scaffolding stays at maximum. The rule is that mastery can only be confirmed after an unassisted production. A forcing function sets scaffolding to zero every eighth session.

Mastery rises by 0.024 a session and reaches 1.0 at session 42. It rises under maximum scaffolding too, so the student is slowed, not trapped.
Confirmation is possible at sessions 32, 40 and 48: forced sessions after mastery passes 0.75. The script prints “FIX EFFECTIVE”.
There is no control run without the forcing function. The “VULNERABILITY CONFIRMED” branch fires only when confirmation never becomes possible, which the rule guarantees when scaffolding never reaches zero. The comparison that would show the fix helps is never made.
Whether the student can succeed on the unassisted attempt is not modelled. The forced session counts as a confirmation opportunity whatever the accuracy.

2. Incorrect ontology

The prerequisite graph is wrong. For 30 simulated students, a “penalty” is drawn uniformly between 0.15 and 0.40 and subtracted from their progress.

The average degradation reported, 28.1%, is the average of the penalties the script drew.
“Detected” means the penalty exceeded 0.28, a fixed cut-off on the injected value itself. 15 of 30 students (50%) are “detected”, which is what a uniform draw over 0.15–0.40 gives (48% expected).
No detector runs. The script’s closing line, that the system often fails to detect a wrong prerequisite structure, restates the cut-off.

3. Malicious authorized actor

A verifier with a valid token over-approves from session 11, with a 25% chance each session. “Detection” flags a session when recorded mastery exceeds true mastery by more than 0.25.

10 malicious approvals occur. The largest gap in the whole run is 0.215, so the flag never fires: 0 of 40 sessions.
Recorded mastery reaches 1.0 at session 16 and true mastery at session 21. Both saturate, so the gap closes to zero and later malicious approvals change nothing.
The detector reads the student’s true mastery. A real system does not have that number, so this detector cannot exist outside the simulation.
The script prints that the system “struggles to reliably detect deliberate over-approval”. The cut-off of 0.25 is above anything the setup can produce.
The verifier-rate limit from the hardening addendum (12 approvals in 20 seconds) is not modelled. The simulation has no timestamps.

What they show

Three scenarios worth designing against. The malicious-verifier case also names a real problem: detecting over-approval needs a signal that does not depend on the approver, such as an unassisted re-check.

What they do not show

That any of the three attacks succeeds or is stopped in a real system.
That any mitigation works.
Anything about the four-channel architecture.

Download (unchanged from the lab’s run): ichannel_starvation_test.py · ichannel_starvation_results.csv · incorrect_ontology_attack_test.py · incorrect_ontology_results.csv · malicious_authorized_actor_test.py · malicious_actor_results.csv
Scripts write to a path from the lab’s own machine (/home/workdir/artifacts/); change it to run them elsewhere. Seed 42, so a rerun reproduces the CSV.