Give your AI agent deploy access — not your panel password

The wrong way: pasting your panel password into an agent

Local AI agents are good at exactly the repetitive part of shipping software: run the checks, fix what they flag, deploy, read the logs, repeat. The tempting shortcut is to hand the agent your panel login so it can "do everything". Your panel account can change payment methods, delete applications and touch every CDN account you own — none of which the agent needs to ship code. The right tool is a credential that can deploy and do nothing else.

The deploy token: shown once, scoped hard

One command creates it. The plain-text token appears exactly once — cdn.com.tr stores only a hash, so nobody (including support) can read it back later. It is bound to a single CDN account and to the deploy surface only: upload source, build, create and update apps, deploy, read status and logs.

$ cdnctl deploy-token create --name "claude-code"
Deploy token (shown ONCE — save it now):
  cdnctl_T1bz••••••••••••••••••••••••

To hand it to an agent: cdnctl configure --token cdnctl_T1bz••••…
Scope: deploy only (source upload/build + app lifecycle).

What the token can and cannot do — we tested every edge

These are not design intentions; each row is a real request we ran against the live API with a freshly minted token:

- Deploy surface on its own account — works (200). - The same endpoints for another account's UUID — 404. The API does not even confirm that the other account exists. - Endpoints outside the deploy surface (billing, DNS, user profile) — 401. - DELETE on an application — 405. The route simply is not registered on the token surface, so the agent cannot destroy what it deployed. - Any request after revocation — 401, immediately.

Wiring it into Claude Code or Cursor over MCP

cdnctl ships an MCP server: `cdnctl mcp` speaks JSON-RPC over stdio and exposes six tools — project_info, check, entitlement, deploy, apps_list and app_show. Registering it means your agent calls deploy the way it calls any other tool, with structured results instead of scraped terminal text.

$ claude mcp add cdntr -- cdnctl mcp

# .cursor/mcp.json
{
  "mcpServers": {
    "cdntr": {
      "command": "cdnctl",
      "args": ["mcp"],
      "env": { "CDN_ACCESS_TOKEN": "cdnctl_T1bz••••…" }
    }
  }
}

The self-repair loop in practice

With the token in place the agent runs the same loop a careful human would: `check` the project, fix what it flags, `deploy`, read the result. In our live test the agent hit a real failure — a Dockerfile that copied the host node_modules into the image and crashed the container — fixed the .dockerignore itself, redeployed, and verified the app healthy. No panel, no human in the loop, and nothing outside the deploy surface touched.

Rotating and revoking

Tokens are listed with their prefix, last-used time and IP — enough to audit without exposing the secret. Revocation is one command and takes effect on the next request. If a token ever lands in a log or a transcript, revoke it first and investigate second; minting a replacement takes seconds.

$ cdnctl deploy-token list
  name: claude-code   prefix: cdnctl_T1bz   last_used: 2026-08-25 15:46 (185.70.97.9)

$ cdnctl deploy-token revoke --id 11
  status: success