Bevestigingen en veiligheid

Wanneer een agent een cloudaccount aanstuurt, is de gevaarlijke faalmodus geen typfout — het is een zelfverzekerde agent die het verkeerde juiste ding doet: het productiemodel verwijderen in plaats van het testmodel, een concept publiceren dat niemand heeft beoordeeld, deployen naar een apparaat waarvan je vergeten was dat je het had. Het antwoord van SenseCraft CLI is een bevestigingsprotocol dat agents verplicht moeten volgen.

De regel

Je eerste bericht is intentie, geen toestemming.

Plain Text

jij:    verwijder model 63760
agent:  Hiermee wordt model 63760 in de Global-omgeving verwijderd. Verwijderde
        modellen kunnen niet worden hersteld. Bevestigen?
jij:    bevestigen
agent:  klaar — verwijderd.

Elke L2-schrijfoperatie volgt dit patroon: de agent stelt een vraag waarin de operatie, de omgeving en het object (met id) worden genoemd, plus de consequentie. Alleen een nieuw antwoord van jou — “confirm”, “yes”, “bevestigen” — ontgrendelt het daadwerkelijke commando met --yes. De volledige lijst met afgeschermde commando’s staat in Output en veiligheid.

Wat expliciet geen bevestiging is:

• “Verwijder model 63760” (het eerste verzoek zelf)
• “Ja, ik zei toch al dat je het moest verwijderen” in hetzelfde bericht
• Alles wat de agent misschien afleidt uit toon of context

Dit wordt dubbel afgedwongen — in de skills die de agent leest én in de CLI zelf: een niet-interactieve (agent)uitvoering van een L2-commando zonder --yes faalt met confirmation required, dus zelfs een kwaadwillende prompt kan de poort niet omzeilen.

De twee extra toestemmingsflags

Twee console-dialoogvensters hebben juridische betekenis en krijgen daarom eigen flags:

Flag	Komt voor bij	Console-equivalent
--agree-declaration	app publish	het selectievakje “Declaration for Publishing”

Een goede agent toont je de verklaring (declaration / disclaimer) en wacht op een apart “ik ga akkoord” voordat hij een van beide flags gebruikt.

Geheimen

• Agents maskeren tokens, toegangssleutels en device_key / token- waarden van devkits — je ziet vormen als sk-****, nooit de volledige waarde.
• Plak geen keys in de chat. Heeft de agent inloggegevens nodig, dan is de juiste route dat jij de toegangssleutel in het accountcentrum aanmaakt en auth add lokaal uitvoert.
• Openbare file_urls van modellen worden nooit getoond, omdat het platform ze niet beschikbaar stelt — wie een agent vraagt om een “downloadlink voor een openbaar model”, vraagt om iets dat niet bestaat.

De volledige weigeringslijst

Een agent die de skills volgt, weigert het volgende:

1. auth add of auth init namens jou uitvoeren — ze verwerken ruwe secrets of de browserlogin, dus voer je ze lokaal uit.
2. Publiceren, verwijderen, depubliceren, deployen, installeren, ontkoppelen, stoppen, klonen, herkoppelen zonder een aparte bevestigingsronde.
3. De console scrapen of HTTP-aanroepen verzinnen met geraden tokens — alleen echte CLI-commando’s.
4. Artifacts van openbare modellen ophalen of het deploy-only-beleid “omzeilen”.
5. L4-operaties aanraken (beheerdersreview-statussen, privacy=1).
6. Doen alsof hij apparaten flasht — Web Serial / USB-flashen is L3: de agent mag je een link geven, maar nooit beweren dat hij heeft geflasht.
7. Commando’s verzinnen — ontbreekt een functie in de CLI (bijv. dataset-export), dan zegt de agent dat in plaats van te improviseren.

Als je agent het protocol niet volgt

Het protocol zit in de skills, dus een agent die ze niet heeft geladen, kent de conventie om eerst te vragen niet — maar de --yes-poort van de CLI beschermt je nog steeds: onbevestigde schrijfoperaties falen gewoon. Om het volledige gedrag te krijgen, zorg ervoor dat de skills gekoppeld zijn (zie Skills) en geef de voorkeur aan agents die projectlokale skillbestanden kunnen lezen.

Vraagt een agent je ooit om --yes zelf in te voeren “om een stap te besparen” bij een destructieve operatie op productie — dan is dat het moment om gas terug te nemen, niet om te versnellen.