User Story
An operator lets a parent agent spawn a child with narrower authority. If authority above that child is later revoked, narrowed, or can no longer be confirmed, the child should not keep acting under the old authority.
Problem Statement
#2025 defines containment when a child is created:
child_policy <= parent_delegable_view <= parent_boundary <= human_admin_maximum_policy
#2109 revalidates pending authority changes against live policy before they are applied.
I could not find a rule for a child that is already running when an authority boundary above it changes. A containment proof that was valid at spawn can become stale while the child keeps running.
Impact / Why This Matters
Revoking or narrowing an ancestor should reach authority that depends on it, not only future child creation.
Without a later recheck, a running descendant may rely on authority derived from a boundary that no longer allows it. With transitive delegation, the same problem can repeat at every level.
Proposed Design
For a later operation that requires authorization, evaluate the descendant against the current authority state it depends on, not only the state captured when it was spawned.
- Ancestor revoked: the descendant cannot authorize a new effect through the old chain.
- Ancestor narrowed: the descendant cannot exercise authority outside the new boundary.
- Authority granted again later: this creates new authority. It does not silently reactivate the old descendant chain.
- Ancestor state unavailable or stale: do not treat the previous state as active. Whether OpenShell rejects or waits can remain a policy choice, but the result should distinguish unresolved state from an actual revocation.
- Earlier work: a later authority change does not rewrite an earlier decision or undo a completed effect.
How to stop, resume, cancel, or compensate work already past its last authorization boundary is out of scope here.
Acceptance Criteria
Alternatives Considered
Terminate every descendant when an ancestor changes. Works for some revocations, but cannot express narrowing and turns an authority change into sandbox lifecycle management.
Check containment only when the child is created. Stale authority can remain usable for as long as the child keeps running.
Handle it only in an external interceptor. A creation-time interceptor can enforce spawn containment, but that alone does not revalidate an already-running child at a later authorization boundary.
Agent Investigation
Reviewed #2025, #2109 / PR #2168, and #1636. I found spawn-time delegation containment and live revalidation for pending changes, but not a rule for descendants that are already running when ancestor authority changes.
I've been working through the same lifecycle cases in draft-pidlisnyi-aps-04. The relevant rules are L1 (ancestor revocation), L3 (reauthorization), L6 (an earlier approval is not current authority), L7 (unknown revocation state), and L11 (no silent authority resurrection):
https://datatracker.ietf.org/doc/draft-pidlisnyi-aps/
Runnable vectors for ancestor revocation:
https://github.com/Agent-Authority-Conformance/aps-conformance-suite/tree/main/fixtures/ancestor-revocation-chain
I can contribute the negative tests if this direction is accepted.
User Story
An operator lets a parent agent spawn a child with narrower authority. If authority above that child is later revoked, narrowed, or can no longer be confirmed, the child should not keep acting under the old authority.
Problem Statement
#2025 defines containment when a child is created:
child_policy <= parent_delegable_view <= parent_boundary <= human_admin_maximum_policy#2109 revalidates pending authority changes against live policy before they are applied.
I could not find a rule for a child that is already running when an authority boundary above it changes. A containment proof that was valid at spawn can become stale while the child keeps running.
Impact / Why This Matters
Revoking or narrowing an ancestor should reach authority that depends on it, not only future child creation.
Without a later recheck, a running descendant may rely on authority derived from a boundary that no longer allows it. With transitive delegation, the same problem can repeat at every level.
Proposed Design
For a later operation that requires authorization, evaluate the descendant against the current authority state it depends on, not only the state captured when it was spawned.
How to stop, resume, cancel, or compensate work already past its last authorization boundary is out of scope here.
Acceptance Criteria
Alternatives Considered
Terminate every descendant when an ancestor changes. Works for some revocations, but cannot express narrowing and turns an authority change into sandbox lifecycle management.
Check containment only when the child is created. Stale authority can remain usable for as long as the child keeps running.
Handle it only in an external interceptor. A creation-time interceptor can enforce spawn containment, but that alone does not revalidate an already-running child at a later authorization boundary.
Agent Investigation
Reviewed #2025, #2109 / PR #2168, and #1636. I found spawn-time delegation containment and live revalidation for pending changes, but not a rule for descendants that are already running when ancestor authority changes.
I've been working through the same lifecycle cases in
draft-pidlisnyi-aps-04. The relevant rules are L1 (ancestor revocation), L3 (reauthorization), L6 (an earlier approval is not current authority), L7 (unknown revocation state), and L11 (no silent authority resurrection):https://datatracker.ietf.org/doc/draft-pidlisnyi-aps/
Runnable vectors for ancestor revocation:
https://github.com/Agent-Authority-Conformance/aps-conformance-suite/tree/main/fixtures/ancestor-revocation-chain
I can contribute the negative tests if this direction is accepted.