Pipelines, agents and tokens
Nothing that runs for a person can reach further than that person.
- Pipelines act as
- The pipeline itself · the person who ran it
- Saving checks
- What the change adds
- Tokens
- A ceiling over the roles
Access control is only as good as its weakest path. A person who may not read the OP40 test results must not get them by building a pipeline that copies them somewhere they can read, by asking the AI assistant, or through a token. This page describes how each of those paths is held to the same rules.
Whom a pipeline acts as
| The run | Acts as |
|---|---|
| Started by hand (Run), or a node test | The person who started it |
| A pipeline set to act as a principal | That API client, agent or pipeline |
| Triggered (schedule, webhook, topic, connector event) with Advanced Access Control | The pipeline itself, pipeline:<id> |
| Triggered on Foundation | The shared pipeline runtime |
So a manual run never reaches further than the person running it, and a triggered run reaches what the pipeline was given, not what its author holds.
Saving checks what the pipeline reaches
A pipeline that publishes to a topic or calls a function reaches those resources every time it runs. When you save a change that adds reach (a new publish node, a function call, a different topic), MaestroHub checks that you hold that access, as if you were doing it yourself:
- Topics are checked for the action the node takes (publish, read), with shares, stewardships and denies on the branches above counted.
- Functions are checked at their connection and effect: a write function needs the right to run write functions there.
If you don't hold it, nothing is saved: This change needs access you don't hold, naming the node, the resource and the permission, for example You can't add publish on topic '…/OP40-TEST/process/leak_rate' (node "Publish result"): you don't hold topic:publish there. Ask someone who holds it to make this change, or ask an administrator for the right.
Only what the change adds is checked. Moving nodes, changing a value or editing code asks nothing. The check runs on every edition, and the same check applies to saves made through the AI assistant, the API and an agent, each as the person or principal saving.
After a save that changes the reach, the platform writes the pipeline's own rights to match it, recorded in the audit trail as a share by the platform on behalf of the person who saved. The rights belong to the pipeline, not to its author: the pipeline keeps working when the author leaves, and deleting the pipeline removes them.
A deny on a pipeline
To stop a pipeline reaching something, write a deny rule on it: deny pipeline:<id> publish on a topic branch, for example. Its triggered runs are then refused there. A deny on a pipeline keeps applying after a licence downgrade. A manual run acts as the person who runs it, so the deny on the pipeline does not apply to it; a deny on the person does.
Tokens are a ceiling
A personal access token carries scopes, and the scopes cap what its owner's roles allow; they never add to them. To create a token with a scope you must hold everything the scope covers. A request outside the token's scopes is refused with INSUFFICIENT_SCOPE. Revoking a token, or deactivating its owner, ends it at once, and its open live connections are closed.
Every audit record made with a token names the token (credential_id), so the audit trail can show everything one token did: View token events in the record's detail. See Audit Trail.
Agents and API clients
An agent's token must be given scopes, within what the agent was granted. An older agent token without scopes is held to the agent's current grants. An API client without scopes can do nothing.
Agents, API clients and pipelines never grant access: they cannot share, appoint stewards, write denies, decide requests or break the glass, even when their role holds the permission.
The AI assistant
Maestro, the assistant inside the product (Beta), and external AI clients over MCP act as the signed-in person: every tool call is decided against that person's access, with their token's scopes as the ceiling, and recorded in the audit trail with both the person and the assistant. Asking Maestro to build a pipeline runs the same save check as building it by hand.