[RECIPE PROPOSAL] oncall-task-scoped-authority: 为待命代理团队设定的任务范围权限,每次工具调用进行验证

1. What is the intent/purpose of your new recipe? In what way will it help the ADK community? A multi-agent recipe for contrib/Python/ that shows how to give a sub-agent less authority than its parent at the argument level, and check it at the ADK plugin callback on every tool call. Scenario: an on-call coordinator receives a production alert for web-checkout and transfers it to a remediation_agent. The coordinator holds the on-call role as a signed warrant (read any logs; scale or restart web-* up to ten replicas; page; hand off). Before the transfer it narrows that role into a ticket bound to the remediation agent's own key: web-checkout only, at most four replicas, ten minutes. The logs the remediation agent reads contain an injected line telling it to scale web-checkout to 50, scale db-primary, and restart web-payments. All three are refused before the tool body runs; the one legitimate change goes through. ADK's transfer_to_agent is checked the same way, so the sub-agent cannot pass the alert on. What it teaches that the current recipes do not: - Why a system prompt, a tool allowlist, a shared API key or a static role cannot express "this service, at most four replicas, for ten minutes, verified where the tool runs", and what can. - Narrowing as a checked operation: a child warrant that widens any bound is refused at grant time, not at call time. - Per-agent keys: each agent signs its own tool calls, so a ticket copied out of one agent is useless in another. - A refusal returned from before_tool_callback replaces the tool result and ADK skips the body; the tools record their own entry so the tests can prove "refused before it ran", not "ran, then reported". Shape follows the merged attenu-guard-customer-service recipe: offline demo.py through the real Runner with a scripted BaseLlm, demo.py --live for a real model, tests that need no key. ### 2. What language is your recipe implemented in (e.g. Python, Go, etc.)? Python (3.11+), google-adk 2.9.x. ### 3. Will this be a deployable recipe, either by having a Dockerfile, or by utilizing Vertex AI? No. It is a standalone recipe that runs offline by default and against Gemini via AI Studio or Vertex AI with demo.py --live / adk run app. No Dockerfile. ### 4. What GCP services or third-party APIs (Salesforce, Jira, etc.) are required? None for the default run. A live run needs a Gemini model via GOOGLE_API_KEY or a Vertex AI project, exactly as the other Python recipes. The only non-Google dependency is the PyPI package tenuo (Apache-2.0, https://GitHub.com/tenuo-ai/tenuo), which provides the signed warrants and the verifier. No hosted service is involved. ### 5. Who (individual/team) will own and maintain this? tenuo-ai (team), point of contact @aimable100. I maintain the tenuo library the recipe uses. ### 6. Please include any additional information you'd like to share. - Proposed folder: …