Align AI review trust assumptions#2917
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
| - **CI runs require nucleus approval on every PR.** A nucleus team member must explicitly authorize each workflow run before it executes. Drive-by malicious actors cannot run CI; an attacker would need to either (a) compromise a nucleus account or (b) social-engineer a nucleus member into approving a hostile PR. | ||
| - **Changes under `.github/` are heavily scrutinized by humans before CI is approved.** Workflow files, persona prompts, helper scripts, and required-check definitions get a manual eyeball pass. So changes to these paths are not, on their own, a strong "this PR is malicious" signal — the human nucleus reviewer is your backstop and they pay extra attention here. Still flag concrete problems you spot in them, but calibrate severity to the actual risk, not to the path. | ||
| - **External / unknown contributors** still warrant heightened scrutiny per the threat model, but the nucleus-approval gate means a hostile PR can't silently exfiltrate by triggering CI on push. The realistic attack surface is what happens *after* nucleus approves, e.g. malicious code that runs at `cargo build` time once CI is greenlit. | ||
| - **Do not assume a universal CI approval gate.** Workflow execution is governed by repository settings outside the PR diff. Depending on the triggering actor and event, a run may start automatically, require a separate trusted action, or be blocked entirely. Never lower a finding's severity based only on presumed human approval. |
There was a problem hiding this comment.
[HIGH] Trusted security-review policy is modified
This file controls the security reviewer's trust and severity calibration. Per the review's trusted operating policy, modifications under .github/ai-review/ must be treated as a high-severity security-boundary change. A trusted maintainer must independently validate these assumptions against the actual repository workflow settings and trigger paths before merge.
🛡️ AI Review — Skeptic (security review)VERDICT: VULNERABLE VERY HIGH scrutiny (13-day-old account, 0 public repos), mitigated by admin permission, prior substantive merges, matching commit authorship, and no Gittensor association; agent/align-ai-review-trust-context → staging. The textual changes appear internally consistent and security-hardening, but they directly alter the trusted review policy that determines how future security findings are graded. Findings
ConclusionThis PR modifies the AI review trust boundary, which requires trusted human validation and blocks an automated SAFE verdict. No evidence of malicious intent was found. # 🔍 AI Review — Auditor (domain review) has not yet run on this PR. |
|
🔄 AI review updated — Skeptic: VULNERABLE |
1 participant
What changed
.githubcontent as a security boundary without assuming a human backstopWhy
GitHub's repository-level workflow execution policy is an actor allow-list, not a universal approval queue. The previous prompt could therefore cause automated reviewers to under-grade workflow and bootstrap risks based on a control that does not apply to every PR.
Impact
AI security reviews now grade the code path that can execute after any trusted trigger. Repository settings remain outside the prompt rather than being duplicated as a hard-coded actor list that can drift.
Validation
git diff --check.github/workflows/ai-review.ymlconsumescommon.mdas prompt text and does not parse the removed wordingorigin/staging