Pipeline Identity
Why pipelines have an identity
A pipeline reads and writes real data: it queries entities, creates and updates them, saves time-series values, and — increasingly — answers questions on behalf of a person through an AI assistant. The question "who is this pipeline acting as?" therefore matters just as much for a pipeline as it does for a logged-in user.
In earlier versions a pipeline ran with implicit, unrestricted access — as if it were the system itself. That is convenient but unsafe: any pipeline could touch any data, and there was no way to say "this pipeline may only do what this person is allowed to do."
Today every pipeline runs under an identity. Just like a user, a pipeline now has a name it acts as, a set of roles, and — through data permissions — a well-defined set of data it is allowed to see and change. Nothing is hidden by the user interface; access is decided and enforced on the server.
This changes the security model, not the way you build pipelines. You still author nodes and data flows exactly as before. What changed is that the platform now attaches an identity to each pipeline run and checks it against data permissions.
The two modes
A pipeline runs in one of two modes.
Service account — the default
By default a pipeline acts as its own service account: a dedicated, non-human identity that belongs to the pipeline's adapter. The service account has a fixed set of roles, and those roles decide what the pipeline can read and write. This is the right mode for scheduled jobs, imports, integrations, and any pipeline that does its work independently of a specific person.
See Service Accounts.
Delegation — on behalf of the calling user
Some pipelines run because a person asked them to — for example the AI chat in an application, where a user asks a question and a pipeline answers it. For these user-facing flows a pipeline can run in delegation mode: its work is carried out under the calling user's identity, so the user only ever sees the data they themselves are allowed to see.
To stay safe, a delegated run is limited to what both sides may do — the effective roles are the intersection of the service account's roles and the user's roles. A powerful service account can never lend a user more access than that user already has.
See Delegation.
How access is actually decided
Whichever mode is used, the outcome is the same: the identity's roles decide what data the pipeline can touch, through the platform's data permissions. To give a pipeline broad access, give its service account the roles that carry the permissions it needs. For least privilege, link a dedicated service account that carries only what that one pipeline needs.
Where each piece lives
| Concern | Where it is managed |
|---|---|
| A pipeline's default identity | On its adapter — every adapter has a mandatory pipeline service account (see Service Accounts) |
| An override for a single pipeline | A link from the pipeline to another service account |
| The roles an identity carries | The service account's declaration and the roles it is assigned |
| Running on behalf of a user | Enabled per AI node and a token-carrying HTTP trigger (see Delegation) |
| Seeing and repairing it all | Refinery Studio |
Related topics
- Service Accounts — the default identity every pipeline runs under
- Delegation — running a pipeline on behalf of the calling user
- Managing Pipeline Identity in Refinery Studio
- Authentication — the underlying OAuth flows (delegation grant, role intersection)
- Users and Roles — how roles and data permissions work