NEMORIONDocsGiving someone permission to run an approved process is different from giving them every privilege that process uses.
Sovereign distinguishes a user from a service acting on their behalf. The Workflows design builds on that foundation with explicitly configured authority for individual operations. The examples here explain the authority model.
Suppose you ask an AI assistant to find information in your team's documents.
In an on-behalf-of flow, the request identifies both the service making the call and you as the represented user. Retrieval must honor your content permissions. The assistant should not gain access to a wider collection simply because its integration service has broader authority.
The audit record will also preserve the distinction between you reading a document directly and a service retrieving it on your behalf.
Now consider a workflow that performs an approved banking operation.
An authorized workflow administrator configures a banking node to use a service principal: an identity assigned to software rather than a person. That identity has the specific authority needed for the operation.
The administrator then grants an eligible person the required permissions to invoke the workflow and use the configured service authority through it. The person can run that approved process without receiving the service credential or a general-purpose banking privilege.
This is explicit delegation to a defined operation. It is not the assistant silently exceeding the permissions of a user it claims to represent.
A useful delegated workflow constrains what it will accept and what it will do. Permission to invoke it must not become permission to supply an arbitrary destination, change its privileged steps, or choose an unrelated credential.
The design therefore separates permission to run a workflow from authority to edit it or configure its identities. Inputs, tool access, and the scope of the service identity all matter.
These controls work together to bound the operation. An identity grant alone does not define what a workflow may do.
An accountable execution needs to retain three facts:
Audit history should make those differences visible. A service performing an operation should not appear as though the person directly possessed and exercised the service's privileges.