Objective and professional context
The fictional controller can only read public document F1. Three model-shaped messages request that read, an email send and an ID outside the allowlist. An exact envelope and exact tool arguments are part of the contract. In a real service, document access would be checked against the signed-in owner on every read, including after retrieval. Nothing in a document or model response can grant a new tool.
Your practical assignment
Identify accepted and rejected cases, then add an unexpected argument to the accepted request. Explain why a correct-looking JSON object can still be unauthorized.
Worked solution and interpretation
Only the exact read_document request for F1 is accepted. send_email and a read of F2 are rejected. An extra argument makes the formerly accepted envelope invalid. The reference makes no external call and does not execute a live agent.
Verification, mistakes and limits
Schema validity and authority are separate checks. A real agent also needs bounded calls, time/cost limits, read-after-retrieval authorization and human approval for consequential actions. A retrieved citation does not prove a generated claim is supported. This exercise has a deterministic boundary, not an infallible factual judge.
Continue with evidence
Keep the unchanged data, your implementation and a changed-input result with a short note explaining what you can and cannot conclude. These free companions do not change saved course progress. The published course catalogue shows deeper assignments available under your current permissions. Keep your conclusions proportional to the evidence you have inspected.
Authoritative reference
Official technical method reference; it does not validate fictional outcomes or your own software environment.
Try the activity before reading its reference. Keep your sources, commands and assumptions with your work. Companion activities are unsaved self-practice and do not award a certificate or change lesson progress.