The documentation gap you found -- three pages, three different stories -- turns a deploy into a guessing game. But the bigger issue is that optional scopes at the consent prompt solve the wrong problem for agents. Even with Edit Permissions, the granted credential is static: it carries every privilege you approved for every request until the session expires or the token rotates. An agent running deploy does not need a credential that can also modify DNS or read account settings. The --scopes flag is a step forward but still bakes privilege into the token at login time rather than into each request at runtime. What agents actually need is per-request credential resolution. The agent holds no static token. Each tool call resolves a scoped credential from a policy-managed vault, and only the exact permissions for that operation are released. A deploy call gets deploy permissions. A read call gets read-only permissions. The agent never decides scope and never touches a raw credential. Architectures that separate policy from credential storage already work this way, and they eliminate the entire class of ambiguity your article identifies.