Runtime Vault
Give bots controlled access to secrets with policies, short-lived leases, and audit logs.
Runtime Vault stores values that bots may need during execution: service tokens, MCP server credentials, repository credentials, customer-specific API keys, or configuration that should not live in a bot workspace.
Use provider credentials for Botyard-managed provider calls. Use Runtime Vault when the bot or an MCP server needs an application secret at runtime.
Create a Runtime Vault variable
- Sign in to app.botyard.io.
- Open Credentials.
- Select the Runtime Vault tab.
- Click Add variable.
- Enter a dot-delimited key path, display name, value, max TTL, sensitivity, and bot access policy.
The key path is the stable reference bots and MCP templates use, for example
github.tokens.read_only or mcp.snowflake.client_id.
Policy controls
Each Runtime Vault variable has a policy:
| Setting | What it controls |
|---|---|
| Key path | The stable name used by bots, leases, and MCP secret references. |
| Max TTL | The maximum lifetime of a plaintext access grant. |
| Sensitive value | Whether the exfiltration scanner should check outbound requests for this value. |
| Allow all bots | Whether every bot in the org can request the value. |
| Linked bots | The explicit allowlist when Allow all bots is off. |
Secrets are encrypted with the same per-organization age/X25519 storage model used for provider credentials. Plaintext values are not returned by the API after creation or update.
How bots obtain secrets
Runtime Vault uses short-lived leases:
- A bot requests a lease for a key path and provides a justification.
- Botyard checks the secret policy for that bot.
- If allowed, Botyard creates a lease with a bounded TTL and maximum redemption count.
- The bot receives an opaque secret reference, not the plaintext value.
- The runtime redeems the lease when the value is actually needed.
- Redemption decrypts the value, records the access, and marks one redemption as used.
This separates authorization from plaintext delivery. A bot cannot mint a lease for another bot's unshared secret, and an expired or already-used lease cannot be redeemed again.
MCP server secret references
MCP setup templates can reference Runtime Vault key paths through env_secret_refs.
For example:
{
"env_secret_refs": {
"SNOWFLAKE_CLIENT_ID": "mcp.snowflake.client_id"
}
}When an MCP server is provisioned, Botyard resolves the key path through the secrets service instead of storing the plaintext in the MCP template. That lets an organization rotate the vault value without editing every template that references it.
Use env_secret_refs for durable MCP credentials. Use pasted plaintext only for non-sensitive
or one-off setup values.
Safety pattern
Runtime Vault follows a brokered secret access pattern with just-in-time leases:
- the policy decides which bots may request a secret
- the lease limits how long a grant is useful
- redemption limits how often it can be used
- audit events record request, grant, denial, redemption, and expiry
- sensitive values are included in exfiltration scanning
This gives bots access to credentials without making the workspace a permanent secret store.