Secrets & egress

Company and Teammate secrets

You can store secrets at two scopes: company-wide (available to every Teammate on your account) and per-Teammate (specific to one). Both are fully customer-editable — you set the key name and value, and can update or delete them at any time.

Naming your keys

A secret key name must start with an uppercase letter, followed by any mix of uppercase letters, digits, underscores, or hyphens — the same shape as an environment variable, like MY_SERVICE_API_KEY. Names that don't match are rejected before they're ever written.

Note: Some key names are reserved by the platform — saving one returns a validation error rather than overwriting anything. Enterprise plans that bring their own provider credentials are the one exception to this; see Model configuration.

The trust architecture: placeholders, not keys

Your Teammate never sees the raw value of a secret you store for it. It only ever holds a placeholder. When the Teammate makes a request to the specific host that key is bound to, the real value is substituted in transit — the Teammate itself can use the key without ever being able to read it.

This is the same structural principle behind the platform's broader security posture: keys are useful to the Teammate, but never legible to it, so a compromised or manipulated Teammate has nothing worth exfiltrating.

Host allowlists for your own integrations

Beyond the secrets the platform wires up for you (model providers, messaging channels), you can register your own secrets for integrations you build yourself — and each one needs a host allowlist telling the platform which destination(s) that key is allowed to travel to. You can set this per Teammate or company-wide, so a shared credential can be scoped to the one service it's meant for.

Warning: If a request goes to a host that isn't on that key's allowlist, the platform does not fill in the real value — the literal placeholder ships instead, and the destination almost always rejects it (a 401 or an "invalid credential" style error naming the placeholder). If your own integration is failing with an auth error like that, check the host allowlist for the secret it's using first — it's the most common cause.

Secret changes require a full deploy

Adding, editing, or deleting a secret — including egress allowlist entries — stages as a pending change and always classifies as a full agent-server refresh on deploy, never a quick reload. Secrets are only re-read from storage when a server boots. See Deploys & pending changes for the full hot-reload vs. refresh breakdown.

API and MCP

Company secrets, Teammate secrets, and egress host allowlists all have full dashboard/API/MCP parity. See API & MCP for the resource map.