Topic 4: Scopes and rules
C.1 Least-privilege scopes per tool
Least privilege means a token should carry only the permissions the current job needs. If a token that can only read leaks, the damage is limited to reading. For the notes server the mapping is short, and we write it down as a table because it is the contract between the server, the authorization server's scope configuration, and the host:
| Capability | Kind | Scope needed | Where it is enforced |
|---|---|---|---|
search_notes | tool, read-only | notes:read | HTTP layer (required_scopes) |
notes://index, notes://{note_id} | resources | notes:read | HTTP layer |
summarise_topic | prompt | notes:read | HTTP layer |
create_note | tool, writes a file | notes:read and notes:write | HTTP layer plus the check inside the tool |
A future delete_note (not built in this course) | tool, destructive | a separate notes:delete | inside the tool |
Two design notes. First, scope names describe what the holder can do to which data, not which tool they may call: if we later add append_to_note, it should reuse notes:write rather than invent tool:append_to_note. Second, the spec says servers MUST respect scope hierarchies where a broader scope implies narrower ones. We have no hierarchy yet; if you add something like notes:admin, make the check in create_note accept it too.