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

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