Migrating from Composio to Naive

• Tool connections live behind their own API key, dashboard, and user_id (entity) namespace.
• That user_id scopes connected accounts and nothing else — it knows the agent’s Slack and GitHub grants, but not its virtual card, its inbox, its vault secrets, or its KYC status.
• “Who let this agent post to Slack, and what else can it touch?” is answered in Composio for tools, and somewhere else for everything else. There is no shared accountability.

• The tenant user that holds the connections is the same user that owns its cards, its email inbox, its vault secrets, and its KYC.
• What the agent is allowed to connect and execute is decided by that user’s Account Kit at execution time — not by which tools you remembered to pass into the model.
• Every connect and execute lands in the same per-user activity log as everything else the agent does.

​

Concept map

​

Before / after: the core path

import { Composio } from "@composio/core";

const composio = new Composio({ apiKey: process.env.COMPOSIO_API_KEY! });

// 1. You first create an auth config for the toolkit (dashboard or SDK) → ac_...
const authConfig = await composio.authConfigs.create("github", {
  name: "GitHub",
  type: "use_composio_managed_auth",
});

// 2. Start a hosted connect flow for this user, send them to redirectUrl
const conn = await composio.connectedAccounts.link("user_123", authConfig.id, {
  callbackUrl: "https://app.example.com/oauth/callback",
});
// → send the user to conn.redirectUrl; conn.waitForConnection() resolves when ACTIVE

// 3. Execute a tool once the account is connected
const res = await composio.tools.execute("GITHUB_CREATE_ISSUE", {
  userId: "user_123",
  arguments: { owner: "acme", repo: "agent", title: "Ping", body: "from the agent" },
});
// res.successful, res.data

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

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

// 1. No separate auth-config step — connect the toolkit directly by slug
const conn = await client.connections.connect("github", {
  callbackUrl: "https://app.example.com/oauth/callback",
});
// → send the user to conn.redirectUrl; status becomes ACTIVE after they finish

// 2. (optional) confirm it's connected from the local mirror
const connected = await client.connections.connected();

// 3. Execute a tool — toolkit slug + tool slug + arguments
const res = await client.connections.execute("github", "GITHUB_CREATE_ISSUE", {
  owner: "acme",
  repo: "agent",
  title: "Ping",
  body: "from the agent",
});
// Typical shape: { successful, error?, data? } — verify against your SDK version

• No auth-config resource. Composio makes you create an auth config (ac_…) per toolkit before linking. Naive connects by toolkit slug directly using managed auth — there is no intermediate object to create or track. White-label OAuth (your own client id/secret) is set on the Account Kit (connections_config.custom_auth_configs), not as a standalone resource.
• Arguments are the last positional arg. Composio takes { userId, arguments }; Naive’s scoped client already knows the user, so execute(toolkit, tool, args) passes the tool’s arguments directly.
• The user id is your identity, not a separate entity. In Composio user_id is an entity that exists only for tool auth. In Naive the same id is a tenant user that also owns the agent’s cards, inbox, vault, and KYC.

​

Connecting an app (OAuth)

const conn = await composio.connectedAccounts.link("user_123", "ac_github", {
  callbackUrl: "https://app.example.com/oauth/callback",
});
console.log(conn.redirectUrl);          // send the user here
await conn.waitForConnection();         // resolves when ACTIVE

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

const conn = await client.connections.connect("github", {
  callbackUrl: "https://app.example.com/oauth/callback",
});

// `connect` returns ConnectResult | PendingApproval. Only the first has a URL.
if (isPendingApproval(conn)) {
  console.log("waiting on a human:", conn.approval_id);
} else {
  console.log(conn.redirectUrl);        // send the user here
  // poll the mirror until ACTIVE (or drive it from a webhook)
  const connected = await client.connections.connected();
}

• On Naive, connecting a service is a sensitive action and may be approval-gated by the Account Kit — connect can return pending_approval (202) until a human approves.
• INITIATED rows older than ~10s are reconciled from the provider before responding. See Connection status.

​

Minimal viable migration

npm install @usenaive-sdk/server

​

Consolidate further once you’re on Naive

// One entity per customer; isolates connected accounts, and only those.
const userId = "customer-acme";
await composio.connectedAccounts.link(userId, "ac_github", { callbackUrl });
await composio.tools.execute("GITHUB_CREATE_ISSUE", { userId, arguments: {/* … */} });

// The card, the inbox, the secrets, the KYC for this customer's agent
// live in entirely separate systems with their own tenancy.

// 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);

await client.connections.connect("github", { callbackUrl });
await client.connections.execute("github", "GITHUB_CREATE_ISSUE", {/* … */});

// The SAME client owns this customer's card, inbox, secrets, and KYC —
// one identity, isolated end to end.
await client.cards.create({ name: "Ops", spending_limit_cents: 25_000, provider: "managed_virtual" });
const inbox = await client.email.createInbox({ local_part: "notifications" });
await client.vault.put("internal.api_key", "key_xyz");

​

Gain #1 — one identity across primitives

• With Composio, the agent’s connections are an island. With Naive, naive.forUser(acme.id) is a single handle to connections and cards and email and vault and KYC.
• You provision a customer’s whole agent footprint from one identity, and tear it down from one place. Sibling tenants can never read each other’s connections, cards, or secrets.

​

Gain #2 — execution-time permission enforcement

• Which apps an agent may connect, and which tools it may run, is policy on the Account Kit — not a check you hand-write, and not just “which tools you passed to the model.”

const starter = await naive.accountKits.create({
  name: "Starter",
  connections_config: {
    mode: "allowlist",
    toolkits: ["github", "slack"],               // only these apps are connectable
    tools: { github: { enable: ["GITHUB_CREATE_ISSUE"] } }, // and only this tool on GitHub
    approvalToolkits: ["slack"],                  // posting to Slack freezes for human approval
  },
});
await naive.accountKits.assignUser(starter.id, acme.id);

• The agent’s code is identical for every tier — client.connections.execute("github", …). Whether the call runs is decided by the caller’s kit at execution time:
  • A blocklist/allowlist mode governs which toolkits connect at all.
  • Per-tool enable/disable filters lock execution down to specific tools.
  • approvalToolkits (or requiresApproval) freezes a sensitive call until a human approves — the API replays it only after approval.
• Move the user to a kit that drops github and the exact same line returns forbidden, with no code change on your side. Composio gates auth (which accounts exist); Naive additionally gates execution per user.

​

Gain #3 — unified accountability

• Every connect, execute, and disconnect for a customer lands in one per-user activity log — alongside their card, email, and vault events, not in a separate tools dashboard:

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

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

​

What does not map yet

​

Where to go next

• /connections primitive — full connect/execute lifecycle
• Connections API reference — exact request/response shapes
• connections SDK sub-client — typed method signatures
• Account Kits and Approvals — the policy model that makes execution-time tool governance real
• Tenant users — the identity that the consolidation hangs off

​

Related reading (blog)

• Why consolidate agent infra on one governed identity — migration thesis behind this guide
• Building AI Agents Into Your SaaS — tenant user anchor for every migration
• How To Build An Agentic Access Governance Platform — connections + Account Kit tutorial