The MesaNet Portal hosts a "Rail Broadcasts" application accessible through a JSON gateway API. A low-privilege operator account can interact with several broadcast endpoints, but a confidential note owned by a privileged automated user sits just out of reach. The challenge requires chaining the broadcast creation pipeline with the automated oversight system to escalate access without ever touching the privileged session directly.
Objective: Using the gateway, probe the `/api/notes/get` endpoint with sequential note IDs to find the one note your session cannot read.
Context: The portal also exposes a notes API through the gateway. Your `operator` session has clearance L3. Try fetching notes by integer ID — start from 1 and increment. Pay close attention to the difference between error messages: some IDs will say the note doesn't exist, while one specific ID gives a different error.
Only reveal the ones you need. Claude tracks how many you used to calibrate the feedback.
Try sending `POST /gateway` with `endpoint: "/api/notes/get"` and `data: {"id": 1}`. Then increment the ID. The wording of error responses changes at a specific ID — that difference is meaningful.
One note ID returns `"Insufficient permissions to read this note"` instead of `"Note not found"`. That phrasing means the note EXISTS but your clearance level is too low. Every other ID either succeeds or says it wasn't found.
Note ID `6` is the one that returns the permissions error. All other IDs (5, 7, 8, etc.) either return content or "Note not found". Note 6 has `classification: confidential` and belongs to a user other than you.
Chat with a spoiler-safe tutor for this step. It uses only this lab spec and gives the smallest useful nudge first.
Tell the tutor what you tried, where you got stuck, or paste the response/error you are seeing.
Enjoying Hintru? Buy me a coffee ☕ ☕