docs(evi): align authorization note with the shipped principal gate

[evlogai]

Content pass: docs

Scanner ranked 155 files, 0 fixed mechanically, 1 reviewed, 1 changed.

Fixed mechanically

None.

apps/evi/docs/authorization.md

Score 95 → 95 (the sole candidate, T-14 on the "Why admin is not simply allowed everything" section, was judged lawful by the reviewer and left untouched). Verdict: pass after rewrite.

The page claimed an authorization state that no longer matches the source. Three critical factual corrections:

• Autonomous turns run under their own principal. The page said a CI-triage turn would "run under a random contributor's identity". Source: apps/evi/agent/channels/github.ts overrides principalId with AUTONOMOUS_GITHUB_PRINCIPAL (github:evlogai, principalType: 'service'); onPullRequest / onCheckSuite are not wired and carry the same requirement when they land.
• Unattended turns are denied, not parked. The page said a turn hitting an approval gate would "park forever" once onIssue was wired. onIssue is wired, and writePolicy (agent/lib/github/label-approval.ts) denies autonomous turns outright on every write outside label and triage work, so nothing parks.
• Today versus proposal is now explicit. The opener names what ships (isMaintainer gate in trust.ts, the per-tool requireApproval map in extensions/github.ts, writePolicy) versus the tier attribute that remains a design, so the closing premise no longer contradicts the shipped state.

Standard corrections: "every write tool ships behind the SDK's always() approval" corrected to per-tool predicates with closeIssue and createPullRequestReview named as the two omissions; the unsourced "roughly 7k tokens per turn" figure dropped; git__push scope corrected to canAccessAdminTools (maintainers plus schedule sessions, with main/master refused for every caller); "nothing binds the reply to the person who triggered the turn" replaced with the shipped upstream mechanism, eve captures the requester's auth on the pending request and exports ApprovalResponsePolicy, which this deployment does not configure.

Not applied

None.

Reported, not changed

• [T-14] apps/evi/docs/authorization.md:160, dropped by the reviewer as the lawful twin (a conceptual passage framing a decision, carrying its mechanism in the text).

Checks

• node scripts/content-lint/index.mjs apps/evi/docs/authorization.md on the saved file: score 95, 0 dashes, sole candidate T-14 (dropped as above). Command and result on revision 1b8e758's content (digest 0192c31d...), verified by a second content_review pass against the source, verdict pass.
• Verified against vercel/eve@0.71.0 (defaults.ts, approval/definition.ts, channel docs), vercel-labs/github-tools (build.ts), and apps/evi/agent/{channels/github.ts, extensions/github.ts, lib/trust.ts, lib/github/label-approval.ts} at a2cfcca.
• No before-after capture: this is a plain markdown internal design note with no rendered surface. The diff excerpt below stands in.
• No changeset: change confined to apps/*.
• pnpm run lint / typecheck / test not run: markdown-only diff, nothing they cover.

- An automated CI-triage turn would therefore run under a random
- contributor's identity, and, with the tier logic above, under their permissions.
+ `onIssue` dispatches with `defaultGitHubAuth(ctx)` and then overrides the
+ projection: `principalId` becomes `AUTONOMOUS_GITHUB_PRINCIPAL`
+ (`github:evlogai`) with `principalType: "service"`. The triage turn runs as
+ the bot, never as the issue opener.

- **Whoever replies first answers it.** Nothing binds the reply to the person who
-   triggered the turn. An attacker approves their own write.
+ **Whoever replies first answers it.** The binding mechanism exists upstream:
+   eve captures the requester's auth on the pending request and exports
+   `ApprovalResponsePolicy`, which decides whether the responder may settle the
+   call. This deployment configures none, so on GitHub an attacker can approve
+   their own write.

ELI5

The agent keeps an internal design note about who is allowed to make it write things on GitHub. The note still described an older plan: it said unattended bot turns would run under whoever filed the issue, and that nothing stops someone else from approving a request. The actual code had already moved past that: those turns run as the bot's own identity and get refused rather than stuck waiting. This PR updates the note to match the code and clearly separates what already exists from what is still just an idea.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
evi	Ready	Preview	Oct 6, 2026 6:41am UTC

4 Skipped Deployments

Project	Deployment	Actions	Updated
evlog-docs	Skipped	v0	Oct 6, 2026 6:41am UTC
evlog-render-lab	Skipped		Oct 6, 2026 6:41am UTC
evlog-telemetry	Skipped		Oct 6, 2026 6:41am UTC
just-use-evlog	Skipped		Oct 6, 2026 6:41am UTC

[coderabbitai]

Important

Review skipped

Bot user detected.

To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

• Configuration used: defaults
• Review profile: CHILL
• Plan: Advanced
• Run ID: 55cb026e-ce28-470c-a993-fd8c606b234a

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

• Autopilot · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[github-actions]

Thank you for following the naming conventions! 🙏

[pkg-pr-new]

@evlog/cli

npm i https://pkg.pr.new/@evlog/cli@783

evlog

npm i https://pkg.pr.new/evlog@783

@evlog/nuxthub

npm i https://pkg.pr.new/@evlog/nuxthub@783

@evlog/signals

npm i https://pkg.pr.new/@evlog/signals@783

@evlog/telemetry

npm i https://pkg.pr.new/@evlog/telemetry@783

commit: 1b8e758