Workspace Secrets
Store API keys and tokens once, then reference them from tools without exposing the value
Overview
A secret is a named credential stored at the workspace level — an API key, a bearer token, a signing value. Tools reference the secret by name instead of containing the value.
The reason to use one is straightforward. A webhook tool needs to authenticate against your API. If you paste the key directly into the tool's header, then every teammate who can open that tool can read your production key, and it sits in the tool's configuration indefinitely. Referencing a secret keeps the value out of that surface entirely.
Creating a secret
- Go to Settings → Secrets.
- Add a secret with a name and its value.
- Save.
The name is what you pick from tool configuration later, so make it descriptive of both the service and the environment — stripe_live_key beats key1. When a call fails six months from now, the name is the only clue you will have.
You can reveal the value while typing it to check for paste errors. After saving, treat it as write-only: to change a credential, replace the secret rather than expecting to read the old value back.
Using a secret in a tool
Secrets are consumed by webhook tools. When you add a request header, choose the Secret header type and pick the secret by name.
urvo substitutes the value when it makes the request. The credential is never sent to the language model and never appears in the transcript, so it cannot leak into a conversation the caller can hear or into a recording.
Deletion and dependencies
A secret that is in use cannot be deleted. Remove it from every tool that references it first, otherwise you would silently break those tools' authentication and only find out on the next live call.
Rotating a credential follows the same logic: update the secret's value in place so every tool referencing it picks up the new value at once, rather than creating a second secret and editing tools one at a time.
Good practice
- One secret per credential per environment. Separate staging from production so a test tool cannot reach live data.
- Scope the credential narrowly at the source. urvo stores whatever you give it; if the key you paste has admin rights on your API, that is what the tool will have. Issue a key limited to what the agent actually needs.
- Rotate on team changes. Workspace members with access to tool configuration can use a secret even without reading it, so rotate credentials when someone leaves.
- Prefer secrets over constant header values for anything sensitive, even short-lived tokens.
Next steps
- Webhook tools — where secrets are used.
- Integrations — connected services manage their own credentials and do not need secrets.
- Invite members — who can see workspace settings.