What Is an Account Kit?

TL;DR

›An Account Kit is a reusable policy template that governs what a tenant user's agents can do.
›It controls two things: which native primitives are enabled, and which third-party apps a user may connect.
›You author a few kits — Starter, Pro, Enterprise — and assign users to them instead of configuring each one.
›Kits set primitive defaults (like a card spending limit), app-filter mode (open/allowlist/blocklist), and per-tool rules.
›Kits can require human approval on sensitive actions; cards, domains, verification, formation, and connecting apps default to gated.
›The default kit on signup enables every native primitive with the app filter open.

If you've read about multi-tenant AI agents or agent permissions on Naïve, you've seen the term Account Kit. This is the short, definitional version: what an Account Kit is, what it controls, and why it exists.

What is an Account Kit?

An Account Kit is a reusable policy template that governs what a tenant user's agents can do. Rather than configuring 10,000 users one at a time, you author a few kits — say "Starter," "Pro," and "Enterprise" — and assign users to them.

It sits in the middle of Naïve's multi-tenant model: an operator (you) owns Account Kits, and each tenant user (your customer) is assigned one. The kit is the rulebook; the tenant user is who the rules apply to.

What does a kit control?

A kit controls exactly two things:

Which native primitives are enabled — cards, email, vault, social, and so on. Primitives can carry defaults, like a card spending_limit_cents.
Which third-party apps a user may connect — Gmail, Slack, Stripe, and the rest of the catalog.

Here's a "Pro" kit:

{
  "name": "Pro",
  "primitives_config": {
    "cards":  { "enabled": true, "defaults": { "spending_limit_cents": 250000 } },
    "email":  { "enabled": true },
    "vault":  { "enabled": true },
    "social": { "enabled": false }
  },
  "connections_config": {
    "mode": "allowlist",
    "toolkits": ["gmail", "slack", "stripe", "hubspot", "notion", "linear"],
    "tools": { "gmail": { "enable": ["GMAIL_FETCH_EMAILS", "GMAIL_SEND_EMAIL"] } }
  }
}

How does the app filter work?

The connections_config.mode field has three settings:

Mode	Behavior
`open`	No filter — every third-party app is available (the default).
`allowlist`	Only the listed toolkits are available.
`blocklist`	Every app except the listed ones.

Allowlist and blocklist are mutually exclusive. Within an allowed app, you can go finer still — enable or disable specific tools (allow Gmail, but only fetch and send). And custom_auth_configs lets you pin your own provider auth so the OAuth consent screen shows your brand instead of the provider's.

Can a kit require approval?

Yes. Each gated primitive accepts requiresApproval. When it's on, a sensitive agent action freezes as a pending approval (HTTP 202) until a human approves it.

The defaults are conservative: cards, domains, verification, formation, and connecting a new app default to requiring approval. Set requiresApproval: false to opt a primitive out. Human callers from the dashboard or a session are not subject to the approval gate — only agent (API-key or MCP) calls are gated (per published docs).

What's the default kit?

On signup you get a default kit with mode: "open" and every native primitive enabled — so you can build immediately without writing policy first. As you move toward a multi-tenant product, you author tighter kits and assign the right one to each tenant user.

Where it fits

An Account Kit is one piece of a larger picture: tenant users give you per-customer isolation, and Account Kits give you enforced permissions on top of that isolation. Together they're how the multi-tenant playbook keeps each customer's agent both separate and safe. For the complete field-by-field reference, see the Account Kits docs.