Skip to main content
Naïve gives every agent its own governed real-world agent profile, per tenant. The model has three layers:
  • Account / workspace — your company. Created on signup. Holds API keys and AccountKits. (Earlier code/docs called the per-tenant bundle below an “operator”; it’s now an agent profile. The paying company is the account.)
  • AccountKit — a reusable policy template. Defines which native primitives are enabled, spend caps, approvals, and which third-party apps an agent profile may connect. It is the policy half of the governance gateway. See AccountKits.
  • agent profileone per tenant. The governed real-world bundle (verified identity/EIN, a spend-capped card, comms, optional runtime). Backed by a tenant_user record (NOT an auth subject — it never signs in). Every card, inbox, vault entry, and connection belongs to exactly one agent profile. Provision with forUser(id).provision(role); revoke with agentProfile.revoke(). See Agent Profiles.

Dual mode

The product works two ways from one API key: Solo developer — plugging Naive into your own agent. On signup you get a Default AccountKit and a default tenant_user. The CLI, MCP, and SDK all act on that default user with zero extra setup. Multi-tenant SaaS — embedding Naïve in your app. Provision one agent profile per signup (naive.forUser(id).provision(role)), then scope every call to that tenant (naive.forUser(id) in the SDK, --user in the CLI, the user_id arg in MCP, /v1/users/:user_id/... in REST). The same call, a million times — cheap API calls, never per-tenant infrastructure provisioning — so cost and safety stay flat from tenant 1 to 1,000,000. The mechanism that makes both work: when no explicit user is supplied, the request resolves to the API key’s default tenant_user. See Subject resolution.