- 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 profile — one per tenant. The governed real-world bundle (verified
identity/EIN, a spend-capped card, comms, optional runtime). Backed by a
tenant_userrecord (NOT an auth subject — it never signs in). Every card, inbox, vault entry, and connection belongs to exactly one agent profile. Provision withforUser(id).provision(role); revoke withagentProfile.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.