In regards to the suggested collector approach: Currently, the peer nodes can deploy themselves to other surrounding nodes, and there's also a "discovery" stra

In regards to the suggested collector approach: Currently, the peer nodes can deploy themselves to other surrounding nodes, and there's also a "discovery" strategy that tries to find out as much as possible about surrounding systems in the network. This usually leads to running the binary on the other system, collecting the information, and removing the binary and the report from /tmp afterwards. Initially I wanted to push this as a pentesting approach, and simulating actual exploits inside the network to see "how far" someone could go, where the critical hops are etc. Maybe I am seeing this a little wrong, but would such an approach work for organizations where multiple teams share an ownership of a system? Maybe on a scheduled basis so it doesn't conflict with high network load times? This way there would be basically a collector that re-routes the S/N/SaaSBOM reports back to the dashboard where the cyber security team would operate in. Inside the program, it's already implemented an basically just a different action that's running. In that case it would be the "tholian-guard <collect>" action vs the EDR-mode "tholian-guard protect" action. Thanks much, this is very valueable feedback I need to think more about, and also the way I'm communicating/designing the dashboard workflows for this scenario.