Permissions and Security

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.

{% hint style="warning" %} Kick MCP is read-only by default, with explicit confirmation required before any changes. {% endhint %}

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. Workspace-bound PATs auto-inject their bound workspace. The backend injects a default workspaceId only when the credential resolves to exactly one workspace. 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 securely

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.