Confirmaciones y seguridad

Cuando un agente maneja una cuenta en la nube, el modo de fallo peligroso no es una errata — es un agente seguro de sí mismo haciendo la cosa correcta equivocada: eliminar el modelo de producción en lugar del de pruebas, publicar un borrador que nadie revisó, desplegar en un dispositivo que olvidaste que tenías. La respuesta de SenseCraft CLI es un protocolo de confirmación que los agentes están obligados a seguir.

La regla

Tu primer mensaje es intención, no consentimiento.

Plain Text

tú:      elimina el modelo 63760
agente:  Esto eliminará el modelo 63760 en el entorno Global. Los modelos
         eliminados no se pueden recuperar. ¿Confirmas?
tú:      confirmo
agente:  hecho — eliminado.

Cada escritura L2 sigue esta forma: el agente hace una pregunta que nombra la operación, el entorno y el objeto (con su id), más la consecuencia. Solo una respuesta nueva tuya — «confirm», «yes», «confirmo» — desbloquea el comando real con --yes. La lista completa de comandos protegidos está en Salida y seguridad.

Cosas que explícitamente no son confirmación:

• «Elimina el modelo 63760» (la propia primera petición)
• «Sí, ya te dije que lo eliminases» en el mismo mensaje
• Cualquier cosa que el agente pueda inferir del tono o el contexto

Esto se aplica dos veces — en las skills que el agente lee y en la propia CLI: una ejecución no interactiva (de agente) de un comando L2 sin --yes falla con confirmation required, así que ni siquiera un prompt malicioso puede saltarse la puerta.

Los dos flags de consentimiento adicionales

Dos diálogos de la consola tienen significado legal, por lo que tienen sus propios flags:

Flag	Aparece en	Equivalente en la consola
--agree-declaration	app publish	la casilla «Declaration for Publishing»

Un buen agente te muestra la declaración (declaration / disclaimer) y espera un «I agree» aparte antes de usar cualquiera de los dos flags.

Secretos

• Los agentes enmascaran los tokens, las claves de acceso y los valores device_key / token de los kits de desarrollo — ves formas como sk-****, nunca el valor completo.
• No pegues claves en el chat. Si el agente necesita credenciales configuradas, el flujo correcto es que crees la clave de acceso en el centro de cuentas y ejecutes auth add localmente.
• Los file_url de modelos públicos nunca se muestran, porque la plataforma no los expone — quien pida a un agente un «enlace de descarga de un modelo público» está pidiendo algo que no existe.

La lista completa de negativas

Un agente que siga las skills se negará a:

1. Ejecutar auth add o auth init en tu nombre — manejan secretos sin procesar o el inicio de sesión del navegador, así que los ejecutas tú localmente.
2. Publicar, eliminar, despublicar, desplegar, instalar, desvincular, detener, clonar o re-vincular sin una ronda de confirmación aparte.
3. Hacer scraping de la consola o inventar llamadas HTTP con tokens adivinados — solo comandos reales de la CLI.
4. Obtener artefactos de modelos públicos o «saltarse» la política de solo despliegue.
5. Tocar operaciones L4 (estados de revisión de administrador, privacy=1).
6. Fingir flashear dispositivos — el flasheo por Web Serial / USB es L3: el agente puede entregarte un enlace, nunca afirmar que flasheó.
7. Inventar comandos — si a la CLI le falta una función (p. ej., exportación de datasets), el agente lo dice en lugar de improvisar.

Si tu agente no sigue el protocolo

El protocolo está en las skills, así que un agente que no las haya cargado no conocerá la convención de preguntar primero — pero la puerta --yes de la CLI sigue protegiéndote: las escrituras sin confirmar simplemente fallan. Para obtener el comportamiento completo, asegúrate de que las skills estén conectadas (consulta Skills) y prefiere agentes que puedan leer archivos de skills locales al proyecto.

Si un agente te pide alguna vez que teclees tú mismo --yes «para ahorrar un paso» en una operación destructiva sobre producción — ese es el momento de ir más despacio, no más rápido.