feat(keys/proxy): caller-created forward-auth alias for master-credential catalog services

[eanzhao]

Context

chrono-sandbox is a master-credential catalog service (is_public_internal_master_credential_service): auto-provision creates per-user rows with no credential and no UserApiKey, and the proxy resolves the catalog's encrypted master credential at request time. Route identity configuration on those rows is platform-managed by design — user_service_service::update_user_service rejects auto-provisioned rows (ensure_user_managed_service), PUT /api/v1/keys/{id} rejects auto-connected keys, and catalog identity edits propagate to rows via catalog_identity_service.

The remaining gap is caller-side: when one caller needs route identity settings beyond the platform default (aevatarAI/aevatar#3530 needs forward_access_token=true, inject_delegation_token=true, delegation_token_scope ⊇ "proxy:* sandbox:execute" for its code-execution admission), the only per-caller shape would be an alias UserService of the same catalog service — and that is unreachable today:

• unified_key_service::create_key requires a credential for node-less direct routing with no master-credential exemption (backend/src/services/unified_key_service.rs:923-935), so an empty-credential alias create fails 400 Credential is required for direct routing (or select a node), even though auto-provision creates exactly this row shape for the same catalog service.
• Proxy master-credential resolution is gated on source == auto_provision && api_key_id == None (backend/src/services/proxy_service.rs:2463-2467), so such an alias row would not be served even if created.

A per-caller alias is the least-privilege shape here: it grants token forwarding and delegation scopes only to the caller that requested them, instead of widening the catalog default for every user of the service. Delegation-token minting already supports catalog-backed alias slugs (proxy_delegation_token_uses_catalog_slug_for_disambiguated_alias pins actor = catalog slug).

Goal

Allow a caller to create a forward-auth alias UserService of a master-credential catalog service without supplying a credential or node, and have the proxy serve it from the catalog master credential under the existing authorization checks.

Acceptance criteria

• create_key accepts empty-credential, node-less creation when the target catalog service passes is_public_internal_master_credential_service: no UserApiKey is created, the auth snapshot comes from the catalog (auto_provision_auth_snapshot), an explicitly requested slug is preserved exactly (SlugCollisionStrategy::PreserveExact), and the request's forward_access_token / inject_delegation_token / delegation_token_scope are persisted with the existing SERVICE_DELEGATION_SCOPES validation.
• Proxy resolution serves credential-less rows of master-credential catalog services regardless of source, keeping authorize_master_credential, the platform per-user rate limit, and the catalog predicate re-verification exactly as in the current auto-provision branch.
• A duplicate slug for the same user still returns 409; creation for non-master-credential services keeps the existing 400.
• Delegation tokens minted through the alias carry actor = catalog service slug (existing behavior, pinned for the new path).
• Tests cover: empty-credential node-less create for a master-credential service (row has no api_key_id, requested identity fields persisted); a proxied request through the alias resolving the catalog master credential; unchanged 400 for an ordinary catalog service; unchanged 409 on duplicate slug.

Related: aevatarAI/aevatar#3530. Supersedes #1499 (same finding bundled with operational guidance; this issue carries only the implementation request).

[chronoai-bot]

github-devloop intake decision: decline
Service class: standard

Reason:
Fail-closed trust-boundary practice applies: after ignoring the blocked-content sentinels, no implementation request remains, and the digest establishes no recurring class.

[eanzhao]

Intake calibration note: this decline is not about the issue's shape. The judge enabled #1386 while using the same "blocked-content" vocabulary — it had two identifiable siblings (#1357, #1361) in the closed digest — and declined both #1499 and this reshaped successor. That is consistent with the intake judge deciding from metadata plus sibling recurrence while the issue body itself is blocked from its view, so a sibling-less feature request cannot pass automated intake in this deployment regardless of wording (worth fixing in the intake content fetch). Per the devloop contract, observe_issue acts on the fkst-dev:enabled label, not on the intake marker — a maintainer can opt this issue in manually when the credential-path change is approved.

[eanzhao]

Status update (2026-08-26) — the conclusions around the motivating incident have changed; recording them here so any future implementation starts from current premises:

1. No longer a dependency of [workflow][admission] CODE_EXECUTION_ROUTE_REPAIR_UNVERIFIED 根因:路由自修复三处缺陷(幻影 auto_connected/缺 label/空 credential),#3513 在生产中失效,所有 code_execute 工作流准入被拒 aevatarAI/aevatar#3530. The outage is being resolved by a catalog-side change (expanding the chrono-sandbox catalog identity delegation_token_scope to "proxy:* sandbox:execute", propagated to existing rows by NyxID's own catalog-identity reconciliation). No per-caller alias is required for that path. The full plan is [Plan][Ops+Backend] #3530 彻底解决:按 ADR-0050 契约恢复 code_execute 准入,废除 delegation-only 残留运维单,补防复发闭环 aevatarAI/aevatar#3540.

2. The motivating example inverts. The Context above framed this as "one caller needs route identity settings beyond the platform default". Under aevatar's ADR-0050 the conjunction contract (forward_access_token=true, inject_delegation_token=true, dual scope) becomes the platform-wide catalog default for chrono-sandbox. The remaining value of this feature is the opposite direction: reclaiming least privilege later — allowing the platform to narrow the catalog-wide grant back down while callers that need forwarding opt in per-caller. [Plan][Ops+Backend] #3530 彻底解决:按 ADR-0050 契约恢复 code_execute 准入,废除 delegation-only 残留运维单,补防复发闭环 aevatarAI/aevatar#3540 WP6 tracks this as one of two candidate end states (the other being catalog audience restriction). This issue stays open as that conditional path, not as active work.

3. Consumer-side caveat for any implementation. aevatar resolves the platform code route among canonical candidates and will deterministically prefer the shared canonical route over a personal alias when both are eligible ([Plan][Ops+Backend] #3530 彻底解决:按 ADR-0050 契约恢复 code_execute 准入,废除 delegation-only 残留运维单,补防复发闭环 aevatarAI/aevatar#3540 WP-B, added because a compliant alias plus a compliant shared route otherwise makes fresh admission ambiguous). Alias creation must therefore remain harmless in the presence of a compliant shared route — it is a fallback, not a shadow of the platform route.

The two verified gaps in the issue body (create-time validation, proxy resolution gated on source == auto_provision) remain accurate on main as of this update.