> For the complete documentation index, see [llms.txt](https://docs.kickbot.com/dashboard/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.kickbot.com/dashboard/api/permissions-and-security.md).

# Permissions and security

How KickBot API keys and connected apps get their permissions, what they can never do, how changes are logged, and the OAuth details for app developers.

## What a key or app can do

A key or connected app acts as one team member on one channel:

* It has that member's current dashboard permissions. If the owner changes them in **Manage Team**, the key or app changes at once.
* Team members other than the owner need the **API & MCP access** permission.
* A **read-only** key or connection can only read.

No key or app can send chat messages directly, see or change billing, payouts, or Stripe setup, manage your team, or use admin features.

## Activity log

Every change made through the API or MCP is logged with the time, the key or app name, the action, and the result. Owners and admins see all activity on the channel in **API & MCP** in the dashboard sidebar. Team members see their own.

## Good practice

* Give each script or agent its own key, so you can revoke one without breaking the others.
* Use read-only keys where you can.
* Set an expiry on keys you only need for a while.
* Revoke keys and disconnect apps you no longer use.

## For app developers: OAuth details

KickBot is an OAuth 2.1 authorization server for MCP clients.

|                               |                                                                       |
| ----------------------------- | --------------------------------------------------------------------- |
| Protected resource metadata   | `https://kickbot.com/.well-known/oauth-protected-resource/api/v1/mcp` |
| Authorization server metadata | `https://kickbot.com/.well-known/oauth-authorization-server`          |
| Authorization endpoint        | `https://kickbot.com/oauth/authorize`                                 |
| Token endpoint                | `https://kickbot.com/api/oauth/token`                                 |
| Dynamic client registration   | `https://kickbot.com/api/oauth/register`                              |
| Revocation                    | `https://kickbot.com/api/oauth/revoke`                                |
| Scopes                        | `read`, `write` (request `read write` for full access)                |

* Authorization code flow with PKCE (`S256`) only.
* Public clients (no secret) are the default. Confidential clients can register with `client_secret_post` or `client_secret_basic`.
* Client ID metadata documents are supported for known MCP clients (for example Claude, ChatGPT, Grok, VS Code and Cursor): the `client_id` is an `https` URL on the client's own site that serves its metadata. Other clients use dynamic client registration.
* Access tokens last one hour. Refresh tokens rotate on every use and last 60 days. Reusing an old refresh token revokes the connection.
* Requests without a valid token get HTTP 401 with a `WWW-Authenticate` header that points to the protected resource metadata.

## Contact

Report a security issue to <support@kickbot.com>. For other questions, use the `#support` channel on [Discord](https://discord.gg/MAg3gBbc89).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.kickbot.com/dashboard/api/permissions-and-security.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.