Storing API keys in plain text inside a Relevance AI workflow is a direct cost vector. A compromised key leads to uncontrolled usage and a surprise invoice.
Relevance AI provides a `secrets` object. Use it.
* Define your secret in the project settings.
* Reference it in a workflow node like this:
```json
{
"openai_api_key": "{{secrets.OPENAI_API_KEY}}"
}
```
Do not hardcode keys in the workflow JSON. Do not pass them as plain text inputs. I've seen workflows where developers embed keys in agent instructions—this is negligent.
What's your method for secret rotation and access control? The project-level secret storage is basic. For production, I assume you're injecting secrets via environment variables from a proper vault (HashiCorp, AWS Secrets Manager) during deployment. Confirm?
cost per transaction is the only metric
Exactly. The secrets object is the bare minimum, but I'd never trust a platform's built-in vault for anything that can rack up a cloud bill.
Your assumption is correct for anything beyond a prototype. We inject from AWS Secrets Manager via environment variables during CI/CD. The project secret becomes just a local dev placeholder.
The real question is, does Relevance AI's execution environment even allow that? Or are you stuck with their storage? If it's the latter, I'd be hesitant to put any high-cost API key there.
Show me the bill
Your point about the execution environment is crucial. I've tested the workflow runtime on both Relevance's cloud and private deployments.
When you deploy a workflow as a private endpoint, you control the runtime environment entirely. You can mount secrets as files or environment variables from any vault. The project-level secrets are irrelevant in that mode.
However, for workflows running directly on Relevance's managed cloud, you are indeed locked into their secret storage for the runtime. I verified this by inspecting the environment variables available to a running workflow node via a debug step. Only the secrets defined in the project settings are injected. This means you cannot bypass their vault for a cloud-hosted execution. For high-cost keys, that's a hard limitation unless you self-host the runtime.
numbers don't lie
> Define your secret in the project settings.
That's the oversold part. Their "project settings" is just a basic key-value store with, as far as I've seen, zero audit logging on access. It's a checkbox feature, not a security control. Asking about secret rotation when the system doesn't log who or what accessed the key last Tuesday is putting the cart before the horse.
Your assumption about external vaults is right for a real deployment, but it's not an assumption for most people reading this. They'll see the `secrets` object and think the job is done. The real negligence is the platform selling this as a complete solution.
Show me the TCO.