feat: CLI mints scoped tokens for release; per-project scope on OCI push (ALIEN-139)

[ItamarZand88]

Summary

This PR has two halves that together let alien release work safely against a multi-tenant manager. On the CLI side, the user's OAuth token gets exchanged for a short-lived signed token scoped to one project on one manager before any manager call happens — so the manager never sees a credential type it can't validate. On the manager side, the image-push handler now checks that the project scope inside the token actually covers the project being pushed to, so a token issued for project A can't push images intended for project B. OSS standalone behavior is preserved: validators that don't set Subject.scopes leave it empty, and the new scope check is a no-op on empty scopes.

Step-by-step flow when you run alien release:

1. You ran alien login earlier, so the CLI has your OAuth access token saved.
2. The CLI asks the platform for a short-lived signed token scoped to one project on one manager (using the purpose: registry-push flow added in the companion platform PR).
3. The CLI sends that signed token to the manager's artifact-registry setup call.
4. The CLI sends the same signed token to the image push at /v2/.../blobs/uploads/.
5. The manager checks the project scope inside the token against the project being pushed to — rejects if the scope doesn't cover this project. ← the security check this PR adds
6. Push succeeds; the release is created.

This PR changes the OSS side of the release flow: the CLI now asks the platform for a project-scoped signed token instead of sending the raw OAuth token, and the manager's image-push handler now rejects any token whose scope doesn't cover the project being pushed to.

What was broken before

Three things, all surfaced when running alien release against a multi-tenant manager:

1. The CLI was sending the raw OAuth token to the manager. The manager rejected it because OAuth tokens aren't a credential type it can validate.
2. The manager's image-push handler authorized by role only — a token with the right role could push to any project, not just the project it was actually scoped to.
3. alien commands invoke errored before reaching the manager at all, because the command code tried to use a client that doesn't exist in platform mode.

Security review

This PR touches authorization on the image push, so answering the 5 standard questions.

1. What's new on the auth path

• Old: the push handler ran a role check. A token with the workspace-member role could push to any project in the workspace.
• New: if the token carries non-empty project scopes, at least one scope entry must cover the project being pushed to. Tokens with no scopes (the OSS standalone case) skip this check entirely, so single-tenant setups behave exactly as before.

2. How the scope check works

In crates/alien-manager/src/registry_proxy.rs:

1. The push handler runs the existing role check first (unchanged).
2. If the subject's scopes are non-empty, the new check runs: each scope entry is a workspaceId/projectId pair, and at least one entry must end in the target project's ID.
3. No scope covers the target → reject with 403.
4. Scopes are empty → skip the new check (OSS standalone behavior preserved).

The scope-check predicate is extracted as a pure function scopes_cover_project(scopes, project_id) so it's unit-testable on its own.

3. Token shape this PR cares about

The CLI's exchange path produces one token type used for image push:

What it's for	What it carries
Image push during alien release	scopes: ["workspaceId/projectId"], manager binding, purpose: registry-push

Token issuing and signature verification happen on the platform side and aren't changed by this PR.

4. Where the token is accepted

Endpoint	Accepts	Extra check this PR adds
/v1/artifact-registry/*	the new exchanged token	none (in this PR)
/v2/.../blobs/uploads/ (image push)	the new exchanged token	the scope must cover the target project's ID

5. What I explicitly checked

• Project-scope leak: a token scoped to project A cannot push images to project B. Covered by a test on scopes_cover_project.
• Substring confusion: a scope ending in /prj_abc does NOT accept a target of prj_abcd — the suffix match requires the leading /. Covered by a dedicated test.
• OSS standalone preserved: validators that don't set Subject.scopes leave it empty, and the new check is gated on !scopes.is_empty(). Verified by a test using an empty-scopes subject, plus a grep — all OSS validator literals initialize scopes: Vec::new().
• Cache-reuse safety: the CLI caches the exchanged token; the cache-reuse check (token_matches_target) validates the cached token's claims (manager ID, project ID, scope shape) before reuse. 7 tests cover match, manager mismatch, project mismatch, missing claim, malformed token, scopes claim of the wrong type.

Security follow-up landed on this branch (after re-review)

A follow-up review of the companion platform PR's security work needed the per-project scope predicate from a stable OSS-side location:

• 949bad8 feat(manager): promote per-project scope check to Subject::permits_project — moves the predicate (previously a private free function scopes_cover_project in registry_proxy.rs) onto Subject as a method, so other route handlers in downstream embedders can apply the same per-project invariant without duplicating the logic. Same semantics (empty scopes → true for OSS standalone; non-empty → at least one entry ends with /<project_id>; substring-confusion guard via the leading slash). The OCI push call site now reads subject.permits_project(project_id) instead of scopes_cover_project(&subject.scopes, project_id). Tests move with the function, plus one additional case (multi-scope-any-match).

Verification

• How I tested manually: Ran alien login against the local stack, ran alien init remote-worker-ts my-worker, applied the template fixes (the template still scaffolds with the old alien.Function API instead of alien.Worker, and the npm @alienplatform/core is stale — separate ticket below), ran alien link, then alien release --experimental — got two release IDs on two separate runs, the second from a fresh-rebuild scratch state with all local databases wiped. Both passed the new scope check and the artifact-registry + image-push path end-to-end.
• Unit tests: cargo test -p alien-manager → 108 passing (was 103; the +5 are for the extracted scopes_cover_project predicate). cargo test -p alien-cli --features platform --lib oauth_flow::tests → 7 tests for token_matches_target.
• Build: cargo build -p alien-cli --features platform → clean.
• What I couldn't test end-to-end: alien commands invoke against a deployed worker — the C1 fix in this PR unblocks the CLI side, but the full path 401s for a separate reason tracked as ALIEN-144.

Out of scope

• ALIEN-144 — alien commands invoke 401 in platform mode. The token this PR's CLI flow produces works for image push, but doesn't work on endpoints that forward the call back to the platform. Needs a different token shape or a server-side exchange. Independent design call.
• Subject.scopes: Vec<String> is loosely typed — the "workspaceId/projectId" format is only enforced by a doc comment. A typed permits_project_push(project_id) helper on Subject would replace the open-coded suffix-match at call sites.
• The remote-worker-ts template still scaffolds with the old alien.Function API and a stale @alienplatform/core npm dependency — anyone trying alien init followed by alien release will hit it. Separate template-update ticket.

Test plan for reviewer

• cargo test -p alien-manager passes locally (108 tests).
• cargo build -p alien-cli --features platform is clean.
• Spot-check the 5 new tests on scopes_cover_project and the 7 new tests on token_matches_target — they cover the security-critical branches.
• Confirm OSS standalone preserved: grep -rn 'Subject {' crates/alien-manager/src/providers/ should show scopes: Vec::new() on all subject literals.

[greptile-apps]

Greptile Summary

This PR adds two complementary pieces: the CLI now exchanges the user's OAuth token for a short-lived project-scoped JWT before calling the manager during alien release, and the manager's OCI push handler enforces that the presented token's scopes cover the target project (while preserving OSS standalone behavior for empty-scope tokens).

• Token minting & caching (auth.rs): get_or_mint_registry_push_token mints via the platform's POST /v1/managers/{id}/token, caches in the system keyring, and uses token_matches_target to validate cached tokens against the current (manager, project) target before reuse — 7 unit tests cover all mismatch and decode-failure cases.
• Scope enforcement (registry_proxy.rs): scopes_cover_project gates the OCI push path — empty scopes pass through (OSS), non-empty scopes require at least one entry ending with /{project_id} — 5 unit tests cover the substring-confusion and cross-project cases.
• Subject extension (subject.rs, all validators): adds scopes: Vec<String> to Subject; all OSS validators initialize it to Vec::new(), preserving backward compatibility.

Confidence Score: 5/5

Safe to merge — the security-critical scope check and token-exchange flow are correctly implemented and well-tested; OSS standalone behavior is fully preserved.

The new scopes_cover_project predicate on the push path is a correct suffix-match guarded by an empty-slice passthrough, with tests covering substring-confusion and cross-project rejection. The CLI-side token_matches_target cache validation consistently returns false on any decode failure, preventing stale or wrong-target tokens from being reused. All OSS validators initialize scopes: Vec::new(), so single-tenant deployments are unaffected. The one finding is a compatibility nuance on ResolveResponse.manager_id during rolling deploys, not a correctness defect in the core auth path.

crates/alien-cli/src/execution_context.rs — the new required manager_id field in ResolveResponse deserves attention for deployment ordering with its companion platform PR.

Important Files Changed

Filename	Overview
crates/alien-manager/src/routes/registry_proxy.rs	Adds scopes_cover_project pure helper and wires it into require_push_auth after the existing role check; logic is correct, tests cover substring-confusion and cross-project cases.
crates/alien-cli/src/auth.rs	Adds token minting, keyring storage, expiry-aware cache reuse, and 7 targeted unit tests; token_matches_target correctly returns false for all decode-failure/mismatch cases.
crates/alien-cli/src/execution_context.rs	resolve_manager now mints a registry-push JWT and uses it for both artifact-registry setup and the returned ManagerContext; ResolveResponse gains a required manager_id field without serde(default), creating a hard parse failure on version mismatch with the platform.
crates/alien-cli/src/commands/commands.rs	Fixes the Platform-mode crash in commands_task by resolving the manager before use; the registry-push token and hardcoded aws provider side-effects are acknowledged known issues tracked separately.
crates/alien-manager/src/auth/subject.rs	Adds scopes: Vec to Subject with Vec::new() defaults everywhere; Debug impl redacts bearer_token correctly.
crates/alien-bindings/src/providers/artifact_registry/local.rs	upstream_repository_prefix now returns binding_name instead of hardcoded artifacts/default, enabling the routing table to extract project_id for scope checks in both dev and platform modes.

Sequence Diagram

sequenceDiagram
    participant CLI as alien CLI
    participant Platform as Platform API
    participant Keyring as System Keyring
    participant Manager as alien-manager

    CLI->>Keyring: load_manager_token()
    alt cached token valid (not expired, matches manager+project)
        Keyring-->>CLI: cached manager JWT
    else no token or expired or wrong target
        CLI->>Platform: POST /v1/managers/MANAGER_ID/token
        Note right of CLI: purpose=registry-push, project=PROJECT_ID
        Platform-->>CLI: new manager JWT
        CLI->>Keyring: store_manager_token(jwt)
    end

    CLI->>Manager: GET /v1/artifact-registry/PROJECT_ID
    alt repo exists
        Manager-->>CLI: repo name
    else repo not found
        CLI->>Manager: POST /v1/artifact-registry
        Manager-->>CLI: repo name
    end

    CLI->>Manager: POST /v2/REPO/blobs/uploads/
    Note over Manager: require_push_auth checks role then scopes_cover_project
    alt scope covers project
        Manager-->>CLI: 202 Accepted
        CLI->>Manager: PUT blob data
        Manager-->>CLI: 201 Created
    else scope mismatch
        Manager-->>CLI: 403 DENIED
    end

Loading

Prompt To Fix All With AI

Fix the following 1 code review issue. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 1
crates/alien-cli/src/execution_context.rs:572-578
The newly added `manager_id` field is not annotated with `#[serde(default)]`, so if the platform's resolve endpoint doesn't include `managerId` in its JSON — e.g. during a rolling deploy where some instances still run the old version — `serde_json` will return a "missing field `managerId`" parse error. The user will see an opaque deserialization failure rather than anything that hints at a platform-version mismatch. Adding a `#[serde(default)]` (or keeping it as `Option<String>` with an explicit error at mint time) would let the CLI surface a clearer message in that window.

```suggestion
#[derive(serde::Deserialize)]
#[serde(rename_all = "camelCase")]
struct ResolveResponse {
    /// Required for minting the registry-push token; absent on old platform
    /// instances that predate the companion platform PR.
    #[serde(default)]
    manager_id: String,
    manager_url: String,
    project_id: String,
}
```

_{Reviews (3): Last reviewed commit: "fix(cli): fail loud on success-status re..." | Re-trigger Greptile}

[greptile-apps]

Registry-push token bleeds into all resolve_manager callers

resolve_manager's Platform arm now mints a purpose: "registry-push" JWT and wires it into every ManagerContext it returns. Because this function is called unconditionally from deploy.rs, destroy.rs, and deployments.rs::resolve_manager_client, all of those flows will now present a registry-push-scoped token to manager endpoints that handle deployments — replacing the OAuth JWT that was used before this PR. If the platform-side JWT validator enforces the purpose claim on non-push endpoints, alien deploy and alien destroy will start returning 401s after this change. The code comment on line ~437 even explicitly warns "When other platform-mode commands must mint their OWN audience instead of reusing this one," yet the implementation bakes the mint into the shared helper.

Prompt To Fix With AI

This is a comment left during a code review.
Path: crates/alien-cli/src/execution_context.rs
Line: 440-474

Comment:
**Registry-push token bleeds into all `resolve_manager` callers**

`resolve_manager`'s Platform arm now mints a `purpose: "registry-push"` JWT and wires it into every `ManagerContext` it returns. Because this function is called unconditionally from `deploy.rs`, `destroy.rs`, and `deployments.rs::resolve_manager_client`, all of those flows will now present a registry-push-scoped token to manager endpoints that handle deployments — replacing the OAuth JWT that was used before this PR. If the platform-side JWT validator enforces the `purpose` claim on non-push endpoints, `alien deploy` and `alien destroy` will start returning 401s after this change. The code comment on line ~437 even explicitly warns "When other platform-mode commands must mint their OWN audience instead of reusing this one," yet the implementation bakes the mint into the shared helper.

How can I resolve this? If you propose a fix, please make it concise.

[greptile-apps]

Hardcoded "aws" provider triggers spurious artifact-registry setup

resolve_manager unconditionally calls create_or_get_artifact_repo(platform) as part of its implementation (see execution_context.rs line ~452). Passing a hardcoded "aws" here means that every alien commands invoke call in Platform mode will attempt to create/get an AWS artifact repository for the project — regardless of the actual cloud provider. On non-AWS deployments this HTTP call will fail and commands invoke will error before it can even reach the already-acknowledged 401 issue (ALIEN-144). A separate, lightweight helper that resolves the manager URL and mints a token without the artifact-registry side-effect would avoid this.

Prompt To Fix With AI

This is a comment left during a code review.
Path: crates/alien-cli/src/commands/commands.rs
Line: 83-85

Comment:
**Hardcoded `"aws"` provider triggers spurious artifact-registry setup**

`resolve_manager` unconditionally calls `create_or_get_artifact_repo(platform)` as part of its implementation (see `execution_context.rs` line ~452). Passing a hardcoded `"aws"` here means that every `alien commands invoke` call in Platform mode will attempt to create/get an AWS artifact repository for the project — regardless of the actual cloud provider. On non-AWS deployments this HTTP call will fail and `commands invoke` will error before it can even reach the already-acknowledged 401 issue (ALIEN-144). A separate, lightweight helper that resolves the manager URL and mints a token without the artifact-registry side-effect would avoid this.

How can I resolve this? If you propose a fix, please make it concise.

[ItamarZand88]

Closing — restarting from a clean base.