Skip to main content
Naive is multi-tenant infrastructure for AI agents. The model has three layers: 
Operator (company)        ← you, the developer who signed up
  └── AccountKit          ← policy template (what a user can do)
        └── tenant_user   ← YOUR end-user; every primitive is scoped to one
              └── resources (cards, inboxes, vault, connections, sessions, approvals, ...)
  • Operator — your workspace. Created on signup. Holds API keys and AccountKits.
  • AccountKit — a reusable policy template. Defines which native primitives are enabled and which third-party apps a user may connect. See AccountKits.
  • tenant_user — your customer. NOT an auth subject; it never signs in. It’s an opaque record you manage via the API/SDK/CLI. Every card, inbox, vault entry, and connection belongs to exactly one tenant_user.

​
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 Naive in your app. Call users.create() per signup, then scope every call to that user (naive.forUser(id) in the SDK, --user in the CLI, the user_id arg in MCP, /v1/users/:user_id/... in REST). 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.