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.

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.

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.