Add an async user-consent broker for always-on agents

Problem Statement

Always-on agents may need explicit user authorization when the user is not actively in session: new resource consent, step-up authentication, or sensitive action approval. Today the practical choices are fail the task, require an active session, or use an over-privileged service account. None preserve user attribution and isolation simultaneously.

Proposed Design

1. Expose an async consent request API with principal, resource, scope/action, reason, expiry, and correlation ID.
2. Initiate CIBA or equivalent provider-specific approval with the identity provider.
3. Return a pending handle to the agent; never return token material.
4. Allow the agent to suspend and resume when the handle becomes approved, denied, expired, or failed.
5. Store approved tokens under the same gateway-side custody, attenuation, and audit rules as other broker-issued credentials.

Acceptance criteria:

• An agent can request consent, receive a pending handle, suspend, and resume after approval without seeing the resulting token.
• Approved, denied, expired, and failed consent states are explicit and machine-readable.
• Consent request, user approval, token acquisition, and downstream token use share correlation IDs.
• The design composes with gateway/operator approval rather than replacing it.

Alternatives Considered

• Fail whenever consent is missing: safest, but blocks useful autonomous workflows.
• Use long-lived service-account access: operationally easy, but undermines user attribution and least privilege.
• Require active interactive sessions for all user-scoped work: reduces autonomy and creates brittle UX.

Agent Investigation

• OpenShell has gateway-mediated policy decisions and operator-style approval concepts, but no documented user-scoped async consent broker for IdP-issued tokens.
• Providers v2 refresh strategies (oauth2_client_credentials, oauth2_refresh_token, google_service_account_jwt, static, external) are all machine-credential or pre-acquired-token shaped; none initiate user consent.
• CIBA is one relevant standard, but the feature should be an async consent abstraction that can use CIBA or provider-specific step-up mechanisms where supported.

References:

• OIDC CIBA core spec: https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0.html
• OpenShell Providers v2 (refresh strategies): https://docs.nvidia.com/openshell/sandboxes/providers-v2

Checklist

• I've reviewed existing issues and the architecture docs
• This is a design proposal, not a "please build this" request

Start with the existing architecture documentation, OpenShell Providers v2 refresh strategies, and the referenced OIDC CIBA core specification. Define an async consent abstraction and document how pending, approved, denied, expired, and failed states, correlation IDs, token custody, and gateway/operator approval satisfy the acceptance criteria.