Task-Scoped Authority

Compare a standing credential with task grants

Suppose the tester held one standing credential for the whole job: a long-lived grant over /workspace, a shell, and the network. The kernel checks every request, at every minute, against all of it. When the tester reads the fixture and follows the comment, the read of .env and the upload through curl both fall inside that scope.

Task grants divide the same job by time and by scope. In the figure the tester takes three subtasks in turn, the tests among them, and receives one grant per subtask, each covering one tool on one path for a signed window. Every grant belongs to one delegation family with a shared invocation count. Drag the marker, or focus it and use the arrow keys, to see what a request at each minute can reach.

The injected requests land inside the standing credential and outside every live grant, so the kernel refuses them at the scope check, before any guard runs. Between subtasks the tester holds nothing, and a request at minute 36 reaches no tool. The hostile text stays in the model’s context after its subtask ends, and the .env request it produces at minute 44 meets a grant that covers search alone.

Issue the grant when the task starts

Issuance is a call the reviewer’s host makes as each subtask begins. In an embedded kernel, CapabilityAuthority::issue_capability takes the subject’s public key, a ChioScope, and a lifetime in seconds, and returns a signed capability token. A host that uses the trust control plane sends the same three values, subjectPublicKey, scope, and ttlSeconds, to POST /v1/capabilities/issue.

The operator bounds what any subtask can receive. The service’s issuance policy sets ceilings on lifetime, invocation count, and operations, and refuses a request beyond any of them. Within those ceilings the reviewer chooses what its subtask needs. Keep the issuer’s key and the issuance credential with the reviewer’s host: a tester that holds neither cannot mint authority for itself. Issuance governance runs the policy ceiling and its refusals.

Size the grant to the task

A task grant narrows several dimensions at once. The issuer in the Authority example derives each worker’s scope from its parent: it keeps only the Invoke operation, adds the worker’s directory as a PathPrefix constraint, sets max_invocations to two, and caps expiry at thirty minutes or the parent’s expiry, whichever comes first.

let mut scope = parent.scope.clone();
scope.grants[0].operations = vec![Operation::Invoke];
scope.grants[0]
    .constraints
    .push(Constraint::PathPrefix(prefix.into()));
scope.grants[0].max_invocations = Some(2);
let expires_at = now.saturating_add(1800).min(parent.expires_at);

Applied to the reviewer’s read_file grant over /workspace, with tests/ as the tester’s directory, the snippet gives the requests from pull request #421 these decisions:

The reviewer’s own grant covers /workspace/.env, because it reads the whole workspace. Under that grant the read passes the scope check and the forbidden-path guard refuses it, as Guards shows. A tester that never needed the file never held it. Least privilege runs this issuer against a real repository, including a sibling directory the prefix excludes.

Delegation can only narrow

The reviewer holds a parent grant with the Delegate operation, and each worker it assigns receives a child of it. The parent’s subject signs a delegation link that records each narrowing step: Attenuation::RemoveOperation, AddConstraint, ReduceBudget, and ShortenExpiry. The child token carries the complete chain and an attenuation proof that commits to the parent’s and the child’s scope hashes.

The kernel checks that relationship each time a call presents the child. A child cannot hold a scope outside its parent’s, outlive its parent, drop its parent’s proof-of-possession requirement, or take a larger budget share. The tester’s grant above has no Delegate operation, so text that tells the tester to hand a sub-agent wider authority has no operation to call. Delegation boundaries lists each rule and the refusal it produces.

Count the family’s calls together

A compromised worker can also do damage in volume: retry a permitted read until something leaks, or split a bulk read across sub-agents so that each stays under its own limit. The family’s accounting bounds both.

budget_share_bps divides a parent’s share among its children in basis points. The budget registry refuses a new child whose share, added to its admitted siblings’ shares, would exceed the parent’s, so delegating cannot multiply a share. In the Authority example, each of the two workers holds 5,000 bps. Capabilities works through the arithmetic.

An aggregate invocation budget counts calls across every grant in a delegation family. The root grant carries it with the DelegationFamily scope, every descendant carries the same signed root binding, and the kernel captures each admitted call against one family quota. In the Authority example, the parent allows six reads and each worker two, while the family allows three in total.

pub struct AggregateInvocationBudget {
    pub scope: AggregateInvocationScope,
    pub max_invocations: u32,
    #[serde(default, skip_serializing_if = "Option::is_none")]
    pub root_binding: Option<AggregateBudgetRootBinding>,
}

Creating workers creates no new allowance. A descendant that delegates further passes the same root binding to its own children, so their calls draw on the same total. Invocation limits races two workers for the family’s last use and shows that exactly one wins.

End authority with the task

Most task grants end on their own. The signed expires_at bounds the token, a delegated child cannot outlive its parent, and the kernel rejects an expired token at the capability check. When a subtask finishes early, the reviewer can revoke its grant instead of waiting.

Revocation also ends a whole family. Revoking a grant records its ID in the revocation store, and at admission the kernel checks the presented token and every ancestor in its delegation chain. Revoking the reviewer’s root therefore refuses every worker’s next call with DelegationChainRevoked, while revoking one worker’s grant closes only that branch. Receipts for calls admitted earlier remain. Autonomy with Authority draws the revoked branch.

During an incident, an issuance freeze stops new grants for an affected lineage. A response plan that suspends a lineage’s capability set must begin with FreezeIssuance, so the lineage cannot receive a successor while the response acts on its older grants. The embedded kernel’s issue_capability_with_security_context checks the freeze before it signs. Detect, Contain, Recover places the freeze in a full response, and Issuance governance covers its admission check.

What a grant leaves to other checks

A grant decides whether a call falls within the task’s authority. It cannot decide whether an in-scope call serves the task. Reading deploy/settings.yaml is in scope for the reviewer. If its grant also covers posting the review, a public comment that quotes the file’s database URL passes every scope check.

Other mechanisms decide those cases. Guards check each call’s arguments against policy. Session rules constrain order and volume, such as a reproduced failure before an edit; Rules Across a Session covers them. Information flow carries the internal read into the session’s retained state, and the kernel refuses egress to a public destination without clearance for it. Information Flow Across Calls follows that case.

Follow the grant further