Jordan-Hall / Jordan-Hall/browser

[P0][SEC-02] Capability broker and scoped grants

Open
#7 1 comment 0 reactions 0 assignees View on GitHub
Dominant language
No language data
Stars
0
Forks
0
PR merge metrics
No merged PRs in 30d

Description

Parent: #1

## Objective
Make authorization deterministic and independent of model/provider output. Every tool/action dispatch must resolve through a Rust capability broker with explicit scope.

## Scope
- Capability registry keyed by provider, account, operation and version.
- Grants scoped by resource/object, account, recipient/audience, data destination, time, task, financial ceiling and effect class.
- Approval binding to proposal digest, exact arguments, source/resource version, expiry and user identity.
- Revocation and lease invalidation.
- Policy evaluation API for browser, connector, agent, desktop, file and transaction workers.
- Decision/audit records with stable reason codes.

## Architecture requirements
- Models may propose but never mint/expand grants.
- A generic tool name is insufficient authority; provider/account/target semantics are part of the decision.
- Changed material arguments require a fresh authorization decision.

## Acceptance criteria
- [ ] Revoked, expired or stale grants cannot dispatch new work.
- [ ] Forged proposals and materially changed arguments fail authorization.
- [ ] Cross-account/cross-recipient confusion tests fail closed.
- [ ] Every privileged dispatch has a traceable policy decision and capability ID.
- [ ] Worker compromise does not reveal unrelated grants.
- [ ] Stop/cancel can invalidate execution leases immediately.

## Tests
Property tests for scope intersection; approval replay attacks; account/recipient swaps; expiry races; stale resource versions; malicious model/tool descriptions.

## Dependencies
- CORE-01
- SEC-01

**First phase:** P0
**Maturity target:** P4
**Workstream:** Authority and security

Contributor guide

No contributing guide indexed for this repository

Research direction

Start by reviewing dependencies CORE-01 and SEC-01 to understand the surrounding authority model. Then use the listed property-test areas—scope intersection, replay attacks, account or recipient swaps, expiry races, stale versions, and malicious descriptions—as the initial test plan. Done means all acceptance criteria hold, including traceable policy decisions and immediate lease invalidation.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
authorization, backend-api-design, security
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.