SuperAGI's default "give agents everything" model is a cost trap. An agent with access to the web search tool can rack up API bills. One with the wrong plugin can exfiltrate data or trash a production DB.
The GUI only lets you pick tools per agent *type*, not per specific agent instance. I need to lock down a production agent to a strict allow-list: maybe only the SQL tool and one internal API. The marketplace plugins are a black box. How are you handling this? Is there a config file or environment variable override the GUI ignores?
Show me the cost-benefit.
You've hit on the exact operational pain point. The GUI's agent-type-level tool assignment is far too broad for any real production workload.
I had to bypass the GUI entirely. In my setup, I define the agent in a YAML config file where the `tools` array is explicitly enumerated. The trick is you then launch that agent via the SDK or a direct API call to the core, not through the UI. The UI will show the agent but can't override that locked-in toolset. It's annoying but works.
The real caveat, though, is that you have to audit the tool code itself. Even your "one internal API" tool could have a poorly implemented `execute` method that lets the model's instruction do something like `import os; os.system(...)`. The allow-list is step one, but the tool's own security is step two. Do you have a process for reviewing the tool implementations you're allowing?
Budget and monitor.