# Give an AI Agent a Smaller Access Contract Than Its Human Operator > Do not hand an AI agent your user session. Exchange it for a smaller, task-specific grant bounded by resource, action, purpose, time, spend, and delegation. Canonical URL: https://www.devobs.io/articles/delegated-agent-access-contract/ By: Ines Costa Published: 2023-05-04T02:28:54.779Z Updated: 2026-09-06T10:18:15.722Z Section: Authorization Reviewed: 2026-09-06 (UTC) ## Delegation must reduce authority An agent acting for a user should receive a new, bounded grant, never a reusable copy of the user session. A safe design is to compute effective authority as the intersection of the user’s current rights, the agent identity, the task grant, and live policy; if any layer denies an action, deny the request. [RFC 8693: OAuth 2.0 Token Exchange](https://datatracker.ietf.org/doc/html/rfc8693) defines a protocol for requesting and obtaining security tokens, including exchanges used for delegation or impersonation semantics, and notes that a resource server might exchange a received token for a more narrowly scoped token for a downstream service. ## Model the effective permission Represent the task grant as data: allowed resource selectors, verbs, purpose, expiry, maximum spend, call count, and whether another actor may be delegated. Keep the human subject and automated actor separate in logs. [RFC 8693: OAuth 2.0 Token Exchange](https://datatracker.ietf.org/doc/html/rfc8693) discusses delegation versus impersonation semantics for token exchange; in practice, preserving separate subject and actor identities in your exchanged-token design helps keep agent activity from becoming indistinguishable from a human click. ## Put the envelope in the credential Suppose a travel agent may find and reserve one Athens–Paris itinerary under €500 until 18:00. It may read the traveler profile fields required for booking, place a refundable hold, and ask for confirmation. It may not read unrelated documents, buy an upgrade, alter loyalty details, or delegate payment. [RFC 9396: OAuth 2.0 Rich Authorization Requests](https://www.rfc-editor.org/rfc/rfc9396.html) defines `authorization_details` for carrying fine-grained authorization data such as actions, locations, and amounts. Treat those fields as untrusted input and validate each one in server-side policy. ## Enforce purpose and spend outside scopes Scopes alone rarely express object identity, price ceilings, or a one-time transition. [RFC 9396: OAuth 2.0 Rich Authorization Requests](https://www.rfc-editor.org/rfc/rfc9396.html) explains why coarse-grained scopes are often insufficient for fine-grained requirements such as a transfer amount or access to particular resources. Put coarse audience and scope in the credential, then bind a task identifier to server-side policy containing the detailed envelope. Require idempotency keys for side effects, count spend at the authoritative ledger, and make the grant short-lived. For this pattern, prefer server-side task records that can be revoked immediately even if a previously issued token has not yet expired. ## Preserve the actor chain Design for prompt injection and confused-deputy requests as ordinary untrusted input. The planner can propose an action, but a separate enforcement point resolves resources and checks the envelope. Reject redirects to a different host, tools added after approval, and arguments whose normalized form changes their meaning. When the agent asks for more authority, create a new grant rather than silently widening the old one. ## A delegation contract to approve Before implementation, write down these decisions: which human authority is required; which agent identity appears in audit records; the exact resources and verbs; expiry and one-time-use rules; monetary and rate limits; whether onward delegation is forbidden; what event revokes the task. Turn each decision into an automated assertion or a rehearsal step. A design that exists only in prose will drift as callers, operators, and dependencies change. Record the owner and the signal that proves the control still works. ## Make the acceptance test concrete For the travel-booking task, record the human subject, agent actor, itinerary, €500 limit, expiry, and allowed actions. Attempt a different itinerary, a higher amount, and a request after revocation; each should be denied at the enforcement boundary. Repeat with a delayed dependency and a concurrent grant change, recording which grant state governed each decision. Keep the timestamps and grant identifiers so a reviewer can reconstruct the result. ## Start with one narrow task Choose one existing agent workflow and replace its inherited user token with a task-specific exchange. Exercise three negative cases: a different resource, a higher amount, and a request after revocation. Review the implementation again within 90 days, or sooner if the protocol, dependency, traffic shape, or threat model changes. Keep the task grant, its subject and actor identities, expiry, and the action that was denied in the test record. Show which boundary rejected the request after the grant changed, so responders can distinguish stale delegation from an application policy error. ## Source references - -