Concepts

Delegation and identity

How Orchestrator Zero meets the eight requirements of agent delegation under an untrusted model, what is built, what is partly built and what is planned.

For: cluster operators and plugin authors.

A delegated action needs a traceable principal and authority that narrows at each hand-off, even when the model cannot be trusted. The paper Delegation Without Trust (Dantuluri and Sundi, 2026) defines eight requirements for multi-agent systems. The mapping below identifies what Orchestrator Zero has built, what is partial and what remains planned.

Orchestrator Zero's starting point is that the platform, not the model, holds every credential and sees every call: nodes reach Temporal, the models and the connections only through the edge, so the edge can record and refuse what passes. Everything below is enforced there or in the runtime outside the model's control.

#	Requirement	Status	How
R1	Delegation-chain integrity and on-behalf-of provenance	Built	The edge links authority blocks to their parents and each audit entry to its job tree. See envelope provenance.
R2	Details	Details	Details
R3	Sender-constrained credentials	Built inside the cluster; bearer outside it	Activity bindings tie credentials to the assigned node; outside services still receive bearer tokens. See binding scope.
R4	Short-lived issuance	Built	Node certificates last 24 hours. A connection's token is minted for one call's scope and reused for the same scope while it has more than ten minutes left. A call binding lasts as long as its activity may run (at most 24 hours). An identity token lasts five minutes at most, never longer than the job's authority or the call's binding, and is minted per call
R5	Rotation	Built	Node certificates renew on their own; the gateway's signing key rotates every 30 days; the audit key and the secrets key rotate on command; each tenant's issuer keys rotate with `oz0 tenant oidc rotate`, with the next key published before it signs
R6	Revocation propagation	Partly built	A kill switch stops an agent, a tool or a tenant across the fleet; a withdrawn grant, a retired agent or a revoked key is refused at the edge on the next call; a long wait is checked again before a call runs. Each envelope carries the tenant's authority epoch, for fencing every call of the trees that lost their authority at once
R7	Tamper-evident audit	Built	The audit trail is a hash chain per tenant, the gateway keeps a signed chain of its own of every model call, and evidence bundles are signed and check offline
R8	Model-independent enforcement	Built	Tool policy, grants, budgets, depth and child limits, approvals, kill switches and the envelope's narrowing are decided by the edge and the runtime, never by asking a model; a model can only ask for less

Delegation-chain integrity

Every job's authority envelope names the person, team or service it runs for. Each hop adds an edge-MACed block linked to its parent by hash: child jobs, flow tools, colleague questions, inbound MCP or A2A tasks, and Ask hand-overs.

A block belongs to a job only once its run starts on it, and only the edge names it. Starting an already-running job ID again, or a node naming another job's envelope, changes nothing.

Every audit entry names the envelope and starter. oz0 evidence verify checks that the envelope belongs to the entry's job tree.

Credentials bound to a node

Nodes authenticate with mTLS certificates. Every activity's call binding names its node and certificate. The edge refuses a model call, connection token or sealed token requested by another node.

The default --call-binding auto requires bindings from nodes whose runtimes support them. For a node that reports an older runtime and has not shown bindings, it allows an unbound call only for a job whose task the edge recently handed that node. The edge discards an unbound token request's arguments before minting a token. See the compatibility rules.

With --call-binding required, the edge mints no connection token for a node request without a binding. An identity token always needs a binding, regardless of that setting. Connection tokens can be sealed to the node.

An outside service receives a bearer token. It lives five minutes, names one audience and the node that ran the call, and is available only to the node the edge assigned the call to.

Authority attenuation

Requirement

Attenuation: authority only narrows down the chain

Status

Built

How

Each block takes the meet of its parent's scopes and the child's own, lower ceilings and one more level of depth; a runtime may ask for less, and a request for more is refused at the edge.

oz0 evidence verify re-derives every chain offline and reports any widening.

The edge checks each tool call against the plugin's grants as they are now and against the job's envelope: a call of another plugin's function that the envelope's scopes do not cover is refused, so a grant made while a tree runs reaches only new trees, and a child that narrowed its scopes cannot call what it gave up.

A job never runs on no envelope because one could not be minted or read: its start is refused, and its calls wait while the edge cannot read it.

Constraints pass word for word through delegations, colleague questions, Ask's hand-overs and delegations, flow tools and a flow's agent steps

Identity for outside services

Each tenant has its own OIDC issuer for its agents on the edge. A cloud, a service or a secrets manager that trusts the issuer accepts a tool call's identity token instead of a key you would otherwise store, and checks it the way it checks any OIDC token: through the issuer's discovery document and its key set.

The issuer is https://<edge>/oidc/<tenant>, where <edge> is the edge's public address (--public-edge-url) or, without one, the edge API's advertised address. A cluster with several edges sets the public address to one name they all answer for, so they all issue as one issuer. oz0 tenant oidc show <tenant> prints it.
Discovery and keys: <issuer>/.well-known/openid-configuration and <issuer>/jwks.json, public on every edge, limited per client address. A cluster whose edges the internet cannot reach publishes them elsewhere.
Signing: ES256. Every edge derives the same keys from the cluster's secrets key (the master key in all-in-one mode) and the tenant's key epoch, so nothing is stored and no edge has to ask another.

What a token holds

Claim	From
`iss`	The tenant's issuer
`sub`	For a workload token, the agent: `oz0:agent:<tenant>:<agent>:<install generation>`. It never names a version, so a trust policy written against it survives upgrades, and it changes when the plugin is removed and installed again, so a reinstalled agent with a reused name does not inherit the old one's trust. For a delegated token, the person the job runs for (`oz0:user:<tenant>:<account>`) or a routine's team (`oz0:team:<tenant>:<team>`)
`act.sub`	In a delegated token, the agent that acts for that person
`aud`	One service or one token-exchange endpoint: the connection's audience
`iat`, `nbf`, `exp`	`exp` at most five minutes after `iat`, and never after the job's authority or the call's binding ends
`jti`	Unique to each token, as RFC 7519 asks, so a service that refuses a replayed `jti` accepts each token once, even two of one call
`oz0_call`	The call binding's digest: the same in every token of one call, and named in the audit trail too
`oz0_agent_version`, `oz0_job`, `oz0_plugin`, `oz0_node`, `oz0_envelope`	The agent's version, the job, its plugin, the node the call runs on, and the job's envelope hash

What a token never holds: the job's scopes, budgets, labels, taint, autonomy level, or who granted a level. They are the platform's own state, and enforcing them stays the platform's job.

Minted only for a call the edge handed out

A tool gets an identity token through a connection of kind identity (or on_behalf_of, below) that covers the function it calls. The node's runtime asks the edge for it with the call's binding, as for any connection token. The edge mints one only when:

the binding's signature is an edge's, it names the asking node and its certificate, and it has not expired: the call is one the edge handed this node, so another node gets nothing for it;
the connection is the job's agent's own plugin's: a tool of another plugin that the agent was granted gets no token that names the agent, or the person it acts for;
the job has not lost its authority to a kill switch, a revoked grant or a removed plugin (a parked agent's request waits);
the call's job has an authority envelope, from which every claim is taken. Nothing in the node's request becomes a claim.

The edge checks the binding, not whether the call is still running. A node that held a call's binding can ask for fresh tokens with it after the call returned, until the binding expires: at most the tool's time limit plus a minute (six minutes with the default limit of five). Each of those tokens still names that call, that node and one audience, and lives five minutes at most. A kill switch, a revoked grant or a removed plugin stops them at once.

An edge that has just started, and has not yet read the tenants' key epochs, mints nothing and answers its discovery document and key set with 503 until it has: it never signs or publishes keys from an epoch it has not read.

Each call gets its own token, which reaches the tool as connection tokens do: sealed to the node when the connection is bound to hosts, else in the call's metadata. It never enters a job's history, a log or a trace. The audit log records token.issued with the profile, the audience, the agent and the job, never the token.

Workload or delegated

A connection says which profile its tokens have:

workload for services that authorize the agent itself. Clouds ignore an actor claim, so their federation always uses workload tokens.
delegated for services that authorize the person and want to know which agent acted. A job started by an API key, an operator, a webhook or an event has no person to act for and gets none; a routine's job acts for its team.

A delegated token carries a person's identifier to whoever receives it. Whether a given service may receive it is a question for your organisation and its counsel, so by default no delegated token leaves the cluster: one whose audience, or token endpoint, is not on the cluster's own address is refused. A tenant admin may allow it with oz0 tenant oidc delegated-off-cluster <tenant> on, a governance change that takes a reason and, with four eyes on, another admin's approval. The recipient map lists every audience the tenant's agents receive tokens for, and says when a token names a person.

On behalf of a person

A connection of kind on_behalf_of reaches a service that runs its own token endpoint: the edge mints a delegated token for the call and exchanges it there (RFC 8693, with the agent's workload token as the actor) for the service's own token, which the call gets as its token. The exchange is made per call, from the edge, and only where delegated tokens may go.

Rotation

The key set holds three keys: the previous, the current and the next. oz0 tenant oidc rotate <tenant> makes the next key current, so it was published before it signs, while a token signed a moment ago still verifies with what is now the previous key. A rotation is refused within two hours of the last one, twice as long as verifiers may cache the key set.

--emergency skips a key, so the current one, which may have leaked, leaves the key set at once; verifiers that cached it trust it until their cache ends. Replacing the cluster's secrets key changes every tenant's keys at once, as an emergency rotation does.

Clouds without stored keys

AWS, Google Cloud and Entra accept the issuer too. For them the edge does the exchange itself: it mints the calling agent's workload token for the cloud's token service, exchanges it for a credential that lives an hour, and passes on only that credential, sealed to the node of the tool call, or uses it itself for a model call. Clouds never receive a delegated token, so never a person's identifier. Setting up the trust on each cloud, the presets and SigV4 signing in the egress proxy: Cloud federation.

What this page does not claim

The envelope, the bindings and the audit trail record what the platform did and on whose authority. Whether that makes a particular person accountable for a particular action, or satisfies a law, a standard or a contract, is for your policies and your counsel to judge.