[GH-ISSUE #36] Add approval-gated dynamic observation providers #25

Closed
opened 2026-10-15 18:20:07 +00:00 by bsakaguchi · 3 comments
Owner

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

Goal

Add bounded runtime evidence collection only after ownership and side-effect policies are enforced.

Candidate providers

LLDB, Frida, fs_usage, log stream, lsof, process-tree tracing, network and protocol capture, Electron or Node inspector, and PTY session capture.

Requirements

Every capability declares whether it is read-only, launches a target, may show UI, may contact a network, may change permissions, writes files or targets, or requires elevated privileges.

Dynamic operations must use explicit approval gates, owned process lineage, contained temporary roots, time and output limits, cancellation, sanitized diagnostics, and cleanup verification.

Acceptance criteria

  • No dynamic provider can run without a matching policy decision.
  • Unrelated processes cannot be observed or terminated.
  • Results identify observed versus inferred evidence and include timestamps and artifact/process identity.
  • Tests cover denial, cancellation, timeout, child cleanup, output truncation, and partial failure.

Roadmap expansion

First dynamic provider: deterministic process capture

Later providers and controlled environments

The first adapter requires an absolute executable and explicit approval, runs inside an isolated HOME/root/process group, denies external network by default, redacts secrets, bounds output, and proves cleanup. Windows PTY capture remains explicitly unavailable until a ConPTY adapter exists.

Managed-runtime characterization workstream

Dynamic observation must include a provider-neutral managed-runtime characterization family, not only native debuggers and whole-process capture.

Required policy distinctions

Model separate grants for:

  • static runtime/package inspection;
  • creation of a temporary instrumented copy;
  • execution of selected managed-runtime code;
  • Node Inspector attachment to a provider-owned process;
  • declared filesystem/process/network/native effects;
  • persistence/export of evidence or instrumented artifacts.

Approval for one does not imply the others.

Ownership and integrity

Every operation binds to exact source and runtime digests. Instrumentation occurs only in an owned temporary root, records a transformation manifest, never changes the authority in place, and proves source rehash plus cleanup. Instrumented observations are controlled replay, not shipped-artifact authority.

Boundary enforcement

Managed-runtime plans declare allowed modules, globals, environment keys, roots, loopback endpoints, children, native/Wasm bridges, timers, calls, bytes, handles, duration, and object-graph depth. Undeclared effects fail closed. Inspector operations attach only to provider-launched owned processes.

Evidence and failures

Record inputs, outputs, throws, asynchronous settlement, ordered effects, static-to-runtime correlations, completeness, truncation, and cleanup. Distinguish artifact mismatch, ambiguous target, policy denial, undeclared effect, inspector disconnect, crash, cancellation, resource leak, and cleanup failure.

Acceptance fixture

Hash a minified JavaScript fixture, create a deterministic temporary export instrumentation, invoke one selected function twice under controlled clock/randomness, observe declared file/child/loopback effects, reject an undeclared effect, cancel an Inspector run, and prove all descendants/handles/temp files are removed while the authoritative artifact remains byte-identical.

Track the detailed capability in #267.

Originally created by @morluto on GitHub (Jul 12, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/36 ## Goal Add bounded runtime evidence collection only after ownership and side-effect policies are enforced. ## Candidate providers LLDB, Frida, fs_usage, log stream, lsof, process-tree tracing, network and protocol capture, Electron or Node inspector, and PTY session capture. ## Requirements Every capability declares whether it is read-only, launches a target, may show UI, may contact a network, may change permissions, writes files or targets, or requires elevated privileges. Dynamic operations must use explicit approval gates, owned process lineage, contained temporary roots, time and output limits, cancellation, sanitized diagnostics, and cleanup verification. ## Acceptance criteria - No dynamic provider can run without a matching policy decision. - Unrelated processes cannot be observed or terminated. - Results identify observed versus inferred evidence and include timestamps and artifact/process identity. - Tests cover denial, cancellation, timeout, child cleanup, output truncation, and partial failure. ## Roadmap expansion ### First dynamic provider: deterministic process capture - [x] #57 - [x] #58 - [ ] #59 - [x] #60 - [x] #61 - [x] #62 ### Later providers and controlled environments - [ ] #69 - [x] #70 - [ ] #71 The first adapter requires an absolute executable and explicit approval, runs inside an isolated HOME/root/process group, denies external network by default, redacts secrets, bounds output, and proves cleanup. Windows PTY capture remains explicitly unavailable until a ConPTY adapter exists. ## Managed-runtime characterization workstream Dynamic observation must include a provider-neutral managed-runtime characterization family, not only native debuggers and whole-process capture. ### Required policy distinctions Model separate grants for: - static runtime/package inspection; - creation of a temporary instrumented copy; - execution of selected managed-runtime code; - Node Inspector attachment to a provider-owned process; - declared filesystem/process/network/native effects; - persistence/export of evidence or instrumented artifacts. Approval for one does not imply the others. ### Ownership and integrity Every operation binds to exact source and runtime digests. Instrumentation occurs only in an owned temporary root, records a transformation manifest, never changes the authority in place, and proves source rehash plus cleanup. Instrumented observations are controlled replay, not shipped-artifact authority. ### Boundary enforcement Managed-runtime plans declare allowed modules, globals, environment keys, roots, loopback endpoints, children, native/Wasm bridges, timers, calls, bytes, handles, duration, and object-graph depth. Undeclared effects fail closed. Inspector operations attach only to provider-launched owned processes. ### Evidence and failures Record inputs, outputs, throws, asynchronous settlement, ordered effects, static-to-runtime correlations, completeness, truncation, and cleanup. Distinguish artifact mismatch, ambiguous target, policy denial, undeclared effect, inspector disconnect, crash, cancellation, resource leak, and cleanup failure. ### Acceptance fixture Hash a minified JavaScript fixture, create a deterministic temporary export instrumentation, invoke one selected function twice under controlled clock/randomness, observe declared file/child/loopback effects, reject an undeclared effect, cancel an Inspector run, and prove all descendants/handles/temp files are removed while the authoritative artifact remains byte-identical. Track the detailed capability in #267.
Author
Owner

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

Approval policy, process capture, passive browser/Electron observation, and controlled JavaScript replay now deliver the first dynamic-observation architecture slices. Keep this open for later provider expansion, managed characterization, Windows ConPTY/strong ownership, and provider-specific real-runtime proof rather than describing all dynamic observation as absent.

<!-- gh-comment-id:5001711457 --> @morluto commented on GitHub (Jul 17, 2026): Approval policy, process capture, passive browser/Electron observation, and controlled JavaScript replay now deliver the first dynamic-observation architecture slices. Keep this open for later provider expansion, managed characterization, Windows ConPTY/strong ownership, and provider-specific real-runtime proof rather than describing all dynamic observation as absent.
Author
Owner

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

Split into focused child issues:

These replace the broad remaining scope in this issue. Closing this parent can happen once all children are closed.

<!-- gh-comment-id:5023443668 --> @morluto commented on GitHub (Jul 20, 2026): Split into focused child issues: - [ ] #358 - [ ] #359 These replace the broad remaining scope in this issue. Closing this parent can happen once all children are closed.
Author
Owner

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

Closing as out of scope / premature for the current local CLI/MCP reverse-engineering focus. No concrete implementation exists yet, and the work overlaps with existing passive browser/Electron observation, process capture, and skill machinery. Can be reopened when a specific runtime observation use case is ready.

<!-- gh-comment-id:5023639172 --> @morluto commented on GitHub (Jul 20, 2026): Closing as out of scope / premature for the current local CLI/MCP reverse-engineering focus. No concrete implementation exists yet, and the work overlaps with existing passive browser/Electron observation, process capture, and skill machinery. Can be reopened when a specific runtime observation use case is ready.
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#25
No description provided.