Skip to content

test(policy): prove extension grants cannot bypass secret authority - #63

Open
seonghobae wants to merge 2 commits into
mainfrom
test/extension-secret-isolation
Open

test(policy): prove extension grants cannot bypass secret authority#63
seonghobae wants to merge 2 commits into
mainfrom
test/extension-secret-isolation

Conversation

@seonghobae

@seonghobae seonghobae commented Aug 10, 2026

Copy link
Copy Markdown
Contributor

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 e83749acd1cf5a0b778ba38eb9d6ed5a9bd1e68f is based directly on protected main 67af7c87589edc2039545af335c95064d9b8391c and proves:

  • the exact extension/session/context grant genuinely allows ProposeTypedAction;
  • the Agent context independently has FillSecret, exact readable/writable origin authority, and a broker-handle delivery request; but
  • extension proposal authority still cannot skip the ordinary high-risk boundary: policy returns RequireApproval(RiskClass::R3) rather than Allow.

The grant is asserted first so the result cannot pass vacuously because the extension lacked proposal authority.

Duplicate-avoidance RCA

The original head 3059fead1ef0b6cf2f7df765b03c4b00a669b9cf also tested raw secret rejection and unexpected secret material. Fresh inventory showed PR #62 had advanced to exact head a57873b3688984711918be17aadd348ed9fb12a9 and 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:

  • CI run 31437994464: success;
  • Rust contracts job 93616406126: Python repository contracts, formatting, locked workspace check, full tests, strict Clippy and rustdoc all success;
  • Production coverage job 93616406182: success, including exact owned production function/line/region/branch enforcement;
  • Security Scan run 31437994491: success;
  • SAST Semgrep run 31437994454: success;
  • CodeRabbit exact-head commit status: success;
  • no formal reviews or inline review threads are currently returned; and
  • GitHub reports the PR mergeable.

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.

@coderabbitai

coderabbitai Bot commented Aug 10, 2026

Copy link
Copy Markdown

Warning

Review limit reached

@seonghobae, you've reached your PR review limit, so we couldn't start this review.

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 @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

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 configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: efe54c87-47f8-4e6f-888d-4d4ae6c8531e

📥 Commits

Reviewing files that changed from the base of the PR and between 67af7c8 and e83749a.

📒 Files selected for processing (1)
  • crates/originweave-policy/tests/extension_secret_isolation.rs

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

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

@seonghobae
seonghobae marked this pull request as draft August 10, 2026 22:22
@seonghobae
seonghobae marked this pull request as ready for review August 10, 2026 22:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant