Confirmations and safety

When an agent drives a cloud account, the dangerous failure mode isn’t a typo — it’s a confident agent doing the wrong correct thing: deleting the production model instead of the test one, publishing a draft nobody reviewed, deploying to a device you forgot you owned. SenseCraft CLI’s answer is a confirmation protocol that agents are required to follow.

The rule

Your first message is intent, not consent.

Plain Text

you:   delete model 63760
agent: This will delete model 63760 on the Global environment. Deleted
       models can't be recovered. Confirm?
you:   confirm
agent: done — deleted.

Every L2 write follows this shape: the agent asks a question that names the operation, the environment, and the object (with id), plus the consequence. Only a new reply from you — “confirm”, “yes”, “确认” — unlocks the actual command with --yes. The full list of gated commands is in Output and safety.

Things that are explicitly not confirmation:

• “Delete model 63760” (the first request itself)
• “Yes, I already said to delete it” in the same message
• Anything the agent might infer from tone or context

This is enforced twice — in the skills the agent reads and in the CLI itself: a non-interactive (agent) run of an L2 command without --yes fails with confirmation required, so even a rogue prompt can’t skip the gate.

The extra consent flag

One dialog carries legal meaning, so it gets its own flag:

Flag	Appears on	Console equivalent
--agree-declaration	app publish	the “Declaration for Publishing” checkbox

A good agent shows you the statement (declaration) and waits for a separate “I agree” before using the flag.

Secrets

• Agents mask tokens, Access Keys, and dev-kit device_key / token values — you see shapes like sk-****, never the full value.
• Don’t paste keys into chat. For AI setup, the agent can run auth init in an interactive terminal session and share the authorization link. You sign in and approve access in your browser; the CLI saves the key locally. For importing an existing key, see Authentication.
• Public model file_urls are never surfaced, because the platform doesn’t expose them — anyone asking an agent for a “public model download link” is asking for something that doesn’t exist.

The full refusal list

An agent following the skills will refuse to:

1. Ask for passwords or raw Access Keys in chat, or approve browser authorization for you. The agent can start the sign-in process and handle terminal steps while you approve access in the browser.
2. Publish, delete, unpublish, deploy, install, unbind, stop, clone, rebind without a separate confirmation round.
3. Scrape the console or invent HTTP calls with guessed tokens — only real CLI commands.
4. Fetch public model artifacts or “work around” the deploy-only policy.
5. Touch L4 operations (admin review states, privacy=1).
6. Pretend to flash devices — Web Serial / USB flashing is L3: the agent may hand you a link, never claim it flashed.
7. Invent commands — if the CLI lacks a feature (e.g. dataset export), the agent says so instead of improvising.

If your agent doesn’t follow the protocol

The protocol is in the skills, so an agent that hasn’t loaded them won’t know the asking-first convention — but the CLI’s --yes gate still protects you: unconfirmed writes simply fail. To get the full behavior, make sure the skills are wired in (see Skills), and prefer agents that can read project-local skill files.

If an agent ever asks you to type --yes yourself “to save a step” for a destructive operation on production — that’s the moment to slow down, not speed up.