Phase 7 · AI Access Controls + LLM Authorization · Lesson 3 of 4
Watch: An AI Over-Privileged, Then Scoped Down
Video
·
10 min
·
+10 pts
You have the theory: four authorization questions, three identity types, and delegated-over-standing tokens. This video shows the difference in practice on one assistant. First it runs the common way — a single broad service token that lets it read across every user's data — and a routine request quietly surfaces something it should never have reached. Then the same assistant is re-provisioned to act on behalf of the current user with narrowly-scoped, short-lived tokens, and the identical request returns only what that user is entitled to.
Watch for the moment the fix lands, because it is architectural, not a prompt tweak: the data the assistant shouldn't see becomes unreachable because the token no longer carries the right, not because the model was told to behave. That is the whole lesson of this module in one change — least privilege enforced at the identity and data layers, where an injection or a bug can't argue its way past.
Invalid YouTube ID or URL: PLACEHOLDER_AI_ACCESS_SCOPING
No environment needed
Conceptual walkthrough — nothing to run. The value is seeing the same request succeed at reaching too much, then be cleanly blocked, and naming why: the token stopped carrying the right. In an assessment that is the question you answer — not "did we tell the model to be careful," but "what does its token actually permit, and what proves it."
What to carry forward
Over-privilege is the default failure mode of AI systems, because broad access is the path of least resistance during a build. The correction is the same every time: resolve the real identity, borrow only that identity's authority, scope it narrowly, and let it expire. Next you will do this deliberately — grant six different personas the minimum models, data, and actions each one needs, and watch the summary flag anything you over-grant.