Overview
Grantex supports multi-agent pipelines where a root agent spawns sub-agents with narrower scopes. Sub-agent tokens carry a full delegation chain that any service can inspect.How It Works
A root agent that holds a grant for['calendar:read', 'calendar:write', 'email:send'] can delegate a subset of those scopes to a sub-agent:
Delegation Claims
The delegated token includes additional JWT claims that trace the delegation chain:| Claim | Description |
|---|---|
parentAgt | DID of the parent agent that created this delegation |
parentGrnt | Grant ID of the parent grant |
delegationDepth | Number of hops from the root grant (root = 0, first child = 1) |
Protocol Constraints
The Grantex protocol enforces three constraints on delegation:1. Scope subset
Sub-agent scopes must be a strict subset of the parent’s scopes. Scope escalation is rejected with a400 error.
2. Expiry cap
Sub-agent token expiry ismin(parent expiry, requested expiry). Sub-agents can never outlive their parent grant.
3. Cascade revocation
Revoking a root grant cascades to all descendant grants atomically. There is no window during which a child grant remains valid after its parent has been revoked. This is implemented as a single recursive CTE in the database.Depth Limit
The maximum delegation depth is 10 hops, enforced at both the application level and the database level (via aCHECK constraint). This prevents unbounded delegation chains.
Inspecting Delegation Chains
When verifying a delegated token offline, theVerifiedGrant object includes the delegation metadata: