Granular Access Control
Granular access control lets every agent and every contact carry a completely different set of credentials, scoped to the context they are acting in. Rather than a single static key shared by everyone, ChatBotKit resolves the right secret at call time based on who is acting, which agent is running, and which service is being reached - so the same platform supports both company-wide tools and per-user data without compromising on either.
Because ChatBotKit identifies the contact behind a conversation regardless of where it happens, these authorization rules resolve the same way whether the user is on Slack, WhatsApp, Microsoft Teams, the web widget, or the API. You configure access once, and it follows your agents and your users across every channel.
What You Can Do
- Scope credentials per identity: Each agent and each contact can hold its own credentials, so two users talking to the same agent can act under entirely different permissions.
- Mix shared and personal secrets: Shared secrets serve everyone using an agent, while personal secrets stay private to the individual they belong to. See OAuth Secrets.
- Connect multiple accounts per service: Create a secret more than once to manage several workspaces or accounts on the same service simultaneously - for example, separate credentials per client. See MCP Secrets Management.
- Run background agents: Link a pre-authenticated secret to an agent and it operates unattended, with no one present to approve each connection.
- Isolate by sub-account: Build multi-tenant SaaS where each customer or department gets its own isolated set of credentials and access.
- Resolve consistently across channels: The same access rules apply whether a contact arrives through messaging, the widget, or your own app. See Connect and Authentication.
How It Works
When an agent needs to reach an external service, ChatBotKit selects the credential to use based on the service, the acting user's context, and the access pattern. A shared secret is used when an agent acts on behalf of the whole account; a personal secret is used automatically when the interacting contact has their own credentials linked - so an agent reaching a user's calendar or email uses that user's account, not a shared one. When an ability needs authentication and no secret is linked, the user is prompted in the moment, and nothing breaks. Every credential is encrypted at rest and in transit, every access is logged for audit, tokens refresh automatically, and revoking a secret immediately stops every agent from using it.
Getting Started
Open the Connect app to authenticate services and create secrets, marking each as shared or personal. Create a secret multiple times when you need separate accounts for the same service. Link the relevant secrets to the agents that should use them for background operation, and leave the rest to resolve from each contact's own credentials at conversation time. Everything is also manageable through the API for programmatic, multi-tenant setups.
Practical Uses
Granular access control underpins serious multi-user and multi-tenant AI: a sales team combines shared CRM access with each rep's personal calendar and email, automatically respecting both organizational and individual boundaries; a consulting firm gives each client's workspace its own isolated secret so different agents reach different accounts at once; and a DevOps team pre-authenticates shared infrastructure secrets to run unattended monitoring agents. In every case, access stays scoped to the right identity and context, consistently, no matter which channel the conversation happens on.