# Delegated identity for AI agents: constrain the task, check the resource > Separate the authorizing user, acting application, and task permissions in an agent architecture built around OAuth and explicit API enforcement. Canonical URL: https://www.devobs.io/articles/delegated-identity-for-ai-agents/ By: Elias Brooks Published: 2026-10-08T01:48:32.999Z Updated: 2026-10-08T01:48:32.999Z Section: Architecture Design delegated identity for AI agents by separating three questions: **who authorized the work, which application is acting, and what resources and actions are permitted?** Enforce those boundaries at the resource API, rather than treating the agent’s instructions as authorization. For example, an assistant asked to summarize two documents should receive permission to read those documents—not automatically inherit permission to edit everything its user can access. This follows the privilege-restriction principle in RFC 9700, which recommends limiting access-token privileges to the minimum required for the application or use case. [OAuth security best current practice](https://www.rfc-editor.org/rfc/rfc9700) The reference architecture below combines human authentication, application authorization, and resource-level permission checks, with application logic connecting them. ## Separate the authorizing user from the acting application OAuth provides a starting point for delegated access: applications accessing data and services on behalf of users. Ory’s Hydra introduction describes both this use case and server-to-server authorization without a user present. Keep those authorization contexts distinct, even when the same agent application supports both. [Ory Hydra documentation](https://www.ory.com/docs/network/hydra) For a user-delegated workflow, model three separate elements: - **Authorizing user:** the person whose authorization permits the task. - **Acting application:** the software executing the task and making API requests. - **Task authorization:** the approved actions, target resources, and operating limits. Use a separate run identifier for tracing individual executions. Do not use it as a substitute for either the user’s identity or the application’s authorization context. For work performed under a service’s own authority, represent that authority explicitly instead of attaching an unrelated human identity. In both cases, avoid asking the resource API to infer authority from a prompt, a document, or a user identifier supplied in tool arguments. ## Map identity, OAuth, and permissions to separate components Ory documents the following roles for its Ory Network services based on Kratos, Hydra, and Keto: | Responsibility | Component role | What the application still defines | | --- | --- | --- | | Human identity | Kratos provides identity and user management, including login, registration, recovery, and account management. | How the authenticated user is associated with an authorization request and task. | | Application authorization | Hydra provides OAuth 2.0 and OpenID Connect. | How requested access corresponds to the agent’s task and how APIs enforce the resulting authorization. | | Resource permissions | Keto supports fine-grained permissions and inheritance through groups, roles, and hierarchies. | Which subject, action, and resource are checked for each operation. | These roles are described in the introductions to [Kratos](https://www.ory.com/docs/network/kratos/intro), [Hydra](https://www.ory.com/docs/network/hydra), and [Keto](https://www.ory.com/docs/network/keto). Treat this as a proposed component architecture, not a claim of turnkey agent delegation. In this design, your application connects the authenticated user, acting application, approved task, and resource check. Assess configuration and feature support separately for a particular self-hosted deployment. ## Enforce the intersection of task authorization and resource access For the document-summary example, adopt a policy in which the application’s task authorization can narrow the user’s access but cannot expand it. A conceptual decision rule is: ```text allow request only when: the credential is valid for this API AND the authorization context is associated with the approved application and user AND the task authorization is active AND the requested action and resource are within the task AND the user has the required permission on that resource ``` This is a proposed application policy, not an Ory API or a standardized token format. Define how your deployment establishes each association rather than assuming every required field will be present in a token. To implement it, maintain a server-side task-authorization record containing the authorizing user, acting application, permitted operations, resource selection, expiry, and status. Associate that record with validated authorization context. If a caller supplies a task identifier, verify that the task belongs to the authorized application and user before using it; do not let a request field select another user’s authority. At the resource boundary: 1. Validate the access credential using the deployed authorization system’s supported mechanism. 2. Resolve the application, user, and task from trusted authorization context and server-side records. 3. Check that the task is active and permits the requested operation on the target resource. 4. Check the user’s resource permission. 5. Execute only if all required checks succeed; deny the operation if a required check cannot be completed. Keto’s documentation gives a concrete relationship example: a user belongs to the readers of a document. Such a relationship can support the resource-permission part of this design. Express the separate restriction to “only these two documents for this task” in your authorization model and integration. [Ory Keto documentation](https://www.ory.com/docs/network/keto) For an operation outside the approved task—such as changing a document while preparing a summary—require new authorization instead of silently broadening the task. ## Choose OAuth extensions for distinct security problems Several OAuth specifications address useful parts of delegated workflows. They are separate mechanisms, not interchangeable definitions of agent identity. **Token exchange: obtaining another security token.** RFC 8693 defines a protocol for requesting and obtaining security tokens from OAuth authorization servers, including tokens employing impersonation and delegation. It distinguishes the two: with delegation, the actor retains its own identity while representing another principal. Consider token exchange when a service needs an explicit exchange step across a boundary, and define the intended authorization semantics rather than treating every exchange as equivalent. [RFC 8693](https://www.rfc-editor.org/rfc/rfc8693) **Resource indicators: identifying the target API.** RFC 8707 lets a client signal which protected resource it wants to access. The authorization server can use that information to restrict the token’s intended audience. Use audience restriction alongside—not instead of—a separate check for which documents the task may access. [RFC 8707](https://www.rfc-editor.org/rfc/rfc8707) **Rich authorization requests: expressing detailed access requirements.** RFC 9396 defines `authorization_details` for fine-grained authorization data in OAuth messages. It includes an example with file paths and read/write permissions. Design authorization-server policy and resource-server checks to enforce the approved details; do not treat the client’s requested details as an authorization decision. [RFC 9396](https://www.rfc-editor.org/rfc/rfc9396) **DPoP: constraining token presentation.** RFC 9449 defines an application-level proof-of-possession mechanism for sender-constraining OAuth tokens and detecting replay attacks. Its access-token proof binds the token value to the holder of the key used to generate the signature. Treat proof of key possession and permission to perform a task as separate checks. The RFC also requires HTTPS: DPoP is not a replacement for secure transport. [RFC 9449](https://www.rfc-editor.org/rfc/rfc9449) Select these mechanisms only after confirming support across the authorization server, client, and resource APIs. This reference architecture does not assume that Hydra implements every extension listed here. Use RFC 9700 as the broader OAuth security baseline; it updates earlier guidance and deprecates some less-secure or insecure modes of operation. [RFC 9700](https://www.rfc-editor.org/rfc/rfc9700) ## Test denial paths and permission changes Start with one narrow workflow and test its boundaries before adding more tools. For the summary assistant, useful acceptance cases include: - Reading either approved document succeeds when the user has read permission. - Reading a third document fails, even if the user can access it outside this task. - Editing an approved document fails under a read-only task. - Substituting another application, user, or task fails the authorization-context checks. - Cancelling or expiring the task blocks subsequent operations. - Removing the user’s document permission affects later checks according to the system’s defined consistency behavior. - An unavailable required authorization check causes the operation to be denied. Define when permission changes become visible, including any caching, and test that contract rather than assuming immediate propagation. Record decision identifiers, the user and application, the requested operation, and the outcome without logging credentials. The central design rule is simple: **identify the user, authorize the application, constrain the task, and check the resource.** Keep those decisions explicit so that an agent’s ability to propose an action remains separate from its authority to execute it. ## Source references - - - - - - - -