Safety — what writes, what asks first

Drafts first, live later

• Theme: the AI edits the theme's draft; visitors see it only once it is published (publish_draft_theme). Preview it with create_theme_preview.
• Pages: a new page is a draft until publish_page.
• Backend workflows: saving keeps a draft; a route runs the new version only after publish_backend_workflow.
• What has no draft — redirects, translations, backend tables and routes, domains — takes effect the moment it is written.

Tools that delete, publish, restore

A tool's name says what it does: delete_…, remove_…, revoke_…, uninstall_…, publish_…, plus restore_backup, restore_theme_version, revert_backend_workflow, upgrade_app and graphql_mutation (runs any mutation). These are the ones visitors see at once, or that cannot be brought back. The full list is under Tools and skills, column Kind.

Who asks first

• Your client decides whether to ask you before each tool call (Claude Code, Cursor… all have per-tool approval settings). For the delete and publish tools, let the client ask.
• The server itself holds back the biggest steps until they are confirmed explicitly: restore_backup does nothing without confirm: true (a full restore also asks for the website's name typed back); delete_content_type needs confirm: true too, because it deletes every record of that type.
• The slim MCP webmati mcp asks again before every delete, publish and restore; a webmati exec script is read-only by default.

Back up before big changes

Before a redesign, a bulk delete or reworking the backend, tell the AI "back the website up first": it uses create_backup and waits for it (the shop-backups skill). If something goes wrong: "restore the website to 10:30".

When the platform itself is the problem

An AI that hits a platform bug or limit should say so, not hack around it. The server tells it how: search_platform_issues first, then vote_platform_issue (+1, with a short note) when the same problem is already reported, or report_platform_issue when it is not, and it gives you the number to follow on Bugs & ideas. The title and text it writes are public to everyone signed in; logs and the failing call go in its private_context, which only you and the platform team see. Both are redacted on the server, but tell the AI never to put a key or a customer's data in a report. In a webmati exec script these are writes, so they need --allow-writes; an automatic website build never gets them.

Keep the key safe

• An API key (wmk_…) is the key to the workspace: never paste it into a chat, never commit it to git. Prefer a key with just the scopes the job needs.

• Revoke a key at any time under Settings ▸ API Keys.

• An image you paste into the chat is something the AI can see but not send: it creates an upload link (create_upload_link) for you to put the image into the media library.