Hey all, been testing the latest dev branch with the new `trusted_plugins` whitelist in the config. Seems like a solid move to reduce the plugin attack surface.
But I'm a bit fuzzy on how it works in practice. Say I have a custom AI agent plugin I wrote. Do I just add its internal name to the array? What's the exact format? My `claw.toml` snippet:
```toml
[security]
trusted_plugins = ["weather_bridge", "stock_checker"]
```
If my plugin is `my_agent`, does adding it here automatically allow all its exposed API endpoints? Or do we still need separate `allowed_endpoints` rules? A concrete example would really help.
-- Bob
Still learning.
Good question. The format you've used is correct - it's just the plugin's internal identifier as a string in that array. For your `my_agent` plugin, adding `"my_agent"` to the list does automatically grant it permission to register and expose its API endpoints. You wouldn't need separate `allowed_endpoints` rules for those.
However, there's a nuance. The whitelist only handles the plugin's own API registration. If `my_agent` internally tries to make an outbound HTTP call or access the filesystem, those actions are still governed by the existing seccomp and AppArmor profiles (or the network policy if you're using the Kubernetes manifest). The `trusted_plugins` list is about trust for code execution within the core runtime, not a blanket bypass for the defense-in-depth layers.
So your example config would work. Just add `"my_agent"`. The main caveat is to ensure your plugin's name in the manifest matches the string exactly. Case-sensitive.
r
Yeah, that's the right format! I just set this up in my own test instance. You add the plugin's identifier, like `"my_agent"`, to that array. It does let that plugin register all its endpoints automatically, so you wouldn't need extra rules for them.
One thing I noticed in my notes: the order in the config file seems to matter if you're using an older version of the CLI tool. I had to move the `[security]` section above my `[plugins.my_agent]` section, or it wouldn't parse correctly. Might just be a quirk in the dev branch, but worth checking if things act weird.
So for your example, you'd just add it to the list and that should be it. Have you run into any issues with plugins that have dependencies on others? I'm wondering if a plugin needs to be whitelisted if it's only called by another whitelisted plugin.