test(policy): prove extension grants cannot bypass secret authority - #63
test(policy): prove extension grants cannot bypass secret authority#63seonghobae wants to merge 2 commits into
Conversation
|
Warning Review limit reached
Next review available in: 33 minutes You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
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. Comment |
Partial implementation of #27 and security evidence for #10.
Buyer/security gap
OriginWeave separates Chromium extension permission from Agent capability, and protected main requires brokered secret delivery plus ordinary risk approval for
FillSecret. Current PR #62 independently covers extension proposal isolation for origin, capability, untrusted instruction, raw-secret delivery and unexpected secret material. This PR is deliberately narrowed to the remaining non-duplicate approval-composition proof.Current unique scope
Current exact head
e83749acd1cf5a0b778ba38eb9d6ed5a9bd1e68fis based directly on protected main67af7c87589edc2039545af335c95064d9b8391cand proves:ProposeTypedAction;FillSecret, exact readable/writable origin authority, and a broker-handle delivery request; butRequireApproval(RiskClass::R3)rather thanAllow.The grant is asserted first so the result cannot pass vacuously because the extension lacked proposal authority.
Duplicate-avoidance RCA
The original head
3059fead1ef0b6cf2f7df765b03c4b00a669b9cfalso tested raw secret rejection and unexpected secret material. Fresh inventory showed PR #62 had advanced to exact heada57873b3688984711918be17aadd348ed9fb12a9and now contains those two composition regressions itself. Retaining them here would create needless parallel coverage and duplicate maintenance. They were removed while preserving this PR's distinct approval-boundary proof.Exact-head evidence
On unchanged exact head
e83749acd1cf5a0b778ba38eb9d6ed5a9bd1e68f:31437994464: success;93616406126: Python repository contracts, formatting, locked workspace check, full tests, strict Clippy and rustdoc all success;93616406182: success, including exact owned production function/line/region/branch enforcement;31437994491: success;31437994454: success;No predecessor-head result is transferred to this exact head. This PR is Ready for review; this scheduled actor does not merge or self-approve.
Truth boundary
This PR adds no secret broker, protected value, browser adapter, extension API, new capability, production API, persistence, workflow mutation, model call, approval evidence, or release claim. It proves only that extension proposal permission cannot manufacture the separate R3 approval required by protected-main Agent policy. Issue #10's trusted broker and issue #27's real extension/runtime boundaries remain open.