[ak5]

Summary

Telegram approval prompts now include a required operator-written authority description and explicitly cover one use of a configured capability. Admit at most 10 prompts per rolling minute, retaining the existing 32-pending limit and fail-closed behavior.

Motivation and scope

Advance #1's lightweight KeePass-backed Allow once / Deny flow. Validate descriptions, test concurrent-request binding and capacity/rate failures, and prove that an unavailable approval worker leaves ungated routes working. Apply the patches required by the current advisory gate: rustls 0.23.46, ctutils 0.4.4, rustls-webpki 0.103.16, Tokio 1.53.3, and webpki-root-certs 1.0.10. The rustls and Tokio patches overlap #84 and #86; reconcile those PRs after this change reaches main.

Issue #1 remains open: real Telegram delivery and deployed HTTPS/network isolation have not been verified. Session grants, reusable rules, and semantic resource/request-body approval are outside this change.

The vertical workload fixture also refreshes its Alpine CA package pin to 20261020-r0; the previous pinned package is no longer available in the configured repository. The container check verifies this fixture build.

Security impact

• Trust boundary changed: public operator-written authority descriptions now cross the existing Telegram boundary; human authority and local policy enforcement are unchanged. Descriptions must not contain secrets or private resources.
• Credential flow changed: no; approval remains before credential lookup/forwarding, and the operator-only bot token stays in KeePass.
• Threat model updated with approval scope, rate limits, restart behavior, and budget-exhaustion risk. No real credentials were used.

Documentation

• Updated README, admin/BotFather instructions, integration boundaries, verification notes, all four configuration examples, and E2E instructions.
• Added ADR 0009 for local capability-level approvals.

Verification

• mise run check (sequential, lower priority; bounded Rust workers)
• mise run e2e (connected two-password KDBX/admin/Telegram-worker/proxy/API flow and isolated Chrome virtual-passkey UI)
• Relative Markdown file links and git diff --check
• Real Telegram and deployed-host verification remain pending. The normal gate skips the optional upstream Hermes-source compatibility test when HERMES_SOURCE is absent.

Risk and rollback

• Risk: every gated name now requires a matching approval_descriptions entry (nonblank printable ASCII, at most 240 bytes). Missing or invalid entries reject configuration. Approval is capability-level; it does not review individual resources or request bodies. A workload can exhaust the per-process prompt budget and temporarily deny gated requests; restart resets the in-memory budget.
• Rollback: revert the feature change and restore its matching configuration, while retaining the dependency security patches. Deployment and immutable-image activation remain operator decisions.

This PR targets protected main. Deployment is separate; issue #1 remains open for live verification.