Delegated authorization
Delegated authorization lets one actor perform specified operations on behalf of another. For an agent, the access decision needs to account for both the software making the request and the person or service it acts for.
On-behalf-of access is another way to describe this arrangement. An agent's own permission to use a tool and a user's permission to access a record are different inputs. Specify how both permissions affect the decision. The OAuth Token Exchange specification distinguishes delegation from impersonation; exchanging a token is a mechanism, not a complete business authorization policy.
Explore Dome: Access · Docs: Govern per end user.
Decide whose permissions the agent should use
Suppose a help-desk assistant opens tickets for employees. When it retrieves an employee's existing requests, access may need to follow that employee's entitlement. By contrast, a scheduled queue monitor may perform a defined service function without representing a current employee.
| Work pattern | Authority to establish |
|---|---|
| Employee asks for their own case details | Agent identity plus verified represented-user context |
| Scheduled system-health check | Approved service authority for the workload |
| Agent continues a previously approved task | Explicit scope, duration, and renewal conditions for that authority |
A scheduled service may not need a human identity. But a request that requires a verified user should not silently fall back to broader service access.
Decide whose permissions should apply before choosing how to carry the identity in a header or token.
Explore Dome: Access · Docs: Agent identity.
Verify who the agent is acting for
If the assistant sends an employee's email address with a request, the receiving service must verify that identity. An address generated by the model or typed into a request argument is not enough.
For the help-desk request, specify which employee is represented, which assistant may act for them, which service accepts that context, what work is permitted, and when the permission expires. Handle missing or unverifiable identity according to an explicit policy.
Dome supports configured verification of end-user context alongside an agent identity. Its per-user tutorial explains the setup. Signing in to a browser does not, by itself, pass verified user context to downstream tool calls.
Explore Dome: Access · Docs: Govern per end user.
Check where the user's access limits are enforced
A backend may not receive the user identity that an earlier service verified. If the server uses one shared backend credential, the backend may see only the service account. The architecture must specify where the represented user's limits are enforced.
To test the help-desk design, request the same ticket on behalf of two employees with different access. Then try missing or invalid user context. Check that the result follows the configured permissions and that the application doesn't retry a denied request using broader service access.
Record the agent and the identity it acts for, including whether that identity was verified. Use authentication versus authorization for token and grant basics. For each connection, be clear about whose permissions apply and which component enforces them.
Explore Dome: Authorization · Docs: Authorization model.