Delegated authority in multi-agent systems.

In a multi-agent system, a parent’s instruction to a child is a security-relevant handoff. The child needs its own identifiable principal and a grant derived from a verifiable origin. The grant should state purpose, action, target, constraints, expiry and whether further delegation is allowed. Its effective authority must be a subset of the parent, and an operator should be able to trace the final actor back to the accountable source.

Monotonic narrowing is the central invariant. A child may be asked to summarize invoices without gaining the parent’s payment authority. The child cannot widen the target set, extend expiry or increase the delegation depth. A textual plan is not an authority artifact, and an agent cannot create a valid grant by describing what it believes it may do.

When a parent agent assigns work, the handoff should say more than “complete this task.” It should name the child principal, authorized operations, target resources, purpose, duration and whether further delegation is allowed. The child grant points to the parent grant so its origin is traceable.

The central invariant is monotonic narrowing. The child cannot gain a tool action, target, value ceiling or delegation right absent from the parent. Adding a child agent should not create additional standing privilege.

• Parent grant reference
• Child principal
• Permitted operation and target
• Purpose and expiry
• Delegation right and revocation state

A parent may delegate the same class of work to several children. If the parent has an aggregate ceiling, the design must prevent each child from independently consuming the full amount. Concurrency and retries matter, especially for payments or infrastructure changes.

Cancelling the parent task should invalidate child authority. An agent resuming after a pause should reevaluate the chain, not assume its old token still conveys the same grant.

A child’s denied action should identify the violated boundary: absent parent authority, scope mismatch, expired grant, revoked origin or forbidden sub-delegation. An opaque “forbidden” response encourages overprivileged workarounds.

A delegated-authority design should test its invariants before it is connected to tools. Can a child outlive its parent? Can it target a resource the parent could not? Can several children exceed a shared limit? Can a child create another child when its own grant forbids sub-delegation? If any answer is yes without explicit authorization, the graph is expanding authority rather than narrowing it.

These checks become especially important when an orchestrator creates agents dynamically. The number of agents may change with the task, but the origin and total authority budget should remain explainable.

A child grant needs an immutable link to its parent and an explicit subset of the parent’s operations, targets and limits. The parent may be allowed to investigate a set of incidents but delegate only log collection for one incident. A child that can create another child needs that right stated separately. A planner’s instruction to delegate does not create the security authority to do so.

Validate the subset when the grant is issued and again when it is used. The latter check catches parent revocation, expiry and policy changes after an agent has queued work. A system that validates only at creation can leave children active after the operator cancels the original task.

Limits shared by several children require a common accounting boundary. If a parent may change five network routes, five children cannot each receive an independent five-change allowance. Reservation or atomic consumption of a shared budget prevents parallel workers from exceeding the parent scope. Retries must identify the same intended operation so a timeout does not consume or execute twice.

Record the first authority origin and the final acting child. The operator needs both to understand the action. ProofGrid’s authority graph makes these relationships reviewable while the public example remains an architecture abstraction rather than an internal schema.

A child may run in another orchestrator, cloud account or MCP-connected service. The receiver must authenticate the child and preserve a verifiable parent reference, task, scope, purpose, expiry and remaining delegation depth. Passing the parent workload token gives the child excessive reach; passing an unsigned JSON description preserves labels without preserving authority integrity.

Some actions require two independent authority paths, such as a business owner approving the task and a platform owner approving the production window. Effective authority is their intersection. The decision should name both required paths and deny if either expires or is revoked. It must not select whichever path grants the larger set of actions.

Suppose child A reserves $20,000 from a $25,000 workflow budget and the payment provider times out. Child B then asks for $8,000. Releasing A’s reservation immediately could permit $28,000 if A actually committed; retaining it forever can stall the workflow. The runtime needs an explicit reservation state, an idempotent executor operation and reconciliation against the provider before settling or releasing the amount.

A parent cancellation should prevent new child effects, but it cannot undo an already committed payment. Record the revocation time, final action-time decision, executor reference and observed outcome. This separates revocation propagation failure from an effect that legitimately crossed the commit boundary before cancellation.

At issuance, validate the parent grant, issuing principal, child identity, subset relationship and remaining depth. At use, validate the entire ancestry again because a parent may have been revoked, a task cancelled, a policy changed or the child expired while waiting. A downstream executor should not rely on a child-supplied parent ID without trusted lookup or verifiable binding.

When work crosses runtimes, queues or MCP servers, the receiver must preserve the same origin and limits. Passing only a shared workload credential loses the logical child and parent task. Passing a self-asserted JSON object may preserve labels but not integrity. The integration needs an authenticated handoff and an enforceable check before the protected effect.

A parent has a total transaction ceiling of $25,000. It creates five children to process separate invoices. Giving each an independent $25,000 grant would turn one approval into $125,000 of possible activity. The design must distinguish a per-action limit from a shared workflow total and keep the latter common to all children.

One conceptual model keeps a shared remaining balance and consumes it atomically. Another reserves an amount for each pending operation and releases unused reservations. A third partitions the original ceiling into disjoint child budgets. Each has different concurrency, retry and failure behavior. ProofGrid enforces the shared constraint while this public architecture leaves the private mechanism undisclosed. A deployment review should identify the owner of the budget and the invariant it must maintain.

Some actions need more than one origin. A deployment agent may need business-owner approval for the task and platform-owner approval for the production window. Effective authority is the intersection of both valid paths. One broad grant cannot substitute for a missing required approval, and revocation on either path should stop the action. Graph convergence must be explicit so a decision can explain which approvals were present.

Different constraints can also intersect: a parent permits changes to ten hosts, a child grant names two, and a maintenance policy names one during the current window. The effective target is one host. The decision should not pick whichever grant gives the agent the largest set.

A task cancellation should invalidate child grants at their next consequential check even if their workload tokens remain valid. Expiration limits unattended authority but does not replace revocation. For high-impact work, short-lived action approvals should bind child principal, tool, target and normalized parameters; replay protection prevents reuse for another effect. Retries after a timeout must be reconciled against the shared budget and executor state.

The evidence chain should identify the first accountable origin, each delegation, final child actor, decision, execution receipt and observed outcome. If the executor times out, the outcome is unknown until confirmed. This permits investigation of both unauthorized delegation and ordinary execution failure without collapsing them into one audit event.