Delegate a token to a sub-agent
Monotonically narrower delegation, and what the chain records.
Written By Dustin
Last updated 24 minutes ago
An agent holding a token issued with --can-delegate can mint a sub-token for another agent.
tovio agent new orchestrator --model <id> --task <text> --can-delegateThe flag grants two things together, and both are required: the delegation capability itself and the sub-token:issue operation. Through MCP or the SDK the agent then calls issue_sub_token. There is no tovio agent delegate command — delegation is something the holder does, not something you do on its behalf.
Monotonically narrower, on every dimension
A sub-token must be provably contained in its parent: paths a subset, lanes a subset, operations a subset, denied operations a superset, clearance only ever dropped, each capability flag only ever dropped, and expiry no later than the parent's. Anything the engine cannot prove contained is conservatively rejected with TVO-TOKEN-005. Delegation shrinks authority at every step; it never widens it.
Delegation rights are not inherited
A sub-token can only delegate further if it was explicitly issued with delegation on. The tool's default is off, so the right is re-granted at each hop rather than propagating quietly down a chain.
The chain is recorded and re-verified
A sub-token persists its parent link. When a delegate opens a session — presenting the leaf's id, its raw bytes, or the hex string issue_sub_token handed it — the engine reconstructs the whole ancestor chain from those links and verifies it end to end: the root pinned to a human repository identity, each agent hop resolved from the signed registration registry, every link unexpired, unrevoked and monotonically narrower. Any break refuses the session.
That revalidation then repeats on every tool call, not only at connect. A commit made by a delegated agent carries the full chain, root to leaf, so you can see which token authorized which, back to the one you issued.
Revocation cascades
tovio agent revoke <token-id>Revoking a token invalidates every live descendant on its next call. You do not have to hunt for what it delegated.
Two honest limits
- A sub-token today is scoped over the same agent identity as its parent. A distinct DID per delegated leaf is the design target, not the current behaviour — so read the chain, not the agent name, to tell two delegates apart.
- An ephemeral delegated leaf whose ancestors were never persisted cannot have its chain rebuilt, so it fails closed on reconnect. That is the safe direction, but it means a delegate needs its chain to have been written down, not just held in memory.