# Ditto security and authorization

## Credential boundaries

Use two unrelated credentials:

- `MCP_ACCESS_TOKEN` authenticates clients to the deployed mm-skills router.
- `DITTO_API_KEY` authenticates the router to Ditto.

Do not reuse either token for Coolify. Store both as secret runtime environment variables. Do not expose `DITTO_API_KEY` to MCP clients, generated applications, browser code, build arguments, repository files, support logs, screenshots, or chat.

## Source URLs

Submit only HTTP or HTTPS URLs. Do not embed usernames or passwords in a URL. Avoid signed private URLs and query parameters containing credentials because the URL itself becomes part of the clone job.

Cloning a public page does not establish a right to republish its trademarks, copy, media, user data, or interaction design. Confirm authorization and replace protected material before publication.

## Generated code

Treat generated output as untrusted input until reviewed. Check for:

- copied analytics and advertising identifiers;
- external scripts and remote asset origins;
- forms that still submit to the source website;
- hard-coded API endpoints, emails, phone numbers, and organization identifiers;
- unsafe HTML injection or copied inline scripts;
- dependencies and post-install scripts;
- hidden tracking pixels, service workers, and web manifests;
- login, checkout, account-recovery, payment, or identity-verification UI that could mislead users.

Run generated code in an isolated workspace with no production credentials. Do not deploy it automatically merely because the clone job completed.

## Router behavior

The central router:

- keeps the upstream key server-side;
- accepts only the configured HTTPS Ditto origins;
- rejects clone URLs with embedded credentials;
- prefixes upstream tools to prevent collisions;
- does not fail the entire Coolify catalog when Ditto is temporarily unavailable;
- reports token presence and upstream errors without returning token values.