The separation between capability, authority, and verification is the right framing. Most agent frameworks conflate all three: the agent that can run a tool is implicitly authorized to run it, and the tool's response is treated as verified fact. That breaks in production when an agent hallucinates a syntactically valid tool call.

The fail-closed design is harder than it looks. Most frameworks don't have a default deny at the identity level. The agent's context is mutable, and an instruction-injection attack can override the 'only call this tool' rule. The fix is to move the authority boundary from the prompt to the credential: the tool should reject calls that arent cryptographically scoped to a specific session and action. That way, even if the agent's instructions are overridden, the tool still enforces the original policy.

One thing to watch: who grants the authority and how does it survive across agent restarts? If authority is a one-time grant in the agent's context window, it evaporates on token limit reset. A durable session identity that persists authority across runs makes the pattern production-ready.