Summary

  • A new individual IETF draft puts the user in charge of selecting an agent's scopes, duration and call ceilings, then personally handing over a one-use connection credential.
  • The user's free-text description of the job travels with the grant as evidence. The service enforces the selected controls. If the sentence says “one invoice” and the box grants broad write access, the box wins.

A Wish Is Not a Permission

The user types “send the one invoice I approved.” Next to it sits a permission choice wide enough to edit every invoice. The form has two instructions, but the server has one rule: it checks the selected permission. Christopher Emerson's revised proposal keeps the sentence for an auditor. If the screen makes the sentence look like a limit, its reassuring prose is doing the work of a lock it never installed.

The 27 October announcement introduces revision 01. The IETF Datatracker records an active individual Internet-Draft with no RFC stream or IETF endorsement. It proposes a design, not a rule already imposed on agent platforms. Revision 01's new section on recording intent makes the key allocation of authority explicit: the application declares its purpose, the user writes their intent, and both texts are retained with consent, introspection, audit and revocation records. Neither is sent to a policy engine to decide what the token may do.

That decision is made in a more prosaic place. A person signs into the resource application, opens its connection management surface and chooses permissions from a ceiling the application calculates from that person's existing rights. They choose a duration and may set per-period call ceilings. They can inspect earlier grants and revoke one before adding another. An optional authenticator ceremony can sign a commitment to the exact selected scopes, time, ceilings, purpose and user text. The application then shows a short-lived, one-use connection credential once.

The person hands it to the agent, which exchanges it for a scoped access token that the agent cannot renew. The draft's human-in-the-loop proposal puts the grant decision and delivery in the user's context, rather than in an automated path managed by the agent.

The Checkboxes Get the Final Vote

The credential is only the beginning of the control chain. The proposal requires introspection on each later API call. That check applies the scopes and ceilings the user selected and records access. A service can mark a scope as requiring confirmation for each use. For that operation, introspection pauses the call and identifies its exact request by digest. The person approves that request in their own context with a user-verified authenticator; the agent retries with the resulting attestation identifier. A declined request stays declined, and revoking the connection makes a pending confirmation unusable.

These details make a general “yes, I trust my assistant” much harder to smuggle into a specific destructive action. They also expose the consent screen's central design burden. The user may write a beautifully narrow instruction in ordinary language. The resource application still needs to offer a correspondingly narrow structured scope, duration and count, or a confirm-each-time switch for the consequential act. The draft says the prose is evidence for later review. It must not widen a grant, and automatic interpretation of it is merely advisory for human review. Nor does the prose itself shrink a broad checked scope.

A user can state a wish; the service must make a boundary the machine can actually enforce.

Revision 00 already proposed the human handoff. Revision 01 expands the sequence with selected call ceilings, review of existing connections, a presence ceremony, per-action confirmation and revocation closure. Its newly added intent section refuses the seductive shortcut of turning an open-ended sentence into a secret policy interpreter. That avoids one class of semantic guessing while placing a bright light on the granularity of the actual controls.

The draft reports an author-operated hosted implementation. That statement establishes what the author says has been built; it does not supply an independent conformance test. Its own security discussion identifies a sharper question: if the agent controls the device or surface that renders the confirmation, a signed “user verification” step may fail to prove what the user actually saw. The glass between agent and person in this design is only as good as the person-side surface.

Original records