How credentials work on Digitorn: connect once, use everywhere

Every agent that calls a model or a tool needs a secret somewhere: an API key, an OAuth token, a service credential. The wrong way to handle that is to paste the key into the agent itself, where it ends up in a bundle, a log, or someone's git history. Digitorn's credential vault exists so you never do that. You connect a key once, use it by name from any agent, and the runtime resolves it, encrypted, per user, at the moment a session opens.

#Connect once, use by name

An agent never holds a key. It holds a name. You connect the real key in Settings, and the agent references it by that name. The plaintext value is stored encrypted server-side and injected onto the live provider client only when a session opens for the person who owns it. It never enters the agent's bundle, a log line, or your shell history.

That one indirection is the whole design. It means the same agent can run for ten different people, each on their own key, with nothing in the agent changing.

#The four scopes

A scope answers two questions at once: who can see this credential, and when does the runtime resolve it. Two are baked into the deployed agent at deploy time and shared; two are looked up fresh per session so each person brings their own key.

Per-user is the right default for almost everything. Each person brings their own key, the agent stays the same, and removing someone from your team revokes their access to every agent at once. System-wide is for a shared internal service credential and needs admin rights to set. Per-app-shared and per-app-per-user cover the niche cases in between, where one agent needs a key the others should not see.

If you're setting up your first agent and you're unsure, pick per-user and move on. The other scopes exist for when you actually need them.

#Where the plaintext lives

Your agent has a name, not a key. The value is stored encrypted, resolved only when the runtime is opening a session for the person who owns it, and injected directly onto the live provider client for that session. It never gets written into an installed agent, a log line, or your history.

#Setting one up

Two steps, both in the browser.

1. Connect the credential. In Settings, open Credentials, pick the provider, paste the key, and give it a name. That name is what your agents will use. If you skip naming it, it defaults to the provider name. One credential per provider works for most setups; use distinct names when you want several keys for the same provider (one for prod, one for dev). User-connected credentials default to per-user scope.

2. Use it in an agent. In Studio, pick the credential from the model or connector picker. Done. The first message you send opens a session, the runtime looks up your credential, and the call goes out with your key. No restart, no key visible anywhere.

#Sharing credentials across agents

Two agents can use the same credential by name. No copy-paste, no second entry. This is the day-to-day pattern: connect one Anthropic key, and your coding agent, your research agent, and your knowledge-base agent all use it. Rotate once, and it propagates everywhere.

#Rotation, the part that matters

Update the value in Settings. Per-user and per-app-per-user pick up the new value on the next session automatically. Deploy-time scopes (system-wide, per-app-shared) need a redeploy of the apps that bake them in, which is deliberate: a system-wide credential is meant to be stable across sessions, so rotating it is a visible event rather than a silent swap.

#When you're self-hosting and iterating fast

If you run Digitorn on your own machine and you're moving quickly on a new provider, there's a lightweight escape hatch: point the agent at a local environment variable instead of a connected credential. You lose per-user scoping, but you keep the "edit a local file and go" simplicity. We use this ourselves on dev machines for providers we're still integrating, and we always switch to a connected credential before shipping.

#Further reading

• The full architecture of a coding agent that uses this pattern: How to build your own Claude Code
• Cost-routing patterns that pair naturally with per-agent credentials: How we cut our coding agent's bill by 60%
• Ten more patterns, ready to open in Studio: /templates