[GH-ISSUE #114] Introduce unified scoped permission grants for local REA capabilities #73

Closed
opened 2026-10-15 18:20:50 +00:00 by bsakaguchi · 1 comment
Owner

Originally created by @morluto on GitHub (Jul 13, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/114

Summary

Replace capability-specific startup-environment friction with one unified, auditable policy engine for local filesystem, executable, mount, process, environment, and network permissions.

Retain administrator/startup policy as a hard ceiling. Add once, session, and optional project grants within that ceiling. #96 remains the process-capture elicitation consumer; this issue defines the shared policy substrate.

Current state in REA 1.3.0

Separate environment variables gate different capabilities, including:

  • process executable and working roots;
  • process environment names and network mode;
  • Evidence import/export roots;
  • investigation input roots;
  • investigation workspace roots;
  • analysis snapshot roots;
  • native DMG mounting.

This is safe but fragmented. Agents receive disabled/outside-root errors, users edit MCP configuration, and the server often requires restart.

Goals

  • One policy vocabulary and evaluator.
  • Least-privilege grants scoped by capability.
  • Administrator ceilings plus user/session grants.
  • Exact subset checking on every operation.
  • Clear review, audit, expiry, and revocation.
  • No secret values in consent or logs.
  • Runtime reload without restart where safe.
  • Consistent CLI and MCP behavior.

Permission model

A grant should describe:

  • capability: process_capture, evidence_read, evidence_write, investigation_input, snapshot_read, snapshot_write, artifact_extract, native_mount, or another registered capability;
  • filesystem roots and access mode;
  • executable paths/roots;
  • allowed environment variable names;
  • network mode: none, loopback, or explicitly approved host/external scope;
  • mount permission;
  • operation limits;
  • lifetime: once, session, or persistent project;
  • issuer and creation time;
  • parent administrator ceiling;
  • audit/revocation identity.

Evaluation

For every operation:

  1. Normalize requested paths without following unsafe escapes.
  2. Build the exact requested scope.
  3. Load the administrator ceiling.
  4. Load applicable session/project grants.
  5. Prove requested scope is a subset.
  6. Either execute, elicit a bounded grant where supported, or return typed remediation.
  7. Record the decision without storing secret values.

Filesystem roots suggested by a client are context, not authorization.

Lifetimes

Once

Valid for one normalized operation identity and consumed after use.

Session

Held in memory, bound to the MCP connection/auth context, and revoked on disconnect.

Project

Explicitly persisted in an owner-only policy store, bound to canonical project identity, inspectable and revocable. Never the default.

User experience

Provide:

  • rea policy status;
  • rea policy explain ;
  • rea policy list;
  • rea policy revoke ;
  • dry-run evaluation showing missing scope;
  • exact restart-required status if runtime reload is impossible.

MCP-capable clients may use form elicitation from #96. Non-elicitation clients receive exact structured configuration guidance.

Security requirements

  • Startup/admin policy is a maximum ceiling unless changed through an explicit trusted local flow.
  • Agents cannot broaden their own ceiling.
  • Symlink, canonicalization, and macOS /var versus /private/var behavior must be handled consistently.
  • Environment values are never displayed or persisted in grants.
  • Loopback and external networking are separate permissions.
  • Grants do not authorize unrelated tools merely because paths overlap.
  • Revocation affects future operations immediately.
  • Active operations follow documented revocation semantics.
  • Policy files use owner-only permissions and atomic writes.
  • Audit records exclude credentials and captured content.

Acceptance criteria

  • All gated local capabilities use one shared policy evaluator.
  • Existing environment variables map into the administrator ceiling for compatibility.
  • Once and session grants work without server restart.
  • Optional project grants are explicit, inspectable, and revocable.
  • Every denial returns requested scope, missing scope, remediation, and restart requirement through #100's typed contract.
  • #96 process-capture elicitation issues grants through this engine.
  • Loopback-only networking is enforceable independently of external networking.
  • Path canonicalization and symlink escapes fail closed.
  • Session grants disappear on disconnect.
  • Tests cover subset reuse, expansion, conflicting grants, expiry, revocation, canonical aliases, symlinks, environment names, network modes, and non-elicitation fallback.
  • CLI and MCP share identical evaluation semantics.
  • Documentation includes migration from current environment variables.

Non-goals

  • Replacing OS-level sandboxing.
  • Treating REA as a security sandbox.
  • Storing secrets in policy.
  • Automatically granting access based on workspace roots.
  • Allowing elicitation to override an administrator ceiling.

Relationships

  • #96 implements the process-capture consent workflow.
  • #101 reflects policy availability in tool discovery.
  • #100 defines permission-required structured errors.
  • #97 task execution must retain the initiating grant context.
Originally created by @morluto on GitHub (Jul 13, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/114 ## Summary Replace capability-specific startup-environment friction with one unified, auditable policy engine for local filesystem, executable, mount, process, environment, and network permissions. Retain administrator/startup policy as a hard ceiling. Add once, session, and optional project grants within that ceiling. #96 remains the process-capture elicitation consumer; this issue defines the shared policy substrate. ## Current state in REA 1.3.0 Separate environment variables gate different capabilities, including: - process executable and working roots; - process environment names and network mode; - Evidence import/export roots; - investigation input roots; - investigation workspace roots; - analysis snapshot roots; - native DMG mounting. This is safe but fragmented. Agents receive disabled/outside-root errors, users edit MCP configuration, and the server often requires restart. ## Goals - One policy vocabulary and evaluator. - Least-privilege grants scoped by capability. - Administrator ceilings plus user/session grants. - Exact subset checking on every operation. - Clear review, audit, expiry, and revocation. - No secret values in consent or logs. - Runtime reload without restart where safe. - Consistent CLI and MCP behavior. ## Permission model A grant should describe: - capability: process_capture, evidence_read, evidence_write, investigation_input, snapshot_read, snapshot_write, artifact_extract, native_mount, or another registered capability; - filesystem roots and access mode; - executable paths/roots; - allowed environment variable names; - network mode: none, loopback, or explicitly approved host/external scope; - mount permission; - operation limits; - lifetime: once, session, or persistent project; - issuer and creation time; - parent administrator ceiling; - audit/revocation identity. ## Evaluation For every operation: 1. Normalize requested paths without following unsafe escapes. 2. Build the exact requested scope. 3. Load the administrator ceiling. 4. Load applicable session/project grants. 5. Prove requested scope is a subset. 6. Either execute, elicit a bounded grant where supported, or return typed remediation. 7. Record the decision without storing secret values. Filesystem roots suggested by a client are context, not authorization. ## Lifetimes ### Once Valid for one normalized operation identity and consumed after use. ### Session Held in memory, bound to the MCP connection/auth context, and revoked on disconnect. ### Project Explicitly persisted in an owner-only policy store, bound to canonical project identity, inspectable and revocable. Never the default. ## User experience Provide: - rea policy status; - rea policy explain <operation-or-scenario>; - rea policy list; - rea policy revoke <grant-id>; - dry-run evaluation showing missing scope; - exact restart-required status if runtime reload is impossible. MCP-capable clients may use form elicitation from #96. Non-elicitation clients receive exact structured configuration guidance. ## Security requirements - Startup/admin policy is a maximum ceiling unless changed through an explicit trusted local flow. - Agents cannot broaden their own ceiling. - Symlink, canonicalization, and macOS /var versus /private/var behavior must be handled consistently. - Environment values are never displayed or persisted in grants. - Loopback and external networking are separate permissions. - Grants do not authorize unrelated tools merely because paths overlap. - Revocation affects future operations immediately. - Active operations follow documented revocation semantics. - Policy files use owner-only permissions and atomic writes. - Audit records exclude credentials and captured content. ## Acceptance criteria - [ ] All gated local capabilities use one shared policy evaluator. - [ ] Existing environment variables map into the administrator ceiling for compatibility. - [ ] Once and session grants work without server restart. - [ ] Optional project grants are explicit, inspectable, and revocable. - [ ] Every denial returns requested scope, missing scope, remediation, and restart requirement through #100's typed contract. - [ ] #96 process-capture elicitation issues grants through this engine. - [ ] Loopback-only networking is enforceable independently of external networking. - [ ] Path canonicalization and symlink escapes fail closed. - [ ] Session grants disappear on disconnect. - [ ] Tests cover subset reuse, expansion, conflicting grants, expiry, revocation, canonical aliases, symlinks, environment names, network modes, and non-elicitation fallback. - [ ] CLI and MCP share identical evaluation semantics. - [ ] Documentation includes migration from current environment variables. ## Non-goals - Replacing OS-level sandboxing. - Treating REA as a security sandbox. - Storing secrets in policy. - Automatically granting access based on workspace roots. - Allowing elicitation to override an administrator ceiling. ## Relationships - #96 implements the process-capture consent workflow. - #101 reflects policy availability in tool discovery. - #100 defines permission-required structured errors. - #97 task execution must retain the initiating grant context.
bsakaguchi 2026-10-15 18:20:50 +00:00
Author
Owner

@morluto commented on GitHub (Jul 20, 2026):

Closing as completed. The unified scoped permission-grant engine is now shipped:

  • src/application/PermissionAuthority.ts and src/application/ProjectPermissionStore.ts implement the evaluator and persisted project grants.
  • src/domain/permissionPolicy.ts models administrator ceilings and once / session / project / administrator grant lifetimes.
  • src/cliPolicyCommands.ts exposes rea policy status|list|explain|revoke.
  • Tests (tests/permissionPolicy.test.ts, tests/permissionAuthority.test.ts, tests/projectPermissionStore.test.ts, tests/processCapturePermission.test.ts) cover subset checking, path canonicalization, symlink escape, expiry, revocation, and network-mode enforcement.

Remaining process-capture elicitation work continues in #96.

<!-- gh-comment-id:5023308055 --> @morluto commented on GitHub (Jul 20, 2026): Closing as completed. The unified scoped permission-grant engine is now shipped: - `src/application/PermissionAuthority.ts` and `src/application/ProjectPermissionStore.ts` implement the evaluator and persisted project grants. - `src/domain/permissionPolicy.ts` models administrator ceilings and `once` / `session` / `project` / `administrator` grant lifetimes. - `src/cliPolicyCommands.ts` exposes `rea policy status|list|explain|revoke`. - Tests (`tests/permissionPolicy.test.ts`, `tests/permissionAuthority.test.ts`, `tests/projectPermissionStore.test.ts`, `tests/processCapturePermission.test.ts`) cover subset checking, path canonicalization, symlink escape, expiry, revocation, and network-mode enforcement. Remaining process-capture elicitation work continues in #96.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
morluto/rea#73
No description provided.