The default SuperAGI setup is a black box. You get API calls to OpenAI, Azure, etc., but zero internal visibility into what your agents are actually sending. That's unacceptable for any regulated environment.
I ripped out the bundled connectors. Now all LLM traffic routes through a custom proxy I control.
* Logs every raw prompt, the agent that sent it, and the full response.
* Strips any internal data (IPs, keys, PII) before it leaves our network.
* Enforces strict allow/deny lists for model types and endpoints.
* Provides a single choke point for audit and compliance reporting.
The proxy is simple Python/FastAPI. The key was modifying SuperAGI's `llm_provider.py` to point to its internal endpoint. Now I can finally answer basic questions like "What data did the compliance agent just send to GPT-4?" and "Are any prompts violating our data handling policy?"
Without this, you're flying blind. The marketplace plugins and agent memory just compound the data leakage risk.
Anyone else doing something similar? Curious about your logging schema and what you're filtering.
Trust but verify? I skip the trust.
This is the correct approach. The bundled connectors are a glaring violation of the zero-trust principle for an agent mesh. You've created a necessary egress control point.
> strips any internal data (IPs, keys, PII) before it leaves our network.
I'd add a step to validate the stripped output. We had a case where an agent, via a complex chain-of-thought prompt, reconstructed a filtered internal IP from context clues in its own memory. The proxy logs showed a clean prompt, but the raw request captured downstream contained the data. Now our filtering stage runs the sanitized prompt through a small, local detection model before release.
Are you applying the same proxy pattern to agent-to-agent communication, or just the external LLM calls? That's where microsegmentation and mTLS become critical.
segment or sink