OWASP / OWASP/browser-security-project
[V7.1] Add requirement to enumerate agent-invocable definitions (skills) reachable at run time
Nobody has claimed this yet.
- Dominant language
- HTML
- Stars
- 5
- Forks
- 1
- PR merge metrics
- No merged PRs in 30d
Description
Summary
Section 7.1 inventories and sanctions AI capabilities as products: "AI-enabled browsers, sidebars, copilots, and agentic extensions in use are inventoried and classified as sanctioned or unsanctioned" (7.1.1). What an agentic capability can do at run time is increasingly set by loadable definitions (skills, task templates, connectors) rather than by the product itself, and those definitions sit outside every current inventory requirement.
Problem
A sanctioned copilot with a user-added or user-modified skill remains "sanctioned" under 7.1.1, while its action surface has changed. No requirement asks the organization to know what an agent can invoke at run time.
The platform layer already documents this. Chromium's upcoming EnterprisePublishedSkills enterprise policy lets an organization publish up to 10 skills, each pinned by an immutable URL and a SHA-256 hash verified "before it is applied". The same policy description states that published skills appear "in addition to their personal skills" and that "users can view, modify, and save these skills for their personal use" (policy definition). So on the platform itself, the set the agent can invoke is not bounded by the set the organization published, and the executed version of a published skill can differ from the one whose hash the organization holds.
Timing: the scope-side controls are already shipping (GeminiActOnWebSettings since Chrome 143, GeminiActOnWebAllowedForURLs/BlockedForURLs since 146), while EnterprisePublishedSkills is still marked future_on. A v0.1 requirement here lands before the surface does.
Proposed addition
BSVS-7.1.4 (Level 2, consistent with 7.1.1-7.1.3):
Verify that, for each sanctioned AI capability, the agent-invocable definitions (skills, task templates, connectors, or equivalent) reachable at run time are enumerated, distinguishing those published and integrity-pinned by the organization from those added or modified locally by the user.
Evidence an auditor can request: the organization's published and pinned set, and a run-time enumeration taken from a managed endpoint, with the difference recorded.
Scope clarification
Not a duplicate of 7.1.1: that requirement inventories the products; this one inventories the definitions a sanctioned product loads. Not a duplicate of 3.3.1: extension inventory covers installed extensions and their permission sets, not definitions inside a sanctioned AI capability. Not a duplicate of 7.2.2: least privilege presumes a scope, but nothing verifies the enumeration that scope is computed against.
Research scope
Verified against Chromium's policy definitions (primary source, linked above). Other major browsers were not measured for this issue; the requirement text is platform-neutral.
Happy to submit a PR with the exact wording if the direction is agreed.
Avp9.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reading the proposed BSVS-7.1.4 text and Chromium's linked EnterprisePublishedSkills.yaml policy definition. Locate the repository's requirements source and compare sections 7.1.1-7.1.3, 3.3.1, and 7.2.2. Done means the new requirement is added with its evidence distinction and cross-references preserved.
Written by the indexing model from the issue text.
Assessment
- Domain
- documentation, security
- Issue type
- Feature
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 58/100