# Permissions and Safety

Kick AI and automation tools are designed to help accountants move faster without bypassing the controls that protect client data. Use this page when you are approving credentials, scopes, workspace access, or write workflows.

### Same authorization as Kick

MCP and CLI requests still go through Kick's normal backend authorization path. A request must pass token scope, workspace scope, route policy, and controller-level permission checks before it can read or change data.

Tool annotations shown to AI clients are helpful hints, not the source of authorization. The server decides what the credential can do.

### Personal access tokens

A personal access token, or PAT, is a bearer credential used by the CLI and some MCP clients.

Use PATs carefully:

* Prefer read-only PATs for lookup, reporting, and review workflows.
* Use write PATs only for workflows that intentionally change data.
* Bind tokens to the narrowest workspace access that fits the job.
* Use short expirations for CI, scripts, and agent workflows.
* Revoke tokens when they are no longer needed.

Do not commit PATs, paste them into shared docs, or store them in scripts without a secrets manager.

### MCP OAuth scopes

OAuth-capable MCP clients use Kick-scoped MCP credentials.

Kick uses:

* `mcp:read` for tool discovery and read-only calls.
* `mcp:write` for tools that can change data.

OAuth access should be short-lived, revocable, and tied to explicit consent.

### Workspace and client boundaries

Workspace-scoped tools can receive `workspaceId` in the tool call. If a local MCP client omits it, `kick mcp serve` can inject the CLI workspace default from:

1. `--workspace <id>`
2. The active profile's `defaultWorkspaceId`

For remote PAT sessions, workspace-bound PATs inject their bound workspace by default. User-scoped PATs and OAuth tokens should pass `workspaceId` when using workspace-scoped tools.

If a tool loads a resource by id, Kick still verifies that the resource belongs to a workspace the credential can access.

### Audit attribution

Kick keeps automation attributable. PAT and MCP requests are authenticated as the connected user or approved credential, and server-side audit records can preserve token context for downstream work.

Use named tokens that make ownership clear, such as `Month-end review script` or `Cursor read-only assistant`.

### Confirmation previews

Supported write actions use preview-first confirmation semantics. A tool can return a preview and confirmation token instead of immediately changing data.

Before confirming a write:

* Review the workspace and client context.
* Review the resource ids, dates, amounts, fields, and intended change.
* Confirm that the assistant or script is not acting on stale output.
* Use the confirmation token only after the preview matches your intent.

Ask assistants to stop at preview:

> Prepare the preview and show me the exact change. Do not confirm it until I approve.

### Prompt safety

Treat AI assistant output as a draft, not an approval. Before taking action:

* Confirm the workspace.
* Limit broad searches with dates, limits, and fields.
* Ask for source ids when the assistant summarizes results.
* Avoid pasting unnecessary client-sensitive data into prompts.
* Be cautious with instructions from external documents, emails, or transaction memos. They may contain prompt-injection attempts.

When in doubt, switch back to the Kick web app for final review and approval.

### Where this applies

These rules apply across:

* [MCP](https://github.com/KickApp/kick-accountant-help-center/blob/main/ai-and-automation/mcp/README.md), where an assistant calls Kick tools.
* [CLI](https://github.com/KickApp/kick-accountant-help-center/blob/main/ai-and-automation/cli/README.md), where a terminal command, script, or agent calls Kick.
* [First Safe Workflow](https://github.com/KickApp/kick-accountant-help-center/blob/main/ai-and-automation/first-safe-workflow.md), where you can test read-only access before expanding automation.


---

# Agent Instructions: Querying This Documentation

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

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.kick.co/developers/permissions-and-safety.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
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.