Approvals, Autopilot & Safety

Studio AI is designed to be permission-first. The assistant should be helpful by default, but it should not surprise you with writes, spending, or broad project edits.

The Default Model#

By default, Studio AI should:

• Read and explain freely.
• Ask before making writes.
• Ask before calling billable providers when your policy requires it.
• Ask before higher-risk actions such as deletes, large event generation, or broad batch changes.

This keeps the assistant useful without making it reckless.

Risk Classes#

The key distinction is reversibility. If the action is easy to review and roll back, it belongs lower in the stack. If it can create broad downstream effects, it belongs higher.

Choosing When the Assistant Asks#

Open the Copilot and use the two selectors at the top. They set when the assistant stops to ask you, separately for chat and for /build:

Chat starts on Ask only for risky changes. /build starts on Ask once per plan — the "Approve & build" press is that one approval.

What Always Asks, Whatever You Pick#

Choosing a looser setting can never remove a prompt from this list:

• Deleting anything — an item, a map, a record of any kind.
• Any hard-to-reverse action (risk class R2 or R3).
• Painting terrain over tiles that already carry placed objects or tileset art. Painting over plain generated ground does not count.
• Placing or moving an object onto a tile where one already stands.
• Linking a new image onto a field that already has art.
• Undo itself.

When the assistant stops, the approval card tells you which of these triggered it and, for a destructive step, exactly what would be lost — "overwrites 12 tiles that already hold placed objects or tileset art", for example. You can untick individual steps before approving.

Dry Run#

Switch the Copilot to Dry run and it plans and reports without writing anything at all — and records nothing, so there is nothing to undo afterwards.

Each previewed step is checked by the editor itself, so the preview is what the real run would do:

If the editor would refuse the step (an unknown field, a duplicate key, an item still used by a shop), the preview fails with the editor's own message, so you can fix the request before approving anything.

Gotcha — "Preview built locally". If the editor can't be reached, or your desktop Studio is older than the assistant, the preview is built by the assistant alone: it lists the change but not the current values or the credit cost, and says so. Update Studio to get the full preview.

Every real AI change, AI generation and Apply Live is recorded in Audit Log with its source set to ai.

What Usually Triggers Approval#

Expect approval prompts for:

• Creating or editing project records.
• Batch content generation.
• Asset generation or imports when billable providers are involved.
• Deleting or replacing project content.
• Tool runs that affect multiple entities or a large zone area.

Expect fewer approvals for:

• Explaining systems.
• Inspecting project state.
• Summarizing existing content.
• Running validation-only passes.

Autopilot#

Autopilot is the opt-in mode where Studio AI can continue without pausing for every step, but only inside the limits you define.

Good autopilot controls include:

• Maximum allowed risk class.
• Allowed tool categories.
• Project scope or target entity scope.
• Spend or credit budget.
• Whether billable model calls are allowed.
• Whether deletes are allowed.

If you turn on autopilot, keep it narrow. A safe first profile is usually:

• R0 and R1 only.
• No deletes.
• No broad batch writes.
• Small budget cap.
• Current project only.

Reviewability#

Studio AI should leave a paper trail for every meaningful run.

You should expect to see:

• The goal or prompt.
• The plan it followed.
• Which tools were called.
• Which records or assets changed.
• Validation or playtest results.
• Enough information to continue, refine, or undo the work.

This is one of the main differences between a trustworthy copilot and an opaque chatbot.

AI edits follow the editor's rules and land in the Audit Log#

When the assistant (or an MCP client) creates, edits, clones, bulk-edits or deletes any content — items, mobs, NPCs and their dialogue, quests and objectives, abilities, skills, recipes, pets, mounts, crops, shop entries, settings, map objects, resource nodes, spawn rules, imported media, painted tiles and placed objects, event scripts — it saves through the same path as the editor's own Save or Delete button:

• Same checks. A value the editor would refuse — an unknown field, a stack size of 0, a mob behaviour that doesn't exist, a dialogue choice pointing at a missing line — is refused for the assistant too, with the field named in the error.
• Same follow-through. The change reaches your running game server and refreshes open editor pages exactly as a manual save does.
• Audit Log. Every such change is recorded under Audit Log with its source set to ai, including the before and after values, so you can see exactly what the assistant changed and when.
• Preview first. Every one of these tools accepts a dry run: the assistant can check a change and show you what it would write — or, for a delete, the record that would go — without saving anything.
• Deletes keep the editor's guards. Deleting an item a loot table or shop still uses is refused, exactly as the Delete button warns you; the assistant has to be told to force it.

Safety Boundary#

There are two important boundaries:

1. Project boundary#

Creator-facing AI tools are scoped to the authenticated user's project. The assistant should not be able to act on another user's project, the whole platform, or raw infrastructure through the public creator surface.

2. Platform boundary#

Public Studio AI and Creator MCP are for editor and project-authoring tasks.

They do not expose:

• Billing mutation tools.
• Global admin tools.
• Raw database operations.
• Test reset and fixture tools.
• Deployment and infrastructure control meant for internal operations.

Good Operator Habits#

You will get better results if you:

• Ask for a plan first on multi-entity tasks.
• Keep autopilot narrow until you trust the workflow.
• Let the assistant inspect the target before it edits.
• Review generated content before publishing.
• Save important house rules in project memory so future runs stay aligned.

Failure Modes To Watch For#

Pause and review if you see:

• The assistant proposing changes outside the requested scope.
• Generic content that ignores your project style.
• Too many entities being touched in one run.
• Missing validation after a complex write.
• A billable media run without clear creative constraints.

When in doubt, switch back to read-only review, then re-run with narrower instructions.

Next: Providers & AI Credits.