Repository navigation
Bind Numbat findings to managed agents - #4
Conversation
Co-authored-by: gagan114662 <[email protected]> Signed-off-by: gagan114662 <[email protected]>
|
Caution The consumer version of Gemini Code Assist on GitHub has been sunset. All code review activity has officially ceased. |
![xhawk-ai[bot]](https://avatars.githubusercontent.com/in/2457056?s=60&v=4){kind=small}
There was a problem hiding this comment.
📋 Review Summary
I reviewed the change that stamps managed agent pubkeys into spawned runtimes and switches Numbat findings from a shared live.ndjson sink to per-agent files resolved from that identity. The main concern is that the identity binding is still chosen from the monitored process environment at callback time, so a runtime can misdirect or suppress its own Guardian findings before Buzz reads them.
🔍 Findings
🟠 High 1
| } | ||
|
|
||
| fn numbat_findings_template(app: &AppHandle) -> Result<PathBuf, String> { | ||
| Ok(numbat_dir(app)?.join("${BUZZ_MANAGED_AGENT_PUBKEY}.ndjson")) |
There was a problem hiding this comment.
🟠 High
This makes the evidence sink depend on BUZZ_MANAGED_AGENT_PUBKEY as expanded from the monitored runtime's environment at callback time. A managed agent can run a tool/subprocess with this variable unset or set to another 64-hex pubkey, causing Numbat to append the finding to a different file while read_numbat_findings continues reading only the original agent's path, so the finding is either hidden from the originating agent or attributed to another one. The callback sink needs to validate/derive the managed identity outside agent-controlled environment mutation before choosing the output file.
Summary
Validation
Existing repository checks
pnpm checkstill reports the pre-existingruntime.rsfile-size overage (the file is 1,060 lines against a 1,033-line cap) and two unrelated Biome informational notices inpersonaCatalogRelay.test.mjs.