Guide
Delegated agents: decide what happens when the user is missing
An expense assistant starts a reimbursement while an employee is signed in. The user closes the browser, and the remaining work runs in a queue. Should the queued step keep acting for that employee?
First decide what the queued job is allowed to do. A delegated job acts for a verified person. A standing job uses permissions assigned to the service itself. Closing the browser must not silently turn the first kind into the second.
Decide what happens when the user is missing
The authorization foundation distinguishes workload identity, represented identity, and business authority. For the hypothetical expense workflow, turn those distinctions into an explicit decision table.
| Request condition | Intended treatment | Evidence or control required |
|---|---|---|
| Agent and verified employee are present | Evaluate the delegated operation | Accepted identity claims plus the employee's relevant entitlement |
| Employee is verified but not entitled to this reimbursement | Refuse the business action | Authoritative ownership or entitlement check |
| Employee identity is required but absent | Refuse; do not substitute a service role | Required-identity configuration and a missing-identity test |
| Client supplies an unsigned employee assertion | Reject for this production workflow | Verification methods restricted to the approved production configuration |
| Work is queued but still requires current user authority | Re-establish accepted authority before execution | Defined credential and entitlement refresh behavior |
| A reviewed workflow accepts the task under standing authority | Use the separately scoped background identity | Explicit acceptance conditions, narrow service authority, and retained initiating context |
The last row is a deliberate workflow design. It does not mean copying the user's email into a job record turns later service activity into verified delegation.
The agent still needs its own identity
Dome's delegated-agent configuration keeps the agent authenticated as itself while supplying accepted act-as identity to rules and audit. For an application-carried OIDC flow, the application sends an end-user token and Dome verifies it using the configured provider.
Other supported flows have different identity delivery mechanics. In particular, interactive OAuth supplies identity through its own access token rather than an additional act-as header. Select the flow first; do not combine examples from different flows.
For this expense application, require verified identity where the workflow needs it and restrict the accepted methods accordingly. Dome also documents an unverified development method. Its existence is a reason to inspect production configuration, not to describe every accepted assertion as verified.
Check the agent's permission and the employee's permission
For the expense example, require both checks to pass: the agent may request reimbursements, and this employee may act on this expense.
Your application must arrange those checks. Verifying the person doesn't tell you who owns the expense.
Dome makes accepted identity available to rules. The expense system should still establish the record relationship and valid transaction state. Keep those checks tied to the record being changed, not to a customer or owner label supplied by the agent.
What can change while the job waits?
Suppose the employee approved submission, but the queue executes later. The design must say whether approval remains valid, which state changes invalidate it, and which component checks those conditions.
If the operation needs a current employee entitlement, a previously accepted identity cannot be assumed fresh forever. If the operation has become an approved service task, make that transition explicit and scope the background identity to the accepted job.
Keep a record of who started the job, but describe how the later step was actually authorized. “Requested by employee A” and “executed under current authority of employee A” are different findings.
Test the missing and mismatched cases
Keep the same expense and agent. Vary the represented identity: valid employee, wrong employee, absent identity, rejected verification method, and a queued job whose authorization conditions have changed.
Use synthetic claims in policy simulation to test the rule logic, then test live verification separately. A simulator accepting a subject as input is not proof that the live endpoint would accept that person's identity.
Test that the queue pauses or refuses the job when required identity is missing. If it continues under service permissions, that must be an explicit, separately approved path.