# Limiti di sicurezza e registrazione

> L'unico punto di scrittura, le convalide e i blocchi comuni a ogni scrittura di un agente, e la traccia che ogni azione lascia.

Un agente non è una seconda via d'ingresso nella stazione. Ogni chiamata finisce nello
stesso codice che chiamano le pagine, sotto gli stessi blocchi, e lascia la stessa traccia
che lascerebbe l'azione di un operatore.

## I limiti comuni a ogni scrittura {#guardrails-every-write-shares}

- **Gli stessi punti di scrittura dell'interfaccia.** Le scritture di configurazione passano
  per gli stessi servizi di preparazione e di caso d'uso delle pagine, le scritture sul campo
  viaggiano sull'unico punto di scrittura della logica e il comando delle prove segue il ciclo di vita di
  Process. Non esiste un percorso parallelo con cui un agente possa aggirare convalide,
  blocchi o registrazione.
- **Convalida pari a quella degli editor.** Un `upsert` fonde i parametri forniti sulla
  dichiarazione esistente e convalida la bozza risultante con le stesse regole che
  applicano gli editor. Un `upsert` rifiutato non lascia nulla applicato a metà.
- **Il blocco di progettazione vale anche qui.** Mentre un'unità di Process è in prova, le
  modifiche di configurazione sono rifiutate con un esito strutturato « Configuration is
  locked while a Unit is running » che nomina che cosa va concluso prima, esattamente come
  le rifiutano le pagine.
- **Un runtime fermo è in sola lettura.** Quando il runtime della stazione è fermo
  continuano a funzionare solo l'ispezione, lo stato, gli elenchi, la guida (`help_search`,
  `help_read`), l'esportazione dei rapporti, l'istantanea di backup e l'orientamento
  nell'interfaccia (`ui_state`, `ui_navigate`, `ui_screenshot`, `ui_scroll`); ogni chiamata
  che modifica risponde `Runtime stopped` anche se l'interruttore della sua area è attivo.
  Gli strumenti aggiunti in futuro falliscono in sicurezza finché non vengono classificati
  deliberatamente come di sola lettura.
- **Gli strumenti distruttivi sono contrassegnati.** Gli strumenti che comandano il campo o
  distruggono dati (`tag_write`, `action_run`, `process_recipe_apply`, `process_start`,
  `process_resume`, le eliminazioni, `server_stop`, …) portano il contrassegno MCP di
  strumento distruttivo, così i client che approvano da soli gli strumenti sicuri chiedono
  comunque prima di questi.

## Come vengono registrate le azioni di un agente {#how-agent-actions-journal}

Tutto quello che un agente fa lascia la stessa traccia delle azioni di un operatore, nei
posti in cui già guardi:

- Il ciclo di vita dell'endpoint, ogni modifica di configurazione fatta dall'agente e ogni
  sondaggio da browser rifiutato vengono registrati nell'area **Agent** della console di
  [Eventi](events) (`logs_read` filtra direttamente su quell'area).
- Le operazioni sul campo dentro il runtime della logica (scritture di variabili,
  scritture di tag, esecuzioni di azioni, tacitazioni di allarme) vengono registrate con
  origine **MCP**, accanto alle stesse operazioni fatte dall'interfaccia; lo storico degli
  allarmi e la riga « Avviata da » di un'azione dicono **Agente**.
- Le prove che un agente avvia, ferma, interrompe o commenta registrano **Agente** come
  autore nel file della prova e negli [Storici](histories), così il nome di una persona non
  finisce mai su qualcosa che non ha fatto.
- Lo storico persistente degli eventi è a sola aggiunta per gli agenti: `event_history_read`
  non può cancellare né eliminare nulla.
- Ogni gesto di un agente sull'interfaccia che cambia qualcosa (`ui_click`, `ui_set_text`,
  `ui_select`, `ui_set_theme`) lascia una riga nell'area **Agent**: lo strumento, ciò su cui ha
  agito e la pagina, mai il testo scritto. Queste righe vanno nel file di log del programma (la
  cartella `logs`, vedi [Installazione e primo avvio](app-install)) e in una
  [cattura dettagliata](events-console#detailed-capture), non nell'elenco della console, così una
  lunga automazione non ne spinge fuori avvisi ed errori. Ciò che il gesto provoca viene
  registrato nella console come sempre.