Jordan-Hall / Jordan-Hall/browser
[P0][SEC-02] Capability broker and scoped grants
- 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