[hivecommons-hive]

Closes #17426

The sec-check policy calls gh api repos/<org>/<repo>/dependabot/alerts, but the contributor-tier App token never requested vulnerability_alerts and the permission was absent from the setup docs, so operators had no path to fix the 403.

The mint requests it as optional: if the installation has not accepted it, the mint retries without it (same pattern as Workflows), so hives without sec-check are unaffected. Existing installations must re-accept the permission. No App-manifest builder or permission-advisory checklist exists in code, so nothing was added there.

— hive: agent=scanner backend=copilot model=claude-fable-5.1 copilot=1.0.88 requested_by=@williamdalessandro

[github-actions]

Open PR overlap check

Base branch: v5

Conflicts are checked with every PR merged onto the current tip of v5, so a PR that only needs a rebase is not reported as conflicting with its siblings.

No conflicting open PRs or same-file overlaps were found.

[hivecommons-hive]

Hive status — updated in place; edits do not notify. Full history is in the Activity Monitor.

hive/awaiting-ci: CI pending — sweep will merge when green. (The vulnerability_alerts fallback now retries only on GitHub's 422 permission refusal, so a hung endpoint keeps its single bounded mint window and a repo-scope 422 still costs exactly one mint attempt.)

---

🐝 Hive Agent: scanner | Instance: hosted-available-oke-11-placeholder-r05x | SHA: 3a5882d44

— hive: agent=scanner backend=copilot model=claude-fable-5.1 copilot=1.0.88

Review findings from reviewer-2 (folded here because this head already carries its hive review):

Code reads correct to me; I am routing it to a maintainer only because it changes what the GitHub App asks for, which is a permission decision rather than a code one.

What I verified in the tree, not just the diff:

• src/pkg/github/app.go:338-351 adds a sec-check tier that is exactly the contributor permission set plus VulnerabilityAlerts: read. Only agentmode.TokenTierForRole with role sec-check in ISSUES_AND_PRS yields that tier (src/crux/agentmode/agentmode.go:128), so no other agent's token widens; TestScopedToken_OnlySecCheckTierRequestsVulnerabilityAlerts pins that.
• The retry at app.go:443-451 fires only on a 422 whose message mentions "permission", so a repo-scope 422 (IsRepoScopeMintError, which matches any 422/404) still gets one mint — TestScopedToken_SecCheckRepoScopeErrorDoesNotRetry covers it. The perms.Workflows == nil guard is always true for this tier.
• ModeForTokenTier (agentmode.go:166) and mint.tierScopes (src/pkg/mint/agent.go:50) both learn the new tier, so issue_claims.go:294 and hive-side scope checks keep working. I found no other tier-name switch that would see sec-check as unknown.
• Docs: src/docs/github-app-setup.md gains the permission row with the re-accept step; changelog fragment present.

Decision for a maintainer: the App manifest itself must declare Dependabot alerts: Read-only and every existing installation must re-accept it once (the token request is optional and degrades to a 403 on the alerts call, so nothing breaks before that). That is an App-wide grant even though only the sec-check token requests it. If that is acceptable, I see nothing in the code that should hold this.

Evidence bundle `#174420a08d9a` sha256:0f40e100d5d1c877d0c6b665beecc75191303d79ffb88b5d8481c2c589720e6c — download from the dashboard or `hivectl review evidence #17442`.

[github-actions]

Mutation testing (advisory)

No surviving mutants in changed files (or the run hit its time budget before reporting any).

Advisory only; this job never blocks the PR (#17349).

[hivecommons-hive]

Decision needed: @clubanderson should decide whether vulnerability_alerts: read must also be requested at the trusted/merger tiers (src/pkg/github/app.go:342-357), since a sec-check agent on an ISSUES_PRS_MERGE (L5) hive mints trusted and would still 403, or whether contributor-only is the intended scope.

Mechanically correct, but the fix only covers one of the two tiers sec-check mints at. Routing to a maintainer because this widens the App's requested permission set.

What I verified at ace9ea1:

• src/pkg/github/app.go:424-440 — opts.Permissions points at the same *InstallationPermissions as perms, so clearing perms.VulnerabilityAlerts before the retry does change the second mint request. The new test asserts exactly that (two requests, second without the key, pull_requests still write).
• The retry gate perms.Workflows == nil keeps it from colliding with the Workflows fallback; today only contributor sets VulnerabilityAlerts, so it is correct, if a little indirect.
• installationPermissionMap gains the key, so the test helper and any permission diffing see it.

Gap (medium): the token tier is derived from agent mode, not role — src/crux/agentmode/agentmode.go:124-129 returns m.TokenTier() for every role except the advisory reviewer. The linked #17426 reproduces at ISSUES_AND_PRS (→ contributor), which this PR fixes, but the same report says sec-check is run "at ACMM L4 or L5"; at L5 the agent mints trusted (src/pkg/github/app.go:342-357), which this PR leaves without vulnerability_alerts, so the gh api repos/<org>/<repo>/dependabot/alerts call in sec-check-holdgated.md still 403s there. The docs row (src/docs/github-app-setup.md:96) states the permission unlocks sec-check unconditionally, which would not be true for L5 hives.

Not a defect, noting only: the docs table already has a blank line before the Workflows row (pre-existing, not introduced here), so the new row renders as the last row of the first table.

I have not approved or changed anything.

— hive: agent=reviewer-2 backend=copilot model=claude-fable-5.1 copilot=1.0.88

[hivecommons-hive]

Decision needed: @clubanderson should decide whether the hive App may request Dependabot alerts read (vulnerability_alerts: read) on every contributor-tier token — all ISSUES_AND_PRS agents, not only sec-check — given every installation must re-accept the App permission for it to take effect.

Routing to a maintainer: the code is correct, but it widens what the App token asks for, and that is a permission decision, not a code one.

What I verified in the tree at 3a5882d:

• src/pkg/github/app.go:329-338 adds VulnerabilityAlerts: read to the contributor tier only. ISSUES_AND_PRS agents mint at the contributor tier (src/pkg/scheduler/workflow_push_ceiling_test.go:10), and sec-check is ISSUES_AND_PRS (src/pkg/config/packs/level-5.yaml:221-232), so the fix reaches the agent #17426 describes. It also reaches every other contributor-tier agent — the grant is per-tier, not per-role. Read-only, but broader than the issue's stated need.
• The fallback at app.go:432-440 fires only on isPermissionNotGrantedMintError (app.go:470-477: HTTP 422 and "permission" in the message). A repo-scope 422 ("…does not exist or is not accessible…") does not match, so the hub's one-mint-per-repo accounting that IsRepoScopeMintError (app.go:487-494) feeds is preserved. TestScopedToken_ContributorRepoScopeErrorDoesNotRetry pins that; TestScopedToken_ContributorVulnerabilityAlertsWithFallback pins the degrade path. The perms.Workflows == nil guard keeps it from colliding with the existing Workflows retry on trusted tiers.
• installationPermissionMap (app.go:828) gains the key, so the permission advisory/diff surfaces see it.
• Docs row added to src/docs/github-app-setup.md:96; changelog fragment present. Issue #17426 is Closes-linked.

Operator consequence a human should weigh: until each installation re-accepts the App permission, every contributor-tier mint takes two round-trips (first 422, then retry) and logs a warning per mint. That is the same trade the Workflows grant made, but it is now on the most common tier.

I have not approved or changed anything.

— hive: agent=reviewer backend=copilot model=claude-fable-5.1 copilot=1.0.88

[hivecommons-hive]

Needs a decision, not a merge:

• the reviewer swarm returned requires_human @3a5882d
• the review found: the reviewer marked this change high-risk
• reviewer question: @clubanderson should decide whether the hive App may request Dependabot alerts read (vulnerability_alerts: read) on every contributor-tier token — all ISSUES_AND_PRS agents, not only sec-check — given every installation must re-accept the App permission for it to take effect.
• the automerge lane will not merge this unattended

Head: verdict requires_human @3a5882d, 66/67 checks green, 1 pending, DCO yes, soak 0s of 10m0s.

What to do: approve this head (3a5882d) to merge as-is, or leave a changes requested review (or reply /hive decision <what to change>) and the hive will push the fix.

How to release it:

• After reading the verdict, a trusted merger can submit a GitHub Approve review for the current head and the lane clears the hold on its next pass; /hive approve replies on a PR are acknowledged but not consumed.

_{Clear the cause and the hive re-evaluates on its next pass; the stage moves to stage/090-ready-for-human-merge, stage/095-pre-merge-soak or the merge queue on its own. Approval does not bypass CI, hold labels or other merge gates.}

[clubanderson]

/hive decision scope vulnerability_alerts:read to the sec-check role token only; App-level permission still needs the one-time re-accept

[clubanderson]

Approved: scoped to sec-check token; App permission re-accept is one-time.

[kubestellar-prow]

LGTM label has been added.

Details

Git tree hash: 0983632212f81f9e3ccfc5de32073e7967a68485

[hivecommons-hive]

Read the diff against the tree at c79ec2d, then the issue. This looks correct to me.

What I verified:

• Role plumbing is real, not just a constant. src/crux/agent/manager_tokens.go:969 and manager_sandbox.go:179 both call TokenTierForRole(m.agentMode(a), a.Config.Role), and the quickstart agent is role: sec-check (src/deploy/hive-quickstart.yaml:119), so the new branch in agentmode.go:128 actually fires for the shipped sec-check agent.
• Default mode coverage. crux.DefaultAgentMode (src/crux/agentmode.go:39-54) puts sec-check at ISSUES_AND_PRS for ACMM L4, L5 and L6, which is the mode the issue reports (L4/L5 holdgated). An operator who overrides mode: ISSUES_PRS_MERGE on sec-check gets the plain trusted token and still 403s — the test at reviewer_tier_test.go:85 pins that as intentional and the docs row says "ISSUES_AND_PRS agent with role sec-check", so it is consistent; just noting it as the one configuration the fix does not reach.
• No fall-through to a read-only tier. mint.ScopesForTier (src/pkg/mint/agent.go:57-62) falls back to advisor scopes for an unknown tier, which would have silently demoted the hive-side mint token; the PR adds the "sec-check" entry at agent.go:50. ModeForTokenTier (agentmode.go:166) maps it back to ISSUES_AND_PRS.
• Retry is bounded to the right failure. isPermissionNotGrantedMintError (app.go:484) requires a 422 whose message mentions "permission", and the guard at app.go:443 also requires perms.Workflows == nil, so the repo-scope 422 (#7869) and the existing Workflows fallback never earn a second mint; opts.Permissions is the same perms pointer, so clearing VulnerabilityAlerts before the retry takes effect. Covered by the three new tests in workflows_permission_test.go.
• Least privilege. Only the sec-check tier sets VulnerabilityAlerts (app.go:345-351); TestScopedToken_OnlySecCheckTierRequestsVulnerabilityAlerts asserts every other tier omits it.

Intent: #17426 is triage/accepted and asks for exactly this permission plus the docs row, so the App-level widening is the maintainer's stated ask, not a new decision; the PR narrows it further to one role. Body matches the diff. Operator-facing: existing installations must re-accept the permission once, which the docs row and changelog both say.

— hive: agent=reviewer backend=copilot model=claude-fable-5.1 copilot=1.0.88

[hivecommons-hive]

Read the diff against the tree at 0a08d9a, then the callers. This looks correct to me.

What I verified

• src/crux/agentmode/agentmode.go:128-130 — the new sec-check tier is only yielded for ModeIssuesAndPRs + role sec-check, and ModeForTokenTier maps it back to ModeIssuesAndPRs (agentmode.go:166), so the mode ladder is unchanged. Every shipped sec-check agent runs at mode: ISSUES_AND_PRS (src/pkg/config/packs/level-{4,5,6}.yaml), so the tier actually reaches the mint via crux/agent/manager_tokens.go:969 → ScopedTokenForRepos.
• src/pkg/github/app.go:338-351 — the sec-check permission set is the contributor set plus VulnerabilityAlerts: read, nothing wider. installationPermissionMap (app.go:839) learns the key so the permission advisory can report it.
• src/pkg/github/app.go:443-451 — the fallback mint mutates perms, which opts.Permissions points at (app.go:433), so the retry really does drop the grant. The guard isPermissionNotGrantedMintError (app.go:480-489) requires a 422 whose message contains "permission"; the repo-scope 422 ("not accessible to the parent installation") does not match, so that path still returns on the first mint and keeps the hub's one-mint-per-repo accounting intact. TestScopedToken_SecCheckRepoScopeErrorDoesNotRetry pins this.
• src/pkg/mint/agent.go:50 — hive-side scopes for sec-check are identical to contributor, so the only widening is the GitHub-side read on Dependabot alerts, exactly what #17426 asks for.

For the operator merging this: the App itself has to declare Dependabot alerts: Read-only and every installation must re-accept once — the PR documents this in src/docs/github-app-setup.md:96 and the fallback keeps minting until then, so the change is safe to land before the App setting is flipped.

— hive: agent=reviewer backend=copilot model=claude-fable-5.1 copilot=1.0.88

[clubanderson]

/lgtm
/approve

[kubestellar-prow]

LGTM label has been added.

Details

Git tree hash: 2d2def50c7ec7b940ad1caae40a02141d379ba71

[kubestellar-prow]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: clubanderson

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [clubanderson]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[github-actions]

Thank you for your contribution! Your PR has been merged.

We'd love to hear how your experience was: share feedback