Migrating from Doppler to Naive

• Secrets live behind a service token (dp.st.<config>...) scoped to one config — a single shared bucket, not per-end-user. To isolate secrets per customer you build the mapping yourself (one config per user, naming conventions, or your own KV on top).
• Every secret in a config is readable by any code holding the token. There is no write-only secret — nothing an agent can use but never read back.
• “Which of this agent’s secrets belong to which end-user, and who let it read them?” is answered in Doppler for secrets, and in unrelated systems for the agent’s cards, email, and KYC. The identity that owns the secret is a config, not the end-user the agent serves.

• The tenant user whose vault holds a secret is the same user that owns its cards, its email inboxes, its phone number, and its KYC.
• Each value is envelope-encrypted with a managed KMS under an encryption context bound to { company_id, tenant_user_id }, so sibling tenants should not be able to read each other’s secrets — you never build the per-user isolation.
• Entries can be locked (stored but never revealed), expiring (expires_at), and whether the agent may touch the vault at all is decided by that user’s Account Kit at execution time.

​

Concept map

​

Before / after: the core path

import { DopplerSDK } from "@dopplerhq/node-sdk";

// One config behind a service token — a shared bucket, not per end-user.
const doppler = new DopplerSDK({ accessToken: process.env.DOPPLER_TOKEN! });

const PROJECT = "agent";
const CONFIG = "prd";

// 1. Store a secret the agent generated (POST /v3/configs/config/secrets)
await doppler.secrets.update({
  project: PROJECT,
  config: CONFIG,
  secrets: { INSTANTLY_API_KEY: "key_xyz" },
});

// 2. Read it back when calling the downstream service
//    (GET /v3/configs/config/secret) → { name, value: { raw, computed, note } }
const res = await doppler.secrets.get(PROJECT, CONFIG, "INSTANTLY_API_KEY");
const apiKey = res.value.computed;

// To isolate per end-user you build it yourself: a config per user,
// naming conventions, or your own KV on top of Doppler.

import { Naive } from "@usenaive-sdk/server";

const naive = new Naive({ apiKey: process.env.NAIVE_API_KEY! });
const client = naive.forUser("alice"); // same id space as your own users

// 1. Store a secret the agent generated (PUT /v1/users/alice/vault/:key)
await client.vault.put("instantly.api_key", "key_xyz", { kind: "api_key" });

// 2. Read it back when calling the downstream service
//    (POST /v1/users/alice/vault/:key/reveal — secret in body, never a URL)
const { value } = await client.vault.reveal("instantly.api_key");
const apiKey = value;

// Per-user isolation is built in: this entry is envelope-encrypted under
// { company_id, tenant_user_id } — sibling tenants should not be able to read it.

• The scope is an identity, not a config. In Doppler the token scopes a config; to serve many users you build the per-user split. In Naive forUser(id) is the split — one line, isolated end to end, and the same handle owns the user’s cards, email, phone, and KYC.
• reveal is a POST. Naive returns the secret in the response body, never in a URL — so it can’t land in a proxy log or browser history.
• kind classifies the entry. api_key, password, cookie, token, reference, or note (default). It’s a label for the dashboard/logs, not a behavior change.
• Values come back masked in list. vault.list() returns keys with •••••••• placeholders and omits expired entries; only reveal decrypts.

​

Minimal viable migration

npm install @usenaive-sdk/server

​

Consolidate further once you’re on Naive

// One config per token; to go multi-user you build the split yourself.
const doppler = new DopplerSDK({ accessToken: process.env.DOPPLER_TOKEN! });
await doppler.secrets.update({
  project: "agent", config: "prd",
  secrets: { INSTANTLY_API_KEY: "key_xyz" },
});

// The card, the email inbox, the phone number, the KYC for this customer's
// agent live in entirely separate systems with their own tenancy — and every
// secret in the config is readable by anything holding the token.

// One tenant user per customer; isolates *every* primitive.
const acme = await naive.users.create({
  external_id: dbCustomer.id,
  email: dbCustomer.email,
});

const client = naive.forUser(acme.id);

// A write-only credential the agent can USE but never READ back.
await client.vault.put("stripe.restricted_key", "rk_live_xyz", {
  kind: "api_key",
  locked: true,
});

// A short-lived session cookie that self-expires.
await client.vault.put("portal.session", "sess_abc", {
  kind: "cookie",
  expiresAt: new Date(Date.now() + 3_600_000).toISOString(),
});

// The SAME client owns this customer's card, email inbox, phone, and KYC —
// one identity, isolated end to end, every capability governed by its Account Kit.
await client.cards.create({ spending_limit_cents: 25_000 });
await client.email.createInbox({ local_part: "ops" });

​

Gain #1 — one identity across primitives

• With Doppler, the agent’s secrets are an island behind a config token. With Naive, naive.forUser(acme.id) is a single handle to vault and cards and email and phone and KYC.
• Each value is envelope-encrypted with a managed KMS under an encryption context bound to { company_id, tenant_user_id } — sibling tenants cannot read each other’s secrets, cards, or inboxes, and you never wrote the isolation.
• Third-party connections (OAuth grants) surface alongside vault entries in one per-user credential view — the SaaS keys the agent generated and the OAuth apps it connected, one identity.

​

Gain #2 — execution-time permission enforcement

• Whether an agent may touch the vault at all is the vault primitive on the user’s Account Kit, decided at execution time — not a token scope you manage separately.

// This tier's agents get email + cards, but no vault access at all.
const kit = await naive.accountKits.create({
  name: "No-secrets tier",
  primitives_config: {
    email: { enabled: true },
    cards: { enabled: true },
    vault: { enabled: false }, // vault calls are refused with `forbidden`
  },
});
await naive.accountKits.assignUser(kit.id, acme.id);

• The agent’s code is identical for every tier — client.vault.reveal("instantly.api_key"). Whether it runs is decided by policy: a user whose Account Kit does not enable vault is refused with forbidden, with no code change on your side.
• Two enforcement levers Doppler has no equivalent for:
  • locked entries — stored and used indirectly, but reveal is typically refused (forbidden per the vault API). A leaked agent process still should not be able to read the raw value back out.
  • expires_at — an entry drops out of list and reveal typically returns not found once expired, reducing replay of stale session cookies or short-lived tokens.

​

Gain #3 — unified accountability

• Every put, reveal, and rotate for a customer lands in one per-user activity log — alongside their card, email, phone, and KYC events, not in a separate Doppler activity feed:

const { events } = await naive.forUser(acme.id).logs.query({ limit: 50 });
// "what did this agent do, for whom?" — vault reveals, card spend, email sends, one timeline

• That is the question that is hard to answer when secrets live in Doppler, cards live in Stripe, and the inbox lives somewhere else. Under Naive it is a single query.

​

What does not map yet

​

Where to go next

• vault primitive — full put/reveal/list/delete/rotate lifecycle, kind, locked, expires_at
• vault SDK sub-client — typed method signatures
• vault CLI — naive vault put/reveal/list per user
• Vault encryption — envelope encryption, KMS, and the { company_id, tenant_user_id } context
• Account Kits — enabling/disabling the vault primitive per user at execution time
• Tenant users — the identity that owns the vault, cards, email, and phone
• Connections — OAuth grants that surface alongside vault entries in one per-user credential view