I’ve been poking around the AgentGPT workflow builder for a project, trying to see if I could make it do something remotely portable or secure. The marketing and tutorials make it seem like a magic box where you just connect blocks and get results, but the devil is, as always, in the details. Specifically, I was looking for a way to avoid hardcoding API keys and endpoint URLs directly into the workflow steps, which is a glaring security and operational red flag.
After some digging and experimentation, I discovered that you can, in a very limited and almost accidental way, use environment variables. I say "sort of" because it's not a first-class feature with a dedicated UI or any documentation I could find. It seems more like an unintended side-effect of how the underlying system parses strings. If you create a text input field in a custom tool or within a step's configuration, and you type something like `${MY_API_KEY}` or `$MY_API_KEY`, the system will sometimes pass that raw string through to the execution context. The catch is that it only works if the runtime environment where the agent actually executes (their cloud, your self-hosted instance, etc.) has those variables defined. In the standard hosted AgentGPT service, this is essentially useless for secrets, as you don't have access to their runtime environment.
This leads to a much bigger conversation about vendor lock-in and total cost of ownership. What they’re selling is convenience, but the cost is control. You build these intricate workflows tied to their specific execution model and UI. The moment you need a real security practice like secret management, or you want to run the same workflow logic in a different environment for redundancy or cost-saving, you hit a wall. You’re forced to either accept the risk of hardcoded credentials or beg for a feature that should be foundational. It’s a classic trap: easy to start, painful to scale, and expensive to leave. I’d be curious if anyone has tried to reverse-engineer the workflow export to inject environment variables post-export, or if you’re just accepting that your automation logic is permanently tethered to their platform’s security posture.
Just my two cents
Skeptic by default
That "sort of" feature is a perfect example of why these visual workflow builders are a trap. They create the illusion of simplicity while baking your secrets into the workflow definition itself. Even if the `${VAR}` string gets passed through, you're still one copy-paste away from committing it to a repo.
The real problem is the execution context being a mystery. If it works on their cloud but not your self-hosted runner, you've just built a workflow that's completely non-portable and breaks the second you try to own your own infrastructure.
null