feat(policy): native expiration / single-use bounds for approved policy grants (expires_at, max_uses) #2881

Activity

1. github-actions

   added

   state:triage-neededOpened without agent diagnostics and needs triageOpened without agent diagnostics and needs triage

   on Aug 21, 2026
2. elezar commented on Aug 25, 2026

   

   elezar

   on Aug 25, 2026

   Member

   More actions

   📋 triage-agent

   Triage Assessment

   Classification: needs-investigation

   Summary

   The requested capability is credible: OpenShell currently relies on an external advisor to apply a policy change and later revoke it, so the time or use bound is not enforced at the OpenShell boundary. A server-enforced bound would provide a stronger just-in-time authorization guarantee.

   Investigation

   Current approved draft chunks merge directly into the active sandbox policy; they do not retain a native expiry, use counter, or independently reversible grant record. OpenShell also has no policy-level TTL or max_uses field. #2591 is related server-managed expiration work, but concerns deleting expired sandboxes rather than reverting a temporary policy grant. No duplicate or implementation PR was identified.

   A focused design investigation is needed before implementation can be scoped safely. It must define grant identity and provenance after a draft chunk merges with later policy changes; what one “use” means for connections, requests, retries, redirects, streams, and concurrent requests; atomic consumption and recovery across supervisor restarts; and expiry/revocation reconciliation, policy reload behavior, and audit/status events.

   To ground that investigation, please add one or two concrete grant lifecycles from your integration:

   1. The exact action being authorized and protocol boundary, such as one HTTP request to a named endpoint versus one TCP connection.
   2. Who creates, approves, consumes, and observes the grant.
   3. Expected behavior for retries, redirects, concurrent requests, and a request that begins before expiry but completes after it.
   4. Whether the bound must survive gateway/supervisor restart and whether it is sandbox-, workspace-, or identity-scoped.
   5. Whether expiration must restore a prior policy state exactly, or simply remove the approved addition.

   This will help distinguish an expiring policy overlay from a one-shot request-authorization primitive.

   Impact Signals

   • Affected users/scope: Operators integrating third-party or just-in-time policy advisors.
   • Regression: Not applicable; this is missing capability.
   • Workaround: Apply then revoke from the external decision layer; functional, but it cannot guarantee an OpenShell-enforced expiry or one-use bound.
   • Evidence quality: Medium-high; the report defines a concrete workflow and current source confirms the missing primitive.

   Human Decision Required

   Decide whether OpenShell should invest in a focused design spike for server-enforced, bounded policy grants. If yes, apply state:accepted, associate the issue with a roadmap item, or do both.
3. elezar

   added

   state:validated

   area:policyPolicy engine and policy lifecycle workPolicy engine and policy lifecycle work

   area:gatewayGateway server and control-plane workGateway server and control-plane work

   area:sandboxSandbox runtime and isolation workSandbox runtime and isolation work

   and removed

   state:triage-neededOpened without agent diagnostics and needs triageOpened without agent diagnostics and needs triage

   on Aug 25, 2026
4. gomission commented on Sep 30, 2026

   

   gomission

   on Sep 30, 2026

   More actions

   One concrete lifecycle from Mission's Trust Graduation work that may help scope the design: one bounded, non-streaming HTTP POST, with one permitted admission and a ten-minute grant expiry. This is a proposed OpenShell use case, not an existing integration or a tested OpenShell guarantee.

   The agent requests the grant; a human approves through an external decision service; OpenShell owns the final admission/use check; the agent and operator can read the persisted decision/status after restarting. Pending approval does not require keeping a request or stream open.

   For this example, bind the grant to the sandbox identity and an exact request: method, origin, path/query, fixed content type and approved body bytes. Exact-body binding is an additional constraint for this example, beyond the issue's expiry/use bounds. Keep grant identity, request identity and payload identity separate: a retry of the same request can read its status, but must not authorize another dispatch; reusing that identity with different bytes is a conflict.

   I would define a use as a durable atomic claim before forwarding, followed by at most one dispatch attempt. Expiry/current revocation state are checked at that admission boundary. Consumption survives gateway/supervisor restarts, and a timeout or HTTP error does not replenish it. This deliberately trades availability for a clear bound: a crash after the claim but before forwarding can leave an unresolved execution. A consumed grant proves admission, not that the backend effect happened.

   The acceptance cases I would start with, under a test policy with no other standing permission for the endpoint:

   Case	Expected result
   Two concurrent requests using the same one-use grant	One claim/dispatch at most; the other receives an explicit exhausted outcome.
   Changed request bytes/target, or reused request ID with different bytes	No dispatch under this grant.
   Restart after claim, before forwarding	Existing claim stays consumed; execution remains unresolved, with no automatic resend or reset.
   Backend commits, then the response is lost	The caller can reconcile through exact-request, read-only backend evidence; absent that capability/evidence, outcome stays unknown.
   Expired/revoked before admission; admitted before expiry but completes afterward	Deny the former; allow recording the latter's outcome. Expiry and manual revocation remain distinguishable.
   Redirect, or retry after an HTTP error	Another forwarding attempt requires fresh authority; the consumed grant does not authorize it.
   Grant expires after an unrelated policy edit	Remove only its temporary contribution; do not restore an old policy snapshot and undo later edits.

   The backend lookup belongs to the caller/provider contract, not a promise that OpenShell can independently verify arbitrary external effects. Likewise, the existing admission/replay work in #3321, #3323 and #3324 is relevant prior work, rather than a reason to add a parallel receipt subsystem.

   Would this be useful as the one-shot request-authorization case, separately from a general expiring policy overlay? If that boundary fits, we can contribute deterministic fake-clock/concurrency/crash cases against the agreed enforcement path. No OpenShell fixture has been run for this proposal yet.
5. github-actions commented on Oct 15, 2026

   

   github-actionsBot

   on Oct 15, 2026 – with GitHub Actions

   More actions

   This issue has had no activity for 14 days and is now marked stale. It may be closed in 14 days if there is no further activity. Comment or remove the state:stale label to keep it open.
6. github-actions

   added

   state:staleInactive item at risk of automatic closure.Inactive item at risk of automatic closure.

   on Oct 15, 2026