From Conversation to Delegation

Chapter 31 proved a proxy may act only through delegation. This chapter makes delegation executable — crossing the book’s most consequential line, from mediation that shapes information into action that changes the world:

Delegation is not “let the AI handle it.” It is a runtime contract specifying which actions may be taken, over which resources, under which conditions, for how long, and where human approval must re-enter.

The DelegationGrant becomes operational — principal, proxy, objective, permitted and prohibited actions, resources, scope, constraints, consequence limits, approval rules, validity window, re-delegation and disclosure policies, revocation, audit — with one separation running through everything: objective and authority are distinct. “Get me to Berlin on Tuesday” authorises searching, comparing, and reserving refundable fares ≤ €450 — never non-refundable purchase, destination changes, accommodation, or passport sharing. An agent inferring hundreds of objective-advancing actions may execute only the authorised subset. Trip-related is not trip-authorised.

The lifecycle: gate the action, not the task

USER OBJECTIVE → DELEGATION GRANT → PLAN → CANDIDATE ACTION
→ DELEGATION GATE → ALLOW / REQUIRE APPROVAL / DENY
→ EXECUTION → RECEIPT

The gate evaluates the actual proposed action — action ∈ permitted, resource ∈ permitted, scope match, constraints pass, grant live, consequence within threshold — never the task’s general shape. Least authority governs duration and breadth alike: just enough authority, for just the required action, for just long enough. Natural language may author the grant; an enforceable representation executes it — the LLM is never both interpreter and final enforcement boundary (South et al.’s translation of permissions into enforceable scopes, ICML 2025 position verified for Chapter 31, reused here as the stricter rule). And every action gate now has a data-use twin evaluated first:

objective → grant → plan → REQUIRED INFORMATION OPERATIONS
→ data-use gate → candidate action → action gate
→ execute → receipt

These two gates may not share one enforcement point. In a real runtime the information needed to judge data use (which sources, which operations, for what purpose) and the information needed to judge the action (which tool, which arguments, which target) become visible at different stages of execution — so authority has to be checked at each boundary where its object becomes observable. One responsibility, several locations; a data-use verdict reached where the full proposal is visible still has to control the action where the effect occurs.

The system justifies both why may I use this information (DataUseAuthority: principal, purpose, data scope, permitted/prohibited operations across ACCESS/PROCESS/INFER/RETAIN/REUSE/DISCLOSE, recipient and temporal scope, retention and derivative policy, revocation, provenance) and why may I perform this action. Necessity governs the first — required for the task, allowed by purpose and scope, minimum sufficient information (AgentDAM, NeurIPS 2025 D&B, verified: agents prone to unnecessary sensitive-information use; CI-Work, ACL 2026 Industry, verified: 15.8–50.9% violation rates with utility↔violation trade-off, scaling no cure). So BOOK FLIGHT permits calendar-for-date and loyalty-record processing — never whole-mailbox access, health inference, or unrelated-contact retention. Unnecessary use without external leak is still a privacy violation, scored as its own failure class alongside unauthorised access, inference, retention/reuse overreach, and disclosure overreach. Composed privilege is validated over the combined surface — calendar+email+contacts jointly reveal what no single permission suggests — with the mechanical rule that locally-valid permissions can still fail least privilege together. Revocation splits into authority-stopped versus flow-reversed, reported honestly per state (future access/inference/reuse stopped; derivatives, receipts, and already-made disclosures inventoried, including the irreversible). Receipts answer both gates’ questions and carry minimum-required content with their own retention, access control, and redaction — auditability never justifies an unlimited dossier.

Capability, authority, and competence stay three separate facts — can it, may it, will it do it well — because authority guarantees nothing about quality. Zhu et al. (NLLP 2025, verified via Anthology: consumer agent-to-agent negotiation across open and closed LLMs, inherently imbalanced dealing with large cross-model disparities, behavioural anomalies including overspending and unreasonable deals, risking financial loss) supplies the consequence-bounds evidence: authorised agents still decide badly, so grants carry explicit limits (spend caps, refundability floors, merchant sets, substitution rules, deadlines) and the book distinguishes POLICY VIOLATION (€510 attempted → DENY) from BAD-BUT-AUTHORISED (€430 poor choice → allowed, competence failure) — different diagnoses, different fixes, never merged.

Approvals, revocation, re-delegation, receipts

Approval tracks consequence and reversibility, never model confidence: READ/PREPARE automatic; low-consequence execute-with-receipt; medium preview-with-approval; high/irreversible fresh explicit approval — so 99% confidence purchases nothing. Revocation gates at action time: T2 revocation denies the T3 execution even mid-task, essential for long-running work. Re-delegation derives narrowing child grants (book-only-€600 parent → search-read-no-purchase 15-minute child; child ⊆ parent always) — capabilities delegated, never ambient authority. Every execution lands in a DelegationReceipt answering why was this allowed: grant id, action, resource, parameters, authority rule, approvals, result, external effects, timestamp, subagents — “agent booked flight” alone is unauditable.

MCP and A2A sit precisely as engineering context, verified where read: MCP authorisation (2026-07-28 spec, verified) is transport-level OAuth 2.1, OPTIONAL, least-privilege scoped — can this client access this resource, not what did this human authorise for this purpose. A2A’s in-task authorisation states and credential-binding guidance (user-supplied spec details, full verification pending) address agent communication and invocation — can these agents interact under whose policies — leaving scope, representation, validity, and revocation semantics to implementations. Neither substitutes the DelegationGrant; both complement it.

Testing scope, not obedience

EXP-32 (A conversation-only through E externally enforced grants with narrowing re-delegation, receipts, live revocation; identical objectives and models; travel/negotiation/subscription/calendar/procurement/cloud tasks) injects scope-creep temptation throughout: beneficial overspend denied anyway, unauthorised “better” substitutions, credential-broadening requests, €700-from-€500 child demands, post-expiry deals, revocation races, “sort the rest out” ambiguity left narrow, irrational-but-in-budget negotiation anomalies (Zhu as experimental inspiration), plus the data-use battery: unnecessary mailbox reads for calendar-solvable tasks, composed-privilege exposure across individually valid tools, benign-fact-to-sensitive-state inference, post-task derivative persistence, post-revocation inference survival, third-party confidences inside principal accounts, and the headline valid-action/invalid-data-use case — authorised outcome through unauthorised process, scored as failure. Scored separately: success, unauthorised/scope/constraint violations, approval calibration both directions, economic loss within authority, revocation/re-delegation failures, audit reconstructability — pursuing useful-autonomy-per-unit-authority-and-approval-burden without scalar collapse. Speech acts stay fenced throughout: SEND_MESSAGE, NEGOTIATE, MAKE_REPRESENTATION, ACCEPT_TERMS exist as explicitly granted capabilities only — because some actions do more than change external state. They make statements, promises, and commitments others attribute to the principal.

The proxy can now act within delegated authority. But what may it say in the principal’s name?

References

• Zhu, S. et al. (2025). The Automated but Risky Game. NLLP 2025. DOI 10.18653/v1/2025.nllp-1.2. Verified via Anthology: imbalanced dealing, overspending/unreasonable-deal anomalies. Used for consequence bounds + anomaly battery.
• South et al. ICML 2025 (verified Ch 31): permission-to-scope translation reused as the author/execute split.
• MCP Authorization spec (2026-07-28, verified via GitHub): transport-level OAuth 2.1, OPTIONAL, least-privilege. Used for the complement-not-substitute distinction.
• A2A spec details (AUTH_REQUIRED, credential binding): user-supplied, full verification pending. Used as engineering context with fence.
• SAGA / Bounded Agents (verified Ch 31): token-derivation + APC narrowing precedents for re-delegation.

Proposed experiment EXP-32: executable delegation under temptation

Status: PROPOSED. Per the design above (A–E, identical objectives/models, eight-case scope-creep battery, burden-aware scoring, speech capabilities fenced).