Skip to content

feat(core): separate Chrome permissions from Agent authority - #175

Open
cursor[bot] wants to merge 15 commits into
mainfrom
cursor/bc-fb7d6c9e-f364-4c0a-bda6-ab0afe7b6b31-cfc4
Open

feat(core): separate Chrome permissions from Agent authority#175
cursor[bot] wants to merge 15 commits into
mainfrom
cursor/bc-fb7d6c9e-f364-4c0a-bda6-ab0afe7b6b31-cfc4

Conversation

@cursor

@cursor cursor Bot commented Aug 16, 2026

Copy link
Copy Markdown

Buyer/security gap

Partial implementation of #27. Chrome extension compatibility evidence must never become OriginWeave Agent authority. A reviewed Manifest V3 permission may prove that stock Chromium exposes a compatibility surface, but it cannot mint an Agent capability, filesystem authority, browser action, secret authority, approval, or any other OriginWeave permission.

Current exact implementation

Protected main is exact 0841d2ab3d8b5e60a03c0a8e818cf438e2716829; current contributor head is exact 7fc96f8bbffe80dc6eabe9efcabfa4362e2c81ac.

originweave-core::chrome_permission_authorizes_agent_action is intentionally fail-closed:

  • reviewed Chrome compatibility permissions (bookmarks, commands, declarativeNetRequest, declarativeNetRequestWithHostAccess, downloads, history, nativeMessaging, scripting, sidePanel, storage, tabs, and windows) return CompatibilitySurfaceOnly;
  • empty, case-shifted, control-bearing, whitespace-tailed, or unreviewed permission tokens return UnrecognizedPermission; and
  • there is no success path, so no ActionKind can make Chrome permission text become OriginWeave Agent authority.

The branch preserves protected-main extension-grant origin binding and exclusive trusted-time expiry. Chrome compatibility evidence remains separate from explicit OriginWeave extension grants and from Agent policy authority.

TDD / current repair

The branch had already advanced beyond the older body snapshot. The intervening exact-head delta, including standard credential-safe Display / std::error::Error behavior and the earlier commands / windows classification repair, was inspected and preserved rather than overwritten.

A fresh current-source audit found one remaining evidence-classification defect: nativeMessaging is a reviewed Manifest V3 compatibility surface used by the active issue #27 native-messaging work, but this boundary still classified it as merely unrecognized. That did not grant authority, yet it made the reviewed compatibility taxonomy incomplete.

  • Test-only head 1dc22225ac3be53569653f8d85b8f0af0ed415c9 added nativeMessaging to the compatibility-only regression first. CI run 32048716882, Rust-contracts job 95442602341, passed repository contracts, formatting, and workspace check and then failed at Run tests. That is the observed RED boundary.
  • Production commit cabe4df327075c1b4564989eb187470470d51d41 added only nativeMessaging to REVIEWED_CHROME_COMPATIBILITY_PERMISSIONS; there is still no success/fallback path and no Agent authority is broadened.
  • Current head 7fc96f8bbffe80dc6eabe9efcabfa4362e2c81ac also makes the Unreleased CHANGELOG code-current by explicitly recording that both downloads and nativeMessaging remain compatibility-only authority surfaces.

The earlier documentation-truth review finding is also no longer present: docs/traceability/extension-authority-security.md continues to label active-PR evidence separately and does not list this PR-only function under protected-main authority.

Exact-current verification

On unchanged exact head 7fc96f8bbffe80dc6eabe9efcabfa4362e2c81ac:

  • CI run 32049209706: success;
  • Rust contracts job 95444247346: success for repository contracts, canonical formatting, locked workspace check, full tests, strict Clippy, and rustdoc;
  • Production coverage job 95444247142: success, including exact owned-production function, line, region, and branch coverage enforcement;
  • Manifest V3 Compatibility run 32049209629: success on the pinned Chromium lane;
  • SAST Semgrep run 32049209527: success;
  • Security Scan run 32049209595: success;
  • current inline review threads: none; and
  • no current-head qualifying formal approval is established. Historical bot comments and the dismissed predecessor human review are not approval or current proof.

No predecessor-head, queued, skipped, cancelled, absent, stale, status-only, model-only, or synthetic evidence is promoted to passing evidence.

Scope boundary

This is IMPLEMENTED_ON_ACTIVE_PR, not protected-main shipped truth. It does not implement native-messaging transport, native-host allow-listing, host-process isolation, extension installation, Chrome message parsing, browser launch/control, filesystem authority, secret brokerage, or the full #27 compatibility/runtime matrix. It changes no workflow, secret, merge rule, scanner policy, or foreign repository.

Standards

Chrome for Developers. (n.d.). chrome.downloads. Google. Retrieved August 16, 2026, from https://developer.chrome.com/docs/extensions/reference/api/downloads

Chrome for Developers. (n.d.). Native messaging. Google. Retrieved August 18, 2026, from https://developer.chrome.com/docs/extensions/develop/concepts/native-messaging

Protected-main AGENTS.md remains authoritative. This scheduled writer does not merge, self-approve, tag, publish, alter workflows, add secrets, or weaken checks.

A Chrome downloads permission is compatibility evidence only. Adapters
must fail closed before treating it as Capability::Download.

Co-authored-by: Seongho Bae <seonghobae@users.noreply.github.com>

@cursor cursor Bot left a comment

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Stale comment

Review — exact head f6c089b8faae015c5b8845296af7cdc3ddcd0c65

chrome_permission_authorizes_agent_action is fail-closed: a Chrome downloads token, and every other reviewed compatibility permission, cannot authorize Agent Download or any other ActionKind. Case, empty, and control-bearing tokens stay UnrecognizedPermission. That is the correct adapter check for ADR 0013 rule 4.

Next action: keep this primitive independent of MV3 runner PRs #43/#176. Do not treat a passing Chrome fixture as Agent filesystem authority. Wire adapters to call this boundary before policy, and add commands and windows to the reviewed-token list when those protected-main surfaces should be classified as CompatibilitySurfaceOnly instead of UnrecognizedPermission. Both paths already refuse the action.

Rust contracts, production coverage, and the pinned Chrome MV3 fixture succeeded on this head at review time. Remaining SAST/security/Strix/review workflows were still queued and are not promoted. This review is not an approval.

View PR

Open in Web View Automation 

Sent by Cursor Automation: Fix Issues

@cursor cursor Bot left a comment

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Review — exact head f6c089b8faae015c5b8845296af7cdc3ddcd0c65

The isolation primitive is sound and independent of the #43/#176 downloads runner. chrome_permission_authorizes_agent_action never returns Ok. Reviewed Chrome tokens including downloads become CompatibilitySurfaceOnly. Empty, case-shifted, newline-injected, and unrecognized tokens become UnrecognizedPermission. The ActionKind argument is intentionally unused so a Chrome permission cannot mint Download or any other Agent action.

is_exact_chrome_permission_token correctly admits mixed-case Chrome names such as sidePanel and declarativeNetRequest while rejecting DOWNLOADS and host-permission punctuation.

Residual, non-blocking

Protected-main MV3 evidence also exercises windows and commands. Those names are not in REVIEWED_CHROME_COMPATIBILITY_PERMISSIONS, so they currently classify as UnrecognizedPermission rather than CompatibilitySurfaceOnly. Both arms still refuse Agent authority. Add them only if an adapter needs the clearer diagnostic; do not treat the omission as a capability leak.

Stay draft until exact-head required checks are green. Do not fold this into the downloads runner, HTTP #37, or reserved MV3 drafts #49/#56/#59/#60/#61.

Open in Web View Automation 

Sent by Cursor Automation: Fix Issues

@cursor

cursor Bot commented Aug 16, 2026

Copy link
Copy Markdown
Author

Bugbot is not enabled for your account, so this pull request was not reviewed.

Enable Bugbot in the Cursor dashboard to get automatic reviews on future PRs.

@seonghobae
seonghobae requested review from seonghobae and removed request for seonghobae August 16, 2026 19:06

@seonghobae seonghobae left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Exact-head review found one current documentation-truth defect that must be fixed before approval. docs/traceability/extension-authority-security.md adds chrome_permission_authorizes_agent_action under the heading “Protected main already provides:”, but protected main is still 0c376acf059be9ddddddfbde1d0189e4f39ef014 and does not contain this PR-only function. That promotes active-PR behavior to shipped truth and violates the repository’s protected-main-vs-active-PR documentation contract. Keep the existing protected-main bullets unchanged and move/label this function as active/non-shipped PR #175 evidence (and make the docs/traceability/README.md wording equally explicit if needed). The Rust fail-closed implementation itself looks coherent on this head; exact-head CI, MV3, SAST, and Security are green. Please repair the truth-status wording without widening scope, then re-run exact-head evidence.

@seonghobae
seonghobae dismissed their stale review August 17, 2026 02:15

Superseded by current exact head db724d4. The current-main reconstruction removed the stale traceability-document changes entirely; fresh compare against protected main 0841d2a contains only CHANGELOG plus the bounded core module/Cargo/test slice. This dismissal is stale review-state cleanup only, not approval; current-head required checks and independent/latest-push approval remain required.

@cursor

cursor Bot commented Aug 17, 2026

Copy link
Copy Markdown
Author

Bugbot is not enabled for your account, so this pull request was not reviewed.

Enable Bugbot in the Cursor dashboard to get automatic reviews on future PRs.

@cursor

cursor Bot commented Aug 17, 2026

Copy link
Copy Markdown
Author

Bugbot is not enabled for your account, so this pull request was not reviewed.

Enable Bugbot in the Cursor dashboard to get automatic reviews on future PRs.

@seonghobae seonghobae changed the title feat(core): refuse Chrome downloads as Agent download feat(core): separate Chrome permissions from Agent authority Aug 17, 2026

Copy link
Copy Markdown
Contributor

Fresh current-source review found one additional issue-#27 compatibility taxonomy gap at exact head 7fc96f8bbffe80dc6eabe9efcabfa4362e2c81ac: Chrome’s current official chrome.management reference requires the manifest permission management for the management API, and that API includes extension enable/disable and uninstall lifecycle operations. Issue #27 explicitly covers install/disable-enable/update-restart behavior. At this boundary, management should therefore be a reviewed compatibility-only permission, never Agent authority.

Owner action on this same canonical branch: add management to chrome_compatibility_permissions_never_mint_agent_authority first and observe the expected RED classification; then add only "management" to REVIEWED_CHROME_COMPATIBILITY_PERMISSIONS. Preserve the existing no-Ok contract and exact-token rejection. No browser-management capability, install authority, OriginWeave grant, or policy authority is widened.

Primary references: https://developer.chrome.com/docs/extensions/reference/api/management and https://developer.chrome.com/docs/extensions/reference/permissions-list . The attempted ref mutation for this test-first repair was blocked before the branch changed, so the exact PR head remains unchanged and no passing evidence is claimed for this gap.

@opencode-agent opencode-agent Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

OpenCode cannot approve yet because required coverage evidence did not pass.

Review outcome

1. HIGH .github/workflows/opencode-review.yml:1 - Coverage evidence did not prove required test/docstring evidence

  • Problem: The required coverage-evidence job result was failure, so OpenCode cannot establish approval sufficiency for this head.

  • Root cause: Automated approval is only valid when the same-head coverage-evidence job proves supported repository test suites passed and configured docstring gates passed or were advisory, or reports not applicable because no supported source files or package manifests exist. Missing, failed, skipped, unavailable, or unsupported-tooling test evidence is a blocker.

  • Fix: Install or configure the repository test/docstring evidence tooling when source files or package manifests exist, rerun the current-head coverage-evidence job, and approve only after it reports success with required evidence or explicit no-source not-applicable evidence.

  • Regression test: Keep the approval branch checking needs.coverage-evidence.result == success before posting APPROVE, and publish REQUEST_CHANGES when coverage-evidence blocker states such as cancelled, skipped, failed, unsupported-tooling, or below-100 evidence are present.

  • Result: REQUEST_CHANGES

  • Reason: coverage-evidence result was failure, so required test/docstring evidence was not proven for current head 7fc96f8bbffe80dc6eabe9efcabfa4362e2c81ac.

  • Head SHA: 7fc96f8bbffe80dc6eabe9efcabfa4362e2c81ac

  • Workflow run: 32185290142

  • Workflow attempt: 1

Coverage evidence

Coverage Decision

  • Result: FAIL
  • Test evidence: not proven passing
  • Docstring evidence: not proven passing when configured
  • Failure count: 1

Changed-File Evidence Map

flowchart LR
  PR["PR changed files"] --> Evidence["OpenCode bounded evidence"]
  Evidence --> S1["Changed file (5 files)"]
  S1 --> I1["repository behavior"]
  I1 --> R1["Review risk: Changed file (5 files)"]
  R1 --> V1["required checks"]
Loading

@opencode-agent

Copy link
Copy Markdown
Contributor

OpenCode Review Overview

  • Head SHA: 7fc96f8bbffe80dc6eabe9efcabfa4362e2c81ac
  • Workflow run: 32185290142
  • Workflow attempt: 1
  • Gate result: REQUEST_CHANGES (approval step)

Pull request overview

OpenCode cannot approve yet because required coverage evidence did not pass.

Review outcome

1. HIGH .github/workflows/opencode-review.yml:1 - Coverage evidence did not prove required test/docstring evidence

  • Problem: The required coverage-evidence job result was failure, so OpenCode cannot establish approval sufficiency for this head.

  • Root cause: Automated approval is only valid when the same-head coverage-evidence job proves supported repository test suites passed and configured docstring gates passed or were advisory, or reports not applicable because no supported source files or package manifests exist. Missing, failed, skipped, unavailable, or unsupported-tooling test evidence is a blocker.

  • Fix: Install or configure the repository test/docstring evidence tooling when source files or package manifests exist, rerun the current-head coverage-evidence job, and approve only after it reports success with required evidence or explicit no-source not-applicable evidence.

  • Regression test: Keep the approval branch checking needs.coverage-evidence.result == success before posting APPROVE, and publish REQUEST_CHANGES when coverage-evidence blocker states such as cancelled, skipped, failed, unsupported-tooling, or below-100 evidence are present.

  • Result: REQUEST_CHANGES

  • Reason: coverage-evidence result was failure, so required test/docstring evidence was not proven for current head 7fc96f8bbffe80dc6eabe9efcabfa4362e2c81ac.

  • Head SHA: 7fc96f8bbffe80dc6eabe9efcabfa4362e2c81ac

  • Workflow run: 32185290142

  • Workflow attempt: 1

Coverage evidence

Coverage Decision

  • Result: FAIL
  • Test evidence: not proven passing
  • Docstring evidence: not proven passing when configured
  • Failure count: 1

Changed-File Evidence Map

flowchart LR
  PR["PR changed files"] --> Evidence["OpenCode bounded evidence"]
  Evidence --> S1["Changed file (5 files)"]
  S1 --> I1["repository behavior"]
  I1 --> R1["Review risk: Changed file (5 files)"]
  R1 --> V1["required checks"]
Loading

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.

2 participants