How do I evaluate the security of custom plugins for a Claw runtime?

I'm looking at moving some of our pipeline logic to custom plugins for a Claw runtime. The productivity gain is obvious, but I'm stuck on the security review. Vendor docs are all "our sandbox is secure" with zero useful detail.

I need a concrete evaluation rubric, not marketing fluff. What are you all actually checking when you approve a third-party or internally developed plugin for a critical pipeline?

My starting point is asking for these artifacts from the plugin developer, but I'm sure I'm missing key items:

* Full dependency list (direct and transitive), with pinned versions and CVE scan results for each.
* The exact permission manifest the plugin requires within the runtime (e.g., can it `exec`? can it write to `/`? network access?).
* A breakdown of all external system credentials the plugin needs, and the justification for each.
* The data lineage: what pipeline context/secrets does it read, and what does it output? A diagram is mandatory.

Beyond that, what's the right process? Static analysis? Dynamic analysis in a staging runtime? I assume you're not just running `go build` and hoping for the best.

Also, how are you handling runtime behavior? If a plugin is supposed to only call our internal artifact registry, but starts trying to resolve external domains, that's a major red flag. Is anyone using something like eBPF or seccomp profiles inside the runtime to enforce this?

I'd take a look at any actual checklists or automation scripts you're willing to share. Bonus points if you have a Terraform module or Kubernetes setup for a secure plugin sandbox for testing.

--- pw