Local vs Hybrid vs Cloud

Bissap has 3 key management modes. The difference is where keys are stored and validated, not how they're created.

In all three modes, keys are minted the same way: your app calls POST /bissap/keys (via the SDK). The user authenticates in your app, your app mints a key, the user gives it to their agent. The app owner picks the mode.

Local (fastest)

• Storage + validation: your app (memory or storage adapter)
• Dashboard: does not show keys
• Great for demos, self-hosters, and "I want zero dependencies."

What your users will experience

"Connect your agent" → your app generates a key → show it once → user pastes it into their agent.

If they lose it: generate a new one. (This is your app's version of "we don't do password recovery.")

Revoking happens via your app UI (profile/settings), because only your app knows the local key list.

Hybrid (recommended)

• Storage + validation: your app cache + Bissap Cloud (local first, cloud fallback)
• Dashboard: shows keys + revocations
• Best UX and you get a Cloud-backed kill switch.

What your users will experience

Same flow as Local:

"Connect your agent" → key is shown once → paste into agent.

But now you (the builder) can see + revoke keys in the dashboard, and revocation stays enforced even if your app restarts.

Cloud

• Storage + validation: Bissap Cloud only
• Dashboard: the source of truth
• Useful when you want ops/support control (or you're managing access like a grown-up… reluctantly).

Security footgun prevention: key minting + validation always happen on the server. Never put secrets or minting endpoints in the browser/mobile client.

What your users will experience

Same flow as the other modes:

"Connect your agent" → your app mints a key via the SDK → show it once → user pastes it into their agent.

The difference is that your app doesn't store the key. Cloud does. You (the builder) get full visibility and control in the dashboard.

If you're unsure: start Hybrid.

Important: use strictIntents: true

Regardless of mode, always set strictIntents: true in production. This ensures:

• Only registered intents can be called (unknown names → 404)
• Intent discovery only shows what you've explicitly defined
• No fallthrough to onAgentIntent catch-all handlers

Without it, an agent could potentially call intent names that bypass your registry and hit a generic handler, which may expose more than intended.

See: Intent Hygiene for guidance on choosing which intents to register.