fix(rbac): preserve colons in scope resource ids

`buildJwtAbility` parsed scopes with `[a, b, c] = scope.split(":")`
which captures only the first three segments. A scope like
`read:tags:env:staging` (a tag id containing a colon) lost everything
after the second colon — `scopeId` became `"env"`, and the tag
`{ type: "tags", id: "env:staging" }` silently failed to match.

Fix: split into all parts, then take everything after the second
colon as the resource id (`parts.slice(2).join(":")`). Two-segment
scopes (`read:tags`) still produce `scopeId === undefined`,
preserving the type-level wildcard semantic.

Test coverage added for the multi-colon-id path. The bug was
pre-existing in the legacy `checkAuthorization` too — system-generated
ids (friendlyIds like `run_abc`) use underscores, so the issue only
surfaced for user-provided strings (tags), which made it easy to miss.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Author: matt-aitken

internal-packages/rbac/src/ability.test.ts

@@ -53,6 +53,17 @@ describe("buildJwtAbility", () => {
     expect(ability.can("read", { type: "runs" })).toBe(false);
   });
 
+  it("preserves colons in the resource id (everything after the 2nd colon)", () => {
+    // Resource ids can contain colons (e.g. user-provided tags like
+    // `env:staging`). The naive `[a, b, c] = scope.split(":")` form
+    // truncated `read:tags:env:staging` → scopeId="env" and silently
+    // mis-matched. Regression coverage for the multi-colon id path.
+    const ability = buildJwtAbility(["read:tags:env:staging"]);
+    expect(ability.can("read", { type: "tags", id: "env:staging" })).toBe(true);
+    expect(ability.can("read", { type: "tags", id: "env" })).toBe(false);
+    expect(ability.can("read", { type: "tags", id: "env:prod" })).toBe(false);
+  });
+
   it("allows any read with read:all scope", () => {
     const ability = buildJwtAbility(["read:all"]);
     expect(ability.can("read", { type: "runs" })).toBe(true);

internal-packages/rbac/src/ability.ts

@@ -26,7 +26,15 @@ export function buildFallbackAbility(isAdmin: boolean): RbacAbility {
 export function buildJwtAbility(scopes: string[]): RbacAbility {
   const matches = (action: string, r: RbacResource): boolean =>
     scopes.some((scope) => {
-      const [scopeAction, scopeType, scopeId] = scope.split(":");
+      // Only the first two colons are delimiters — everything after the
+      // second colon is the resource id (which may itself contain colons,
+      // e.g. user-provided tags like "env:staging"). Naive
+      // `split(":")` + 3-tuple destructuring truncated such ids to the
+      // first segment and silently failed to match.
+      const parts = scope.split(":");
+      const scopeAction = parts[0];
+      const scopeType = parts[1];
+      const scopeId = parts.length > 2 ? parts.slice(2).join(":") : undefined;
       // Bare `admin` is the universal wildcard. `admin:<type>` is *not* —
       // it falls through to normal matching as action="admin" against
       // resources of that type. Pre-RBAC, the legacy checkAuthorization