> ## Documentation Index
> Fetch the complete documentation index at: https://usenaive.ai/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# AccountKits

> Policy templates that govern what a tenant user's agents can do.

An **AccountKit** is a reusable policy template. Instead of configuring 10,000 users
individually, you author a few kits ("Starter", "Pro", "Enterprise") and assign users
to them.

A kit controls two things: which native **primitives** are enabled, and which third-party
**apps** a user may connect.

```jsonc theme={"theme":"css-variables"}
{
  "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"] } },
    "custom_auth_configs": { "gmail": "ac_agent_profile_branded_gmail" }
  }
}
```

## App filter — three modes

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

`allowlist` and `blocklist` are mutually exclusive — modeled as
`toolkits: { enable }` vs `{ disable }`.

## Per-tool filter

Within an allowed toolkit, restrict to specific tools with
`tools.<toolkit>.enable` or `.disable` (mutually exclusive). E.g. allow Gmail but only
read + send.

## White-label

`custom_auth_configs.<toolkit>` pins your own provider auth config id for an app, so
the OAuth consent screen shows *your* brand instead of Naive's or the provider's.

## Governance — require approval

Each gated primitive accepts `requiresApproval`, and connections accept
`requiresApproval` / `approvalToolkits`. When on, an agent's sensitive action is
frozen as a pending [approval](/docs/architecture/approvals) (HTTP 202) until a human
approves it.

```jsonc theme={"theme":"css-variables"}
{
  "primitives_config": {
    "cards":   { "enabled": true, "requiresApproval": true },
    "domains": { "enabled": true, "requiresApproval": true },
    "social":  { "enabled": true, "requiresApproval": false }
  },
  "connections_config": {
    "mode": "open",
    "requiresApproval": false,
    "approvalToolkits": ["stripe"]   // only Stripe connects need approval
  }
}
```

`cards`, `domains`, `verification`, `formation`, and `connections.connect`
default to requiring approval; set `requiresApproval: false` to opt a primitive
out. Human (dashboard/session) callers always bypass the gate — only agent
(API-key / MCP) calls are gated.

## How it maps to the connections provider

Naive translates a kit to the provider's session config:

| Kit                   | Provider session config           |
| --------------------- | --------------------------------- |
| `mode: "open"`        | `toolkits` omitted (full catalog) |
| `mode: "allowlist"`   | `toolkits: { enable: [...] }`     |
| `mode: "blocklist"`   | `toolkits: { disable: [...] }`    |
| `tools`               | passed through unchanged          |
| `custom_auth_configs` | `authConfigs`                     |

The default kit on signup is `mode: "open"` with every native primitive enabled.