Explainer
Choose a standing or delegated agent
A nightly reconciliation job and a support assistant opened by an employee may run the same code. They do not necessarily carry the same authority.
Ask whose permission the work needs. Running in a browser, a queue, or a scheduled job doesn't answer that question. A standing agent performs approved service work under its own identity. A delegated agent represents a verified person while remaining an identified software caller.
Decide whose authority the work requires
| Workload | Starting design | Question to resolve |
|---|---|---|
| Nightly reconciliation owned by a service team | Standing authority for a defined service task | Which operations does the service itself need? |
| Employee asks for their own case records | Delegated authority | How is the represented identity verified on the call? |
| Shared interactive client used by many employees | A configured interactive/delegated identity path | Does each call preserve the actual person's identity? |
| Background work queued after a user request | Depends on the business authorization contract | Must the later action still use the person's authority, or is it separately authorized service work? |
| Automation uses a fixed “system user” label | Not enough information | Is that a real verified relationship or only an argument string? |
Use the table to start the discussion, not to assign a mode automatically. A background execution time does not grant standing authority, and an email address in an argument does not establish delegation.
What happens when the report runs later?
In an illustrative support workflow, an employee requests a report that will be assembled later. At submission time, the application records the requested operation and the relevant user relationship.
Decide what the worker will be allowed to do when it picks up that report. If the report is a service-owned, preapproved operation, define that standing authority explicitly and restrict the worker accordingly. If each later data access must be authorized as the employee, preserve a supported, verifiable identity path and account for credential lifetime and current policy.
Do not silently fall back to a privileged standing agent when the user's assertion expires. That changes the authority model precisely when the original evidence is missing. Defer, reauthorize through the application's approved process, or fail according to the service contract.
Dome does not make this business decision on behalf of a queue. Its delegated-agent documentation explains how verified represented identity reaches rules and the operating record.
Check the workspace's requirements
A workspace can require represented identity and restrict accepted verification methods. Agent settings cannot weaken that floor. If the workspace requires a represented person, a standing workload needs a different, approved setup. Leaving out user context won't exempt it from that requirement.
For application-carried delegation, the agent authenticates as itself and sends the supported act-as assertion. Interactive OAuth is a separate documented path that supplies the person's identity from the interactive token; do not add a second conflicting act-as mechanism.
An unverified development assertion is not production identity evidence. Pick the supported verification method that meets the deployment's trust requirements, then test it.
Record the choice and the missing-identity behavior
| Record field | Standing workload | Delegated workload |
|---|---|---|
| Accountable software | Registered service agent | Registered application agent |
| Business authority | Approved service purpose and operations | Approved operations for the represented person/context |
| Missing person | Deliberately unnecessary for that approved task | Refuse when represented identity is required |
| Evidence | Agent, action, resource, policy, known outcome | Those facts plus applicable verified identity |
| Change that requires review | Service purpose or authority expands | User population, verification path, or represented operations change |
Keep the record with the service's operating instructions. Once delegated authority is chosen, configure the verification method and test valid, missing, tampered, and mismatched identity assertions.
Before implementing the worker, finish one sentence: “This report runs under the service's approved authority” or “Each data access must represent the employee.” Then use the record to check that your setup—and its failure behavior—matches that choice.