# Limites de segurança e registro

> Os funis, a validação e as travas que toda escrita de agente compartilha, e a trilha que cada ação deixa para trás.

Um agente não é uma segunda entrada na estação. Toda chamada cai no mesmo código que as
páginas chamam, sob as mesmas travas, e deixa a mesma trilha que a ação de um operador deixaria.

## Limites que toda escrita compartilha {#guardrails-every-write-shares}

- **Os mesmos funis da interface.** As escritas de configuração passam pelos mesmos serviços de
  provisionamento e de caso de uso que as páginas, as escritas ao vivo pegam o funil de escrita único da Lógica, e o
  controle de execução pega o ciclo de vida do Process. Não existe caminho paralelo que um agente pudesse usar para
  contornar a validação, as travas ou o registro no diário.
- **Validação com o rigor do editor.** As inserções e atualizações fundem os parâmetros fornecidos sobre a declaração
  existente e validam o rascunho fundido com as mesmas regras que os editores aplicam. Uma
  atualização recusada não deixa nada aplicado pela metade.
- **A trava de engenharia vale.** Enquanto uma unidade do Process está em execução, mudanças de
  configuração são recusadas com um resultado estruturado "A configuração fica travada enquanto uma unidade está
  em execução", que nomeia o que terminar primeiro, exatamente como as páginas as recusam.
- **Um runtime parado é somente leitura.** Quando o runtime da estação está parado, só inspeção, estado,
  listagem, a ajuda (`help_search`, `help_read`), exportação de relatório, o instantâneo de backup e a
  orientação da interface (`ui_state`, `ui_navigate`, `ui_screenshot`, `ui_scroll`) continuam funcionando;
  toda chamada que altera algo responde `Runtime stopped`, mesmo com o interruptor de área dela ligado.
  Ferramentas acrescentadas no futuro falham fechadas até serem deliberadamente classificadas como somente
  leitura.
- **Ferramentas destrutivas são sinalizadas.** Ferramentas que comandam equipamento ou destroem dados
  (`tag_write`, `action_run`, `process_recipe_apply`, `process_start`, `process_resume`,
  as exclusões, `server_stop`, …) carregam
  o sinalizador de destrutiva do MCP, então clientes que aprovam sozinhos as ferramentas seguras ainda perguntam antes
  destas.

## Como as ações de agente são registradas {#how-agent-actions-journal}

Tudo que um agente faz deixa a mesma trilha que as ações de um operador deixam, nos lugares
em que você já olha:

- O ciclo de vida do endpoint, toda mudança de configuração feita pelo agente e toda sondagem de
  navegador recusada são registrados sob a área **Agent** do Console de [Eventos](events)
  (o `logs_read` filtra por ela diretamente).
- Operações ao vivo dentro do runtime da Lógica (escritas de variável, escritas de tag, execuções de ação, reconhecimentos
  de alarme) são registradas com a origem **MCP**, ao lado das mesmas operações feitas pela
  interface; o histórico de alarmes e a linha "Disparada por" de uma ação dizem **Agente**.
- Execuções que um agente inicia, para, aborta ou comenta gravam **Agente** como o autor no
  arquivo da execução e nos [Históricos](histories), então o nome de uma pessoa nunca é posto em algo
  que ela não fez.
- O histórico persistente de eventos é somente de acréscimo para agentes: o `event_history_read` não consegue
  limpar nem excluir nada.
- Todo gesto de interface de um agente que muda algo (`ui_click`, `ui_set_text`, `ui_select`,
  `ui_set_theme`) deixa uma linha sob a área **Agent**, com a ferramenta, o que ela tocou e a
  página, nunca o texto escrito. Essas linhas vão para o arquivo de log do programa (a pasta
  `logs`, veja [Instalar e abrir](app-install)) e para uma
  [captura detalhada](events-console#detailed-capture), não para a lista do Console, então uma
  automação longa não empurra para fora dela os avisos e os erros. O que o gesto causa é
  registrado no Console como sempre.