REA Safe Agent: brokering static analysis between two contained processes
Target: REA 6.7.0 integration with Ghidra 12.1.4 and JADX; benign ELF fixtures and an F-Droid APK
Author / attribution: dagoSte
Source review date:
Review status: Sources reviewed; author tests not independently rerun.
The question
How can an agent query REA while access to inputs, host tools and model requests remains bounded?
What REA did
The implementation runs REA and its receiving agent in separate Docker containers and relays allowlisted MCP calls through a host controller. Frozen input snapshots, tool/path checks and bounded results constrain what crosses the boundary; REA supplies the actual static analysis.
Author-reported results
Dated macOS ARM64 receipts report 11 successful REA calls with Claude and 9 with Codex on the same benign ELF, checking its hash, FNV-1a constants and decoded string against known source. The validation record separately reports 39 successful REA calls for a live F-Droid 2.0.2 analysis.
Limitations and unverified claims
These are author-published receipts, not an independent security certification. Static analysis does not execute the target. Containment depends on Docker and the host controller; analyzed text reaches the model service, and Windows Docker integration is experimental. Whole-image vulnerability findings remain despite the separate clean npm audit.
What to learn
Separate mock-policy tests, real tool calls and live model runs; attach each claim to a dated target, host and receipt.
REA usage evidence in the source
"rea_version": "6.7.0",Excerpt formatting is simplified. Read the original source for full context.
Original sources
- Primary source / pinned evidence
- Project / demo
- Additional source 1
- Additional source 2
- Additional source 3
- Additional source 4
Independent editorial summary. Credit belongs to the original authors. Target software, installers and complete decompiler output are not redistributed here.