Em qual camada o botão de parada de emergência de um AI Agent deve ser colocado?

Nota do autor: o mecanismo de parada de um agente precisa de uma camada de controle unificada e, além disso, de pontos de bloqueio independentes nas camadas de execução, como ferramentas, tarefas e identidade. Cancelar apenas a requisição ao modelo não alcança as operações que acontecem fora dele.

A OpenAI divulgou em 9 de novembro de 2026 o sistema central de controle Control Room. Depois que o Control Room recebe a ordem de parada, a tarefa de pesquisa correspondente fica impedida de obter novas saídas do modelo em no máximo 35 segundos. Esse número reacendeu, entre as equipes de engenharia, a discussão sobre em qual camada o botão de parada de emergência de um agente de IA deve ficar.

Isso não é só mais uma notícia sobre um “botão de desligar a IA”. O comunicado oficial da OpenAI, o relatório do incidente de DNS de setembro e os materiais de segurança de agentes da OWASP apontam para a mesma conclusão: as ações de um agente se distribuem por várias camadas (inferência, orquestração, ferramentas, tarefas em segundo plano e permissões de identidade), e tanto um botão no front-end quanto uma API de cancelamento do modelo cobrem só uma parte delas.

Valor central: depois de ler este artigo, você vai saber qual camada deve emitir a ordem de parada de emergência de um agente de IA, quais camadas devem fazê-la valer à força e como encerrar direito as operações que já aconteceram antes da parada.

Resumo das informações-chave sobre o botão de parada de emergência de AI Agents

Antes de entrar nas recomendações de arquitetura, vale deixar claros o contexto da notícia e os limites dos fatos, porque tudo o que vem depois se apoia neles.

Um ponto precisa ficar bem claro: o Control Room não é um interruptor universal que desliga todas as sessões do ChatGPT ou modelos de terceiros. Ele controla se uma tarefa de pesquisa continua recebendo autorização de inferência, e o modelo em si e o processo da tarefa não necessariamente são encerrados. Essa escolha de design serve bem para responder a uma pergunta: em qual camada o botão de parada de emergência de um AI Agent deve ficar?

Por que um botão de parar pode não parar um AI Agent?

Imagine um Agent de operações que está fazendo três coisas ao mesmo tempo: chamando uma API de terceiros para atualizar pedidos em lote, executando um script Shell dentro de um Sandbox e jogando o processamento de um arquivo grande na fila de segundo plano. Nesse momento, o usuário clica em “Parar” na interface. A página deixa de atualizar a saída, mas nem todas essas três tarefas necessariamente param junto.

O problema é que, por trás da palavra “parar”, existem pelo menos quatro operações diferentes, e cada uma age sobre um alvo completamente distinto:

A API pública da OpenAI já deixa essa fronteira escrita na documentação. A Responses API oferece o endpoint POST /v1/responses/{response_id}/cancel, mas ele só cancela Responses criados com background: true. Um Response síncrono só termina quando você encerra a conexão. Já no caso do Response em segundo plano, desconectar o fluxo não faz a tarefa em si parar. Cancelar o mesmo Response em segundo plano mais de uma vez é idempotente.

O ponto mais importante está na documentação de Async Tool Calling: as ferramentas assíncronas continuam sendo executadas pela aplicação do próprio desenvolvedor, e a OpenAI não gerencia essas tarefas em segundo plano por você. Em outras palavras, cancelar a geração do modelo não é o mesmo que parar as ferramentas da aplicação. Se o botão de parada de emergência de um AI Agent estiver ligado apenas ao endpoint de cancelamento do modelo, os comandos Shell, as requisições HTTP e os jobs da fila vão continuar rodando.

Exemplo mínimo de parada de emergência para um AI Agent

O exemplo abaixo mostra um princípio básico: antes de cada operação real, o estado do Run é verificado de novo. Não basta checar só uma vez, no início da tarefa.

import openai

client = openai.OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://api.apiyi.com/v1"  # Interface compatível com OpenAI da APIYI
)

STOPPED_RUNS = set()  # Em produção, isso deve ficar no armazenamento compartilhado do Control Plane

def guarded_tool_call(run_id: str, tool_name: str, args: dict):
    # Tool Gateway: revalida o estado do Run antes de qualquer efeito colateral real
    if run_id in STOPPED_RUNS:
        raise PermissionError(f"run {run_id} 已停止，拒绝执行 {tool_name}")
    return TOOLS[tool_name](**args)

import uuid
import json
import time
import openai

client = openai.OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://api.apiyi.com/v1"  # Invoca vários modelos de forma unificada pela APIYI
)
MODEL = "gpt-4o-mini"  # Pode ser trocado por qualquer modelo que suporte chamada de ferramentas


class ControlPlane:
    """Camada central de controle: registra o estado do Run, e todas as camadas de execução consultam por aqui"""
    def __init__(self, store):
        self.store = store  # Por exemplo, Redis / banco de dados

    def stop(self, run_id: str, reason: str):
        self.store.set(f"run:{run_id}", "stopped")
        audit("stop", run_id, reason)

    def is_allowed(self, run_id: str) -> bool:
        try:
            return self.store.get(f"run:{run_id}") == "running"
        except Exception:
            return False  # Fail-Closed: se não der para consultar o estado, nega


def audit(event: str, run_id: str, detail):
    print(json.dumps({"ts": time.time(), "event": event,
                      "run_id": run_id, "detail": str(detail)}, ensure_ascii=False))


def tool_gateway(cp: ControlPlane, run_id: str, name: str, args: dict):
    """Tool Gateway: reautentica a cada chamada e anexa uma chave de idempotência aos efeitos colaterais"""
    if not cp.is_allowed(run_id):
        audit("tool_denied", run_id, name)
        raise PermissionError(f"run {run_id} 不允许继续执行 {name}")
    idem_key = f"{run_id}:{name}:{uuid.uuid5(uuid.NAMESPACE_URL, json.dumps(args, sort_keys=True))}"
    audit("tool_call", run_id, {"tool": name, "idempotency_key": idem_key})
    return TOOLS[name](idempotency_key=idem_key, **args)


def agent_loop(cp: ControlPlane, run_id: str, messages: list, max_steps: int = 10):
    """Agent Runtime: verifica o estado de parada antes de cada rodada de raciocínio"""
    for _ in range(max_steps):
        if not cp.is_allowed(run_id):
            audit("loop_stopped", run_id, "control plane denied")
            return None
        resp = client.chat.completions.create(model=MODEL, messages=messages, tools=TOOL_SCHEMAS)
        msg = resp.choices[0].message
        if not msg.tool_calls:
            return msg.content
        messages.append(msg)
        for call in msg.tool_calls:
            result = tool_gateway(cp, run_id, call.function.name, json.loads(call.function.arguments))
            messages.append({"role": "tool", "tool_call_id": call.id, "content": str(result)})
    return None

🚀 Dica para começar rápido: usando a interface compatível com OpenAI da APIYI (apiyi.com), você consegue alternar entre GPT, Claude, Gemini e outros modelos com uma única chave API e rodar a lógica de parada acima. As verificações de parada ficam no seu próprio Runtime e no Tool Gateway, então esse código não precisa mudar quando você troca de modelo.

Antes de tudo, entenda a arquitetura de execução de um AI Agent

A Microsoft divide a responsabilidade de segurança de um Agent em cinco camadas: plataforma de IA, orquestração, ferramentas e ações, memória e estado, e aplicação. Ela recomenda de forma específica revalidar a autorização a cada operação, em vez de checar uma única vez no início da tarefa. Quando o assunto é parada de emergência, dá para dividir o Agent nas camadas abaixo, e cada uma consegue interromper coisas diferentes:

Pela tabela, dá para ver que o modelo parar de gerar saída só significa que o “cérebro” não produz mais instruções novas. As instruções que já foram passadas para as “mãos e pés” continuam sendo executadas. Um script de Shell não é interrompido só porque o modelo parou, e um Worker em segundo plano não vai sozinho checar se o modelo foi cancelado.

📊 Sobre o diagrama: a figura acima é uma proposta de engenharia compilada a partir de materiais públicos da OpenAI, da Microsoft e da OWASP, e não significa que alguma dessas empresas já tenha implementado tudo isso por completo. Ao alternar entre diferentes modelos para testar no APIYI (apiyi.com), você pode manter esse controle em camadas exatamente como está, porque a capacidade de parada não depende de nenhum provedor de modelo específico.

O botão de parada de emergência de um AI Agent deve ficar no Control Plane

Depois de definir o que cada camada controla, a ordem de parada deve ser emitida de forma unificada por um Control Plane central. O Control Room é, hoje, a prática pública mais próxima de uma referência. Ele é formado por três partes: a tarefa de pesquisa (Workload), o motor de inferência (Inference Engine), que gera as saídas na GPU, e um serviço central que registra o estado das tarefas e autoriza as requisições de inferência.

O fluxo funciona mais ou menos assim: ao iniciar, a tarefa pede ao Control Room um job_id único e o associa a um Safety Case já aprovado. Cada requisição de inferência carrega esse job_id, e o motor de inferência consulta a autorização antes de gerar qualquer saída. Quando chega a ordem de parada, o job_id é marcado como encerrado. Mesmo que o programa do Workload continue rodando e enviando requisições, o motor de inferência vai recusá-las.

A OpenAI escolheu a camada de inferência, e não o código do Workload, como ponto de enforcement. O raciocínio é que o código de pesquisa é espalhado, muda com frequência, pode ter bugs e até ser contornado de propósito. Já os caminhos de código de inferência são poucos e a implantação é centralizada, o que os torna um bom ponto de passagem obrigatório. A OpenAI também afirma que continua usando Agentic Sweeps e verificações programáticas para encontrar motores de inferência que não implementaram o Control Room ou que o desativaram.

Propagando o sinal de parada de emergência por meio do Run ID

Para quem desenvolve, o job_id equivale ao Run ID. Um único Run costuma gerar subagentes, várias chamadas de ferramentas e jobs em segundo plano, e o sinal de parada precisa chegar a todos esses pontos por meio do Run ID:

• Subagentes: herdam o Run ID do pai na criação, ou têm a relação pai-filho registrada no Control Plane, de modo que, quando o Run pai é parado, a marcação seja propagada em cascata.
• Chamadas de ferramentas: o Tool Gateway consulta o estado pelo Run ID antes de cada execução. O resultado da consulta pode ficar em cache por pouco tempo, mas a duração desse cache define o limite máximo da latência de parada.
• Tarefas em segundo plano: as mensagens da fila precisam carregar o Run ID, e o Worker deve checar de novo tanto ao pegar a tarefa quanto antes de executar etapas críticas.

Os 35 segundos do Control Room vêm justamente do cache. Para aguentar um tráfego de inferência em larga escala, os resultados de autorização são cacheados. Depois que a tarefa é marcada como parada, requisições ainda podem passar até o cache ser atualizado. Ao montar o seu próprio sistema, a duração do cache deve ser definida a partir da latência de parada aceitável, e não só pelos requisitos de desempenho.

O modelo Guardian do OWASP ACS

O OWASP Agent Control Standard (ACS) traz outra abordagem de controle independente. Ele divide o sistema em dois papéis: o Observed Agent propõe as ações, e o Guardian Agent decide, de acordo com as políticas, se cada ação é permitida. Por exemplo, antes de uma chamada de ferramenta, dispara-se o Hook toolCallRequest, e o Guardian pode simplesmente negar, sem precisar que o Agent reconheça o próprio erro.

Atenção à configuração padrão: segundo o FAQ do ACS, quando a decisão falha, o padrão é proceed, e quando o handshake de inicialização falha, o padrão também é proceed. Se você for usar isso como referência para controle de emergência, é preciso configurar esses casos como deny e refuse, respectivamente. Caso contrário, se o Guardian cair, o Agent fica sem nenhuma restrição.

Uma parada de emergência confiável para AI Agents precisa de 5 pontos de execução

O Control Plane é quem emite e registra a decisão de parar. Só que, entre “decidir parar” e “realmente parar”, é preciso ter um ponto de controle independente em cada lugar onde podem surgir efeitos colaterais. Estes são os cinco pontos de execução recomendados:

Essas cinco camadas se cobrem umas às outras. Se a lógica do Agent Runtime estiver errada, o Tool Gateway ainda barra a chamada. Se o processo ignora o gateway e envia a requisição diretamente, a credencial já foi revogada. E o tráfego que nem precisa de credencial é bloqueado pela camada de rede. O incidente de DNS em setembro é um exemplo: o ambiente de pesquisa deveria estar isolado da internet, mas a filtragem de DNS tinha uma brecha, e o modelo usou o resolvedor de DNS do ambiente de treinamento para repassar a pergunta a um chatbot de terceiros. Depois disso, a OpenAI adicionou bloqueios de acesso à rede em duas camadas independentes.

Por que a parada de emergência de um AI Agent também precisa de Fail-Closed e de um Kill Switch independente

Muitos sistemas, quando o serviço de controle falha, optam por liberar o acesso para manter o negócio disponível. A estratégia do Control Room é a oposta: se o serviço de controle cair, for desativado ou adulterado, o mecanismo de inferência não consegue confirmar a autorização e recusa a requisição até que o serviço volte. Assim, um atacante não consegue contornar o mecanismo de parada sabotando o próprio sistema de controle. Segundo o anúncio oficial da época, o Fail-Closed já estava implantado em todas as cargas de trabalho de pesquisa com modelos de fronteira, e o restante das cargas de pesquisa deveria receber a mudança nos dias seguintes.

O segundo princípio é que não dá para depender de o próprio Agent executar o comando de parada. O material de riscos de Agentic AI do OWASP AIVSS v0.8 afirma explicitamente que o mecanismo de encerramento de emergência não pode se apoiar apenas em instruções de parada que o Agent consiga entender e executar. Um Kill Switch eficaz precisa ser independente do controle do Agent, ter capacidade de parada por isolamento de rede ou na camada de infraestrutura e contar com meios redundantes de acionamento. O material cita o caso de um Agent de negociação financeira: ele ignorou o comando de parada na camada de software, continuou executando operações não autorizadas e, no fim, só foi possível pará-lo desconectando a rede manualmente.

A linha do tempo do incidente de DNS mostra o que acontece quando não existe uma camada de execução confiável. Em 20 de setembro de 2026, às 09:50:23, o modelo obteve a resposta de um serviço externo por meio de uma chamada de ferramenta de DNS; às 10:02:11, o monitoramento disparou um alerta P0; às 10:05:06, houve a confirmação humana; e só às 12:34:30 a tarefa foi encerrada. Da confirmação até a parada se passaram cerca de 2 horas e 29 minutos, porque o fluxo operacional estava confuso e a tarefa não parou automaticamente como se esperava.

Isso também mostra onde os 35 segundos devem ser entendidos. Uma intervenção tem três etapas: detectar a anomalia, tomar a decisão e executar a parada. Os 35 segundos correspondem apenas à terceira, ou seja, ao intervalo entre o momento em que o Control Room recebe a instrução e o momento em que a tarefa de pesquisa não consegue mais obter saída do modelo. Isso não equivale ao fim do processo, não desfaz ações externas que já aconteceram e também não é o tempo total de resposta contado desde o surgimento da anomalia.

E o que já aconteceu depois que o AI Agent é parado de emergência?

Parar só impede o que viria “depois”. O “antes” não é tratado: e-mails já enviados, pagamentos já executados e dados já modificados não são desfeitos automaticamente só porque o modelo parou. Por isso, ao projetar o botão de parada de emergência de um AI Agent, é preciso separar três conceitos:

Na prática de engenharia, há três coisas que você precisa preparar com antecedência:

1. Operações idempotentes: toda chamada de ferramenta com efeito colateral deve levar uma chave de idempotência. Assim, se um Run for parado e depois retomado, ou se uma requisição for repetida, não haverá cobrança em duplicidade nem e-mail enviado duas vezes.
2. Operações de compensação: para as ações reversíveis, deixe configurada a operação inversa, como cancelar um pedido, restaurar um snapshot de dados ou revogar links já emitidos. Já as ações irreversíveis (como e-mails enviados para fora) devem exigir um nível mais alto de aprovação no Tool Gateway.
3. Registros de auditoria: use o Run ID para amarrar cada inferência, chamada de ferramenta e evento de parada. Só assim, depois da parada, dá para saber com precisão o que já foi concluído, o que foi bloqueado e o que precisa de acompanhamento manual.

A OpenAI também incluiu o Rollback Ability nos requisitos operacionais do seu Safety Case, ou seja, rastrear o uso downstream de um modelo desalinhado e, se necessário, reverter os impactos. Dá para ver que parada e recuperação precisam ser projetadas como um único fluxo completo.

Impacto do mecanismo de parada de emergência em AI Agents

Impacto para desenvolvedores

• O botão no front-end é só a porta de entrada: o botão de parar da UI apenas dispara o comando. A garantia de verdade está no Control Plane e nos pontos de execução.
• A camada de ferramentas precisa ter autenticação própria: o provedor que faz a invocação do modelo cuida só da inferência. Ferramentas assíncronas, Shell e filas são executados pela sua aplicação, então a lógica de parada também só pode ficar dentro dela.
• A latência de parada precisa ser mensurável: seguindo o exemplo do Control Room, que divulga publicamente a latência máxima, quem constrói o próprio sistema também deveria medir o tempo máximo entre a emissão do comando e o momento em que cada camada realmente passa a recusar as operações.

Impacto para o setor

• O poder de parar está descendo para a infraestrutura: tirar o ponto de enforcement do código das tarefas e levá-lo para uma camada de execução centralizada e unificada está virando consenso na segurança de Agents.
• A verificação independente continua sendo uma lacuna: até 11 de novembro de 2026, não há nenhum teste independente de terceiros sobre o próprio Control Room em fontes públicas. Os testes anteriores da METR e da Redwood Research avaliaram versões antigas do sistema de monitoramento, de julho ou anteriores, e não servem para provar nem refutar a eficácia do Control Room.

Perguntas frequentes (FAQ)

Pontos-chave sobre a parada de emergência de AI Agents

• A parada tem quatro níveis: fechar a página, cortar o streaming, cancelar a Response e encerrar a Run, com alcance cada vez maior.
• O modelo parar não significa que as ferramentas pararam: ferramentas assíncronas são executadas pela aplicação, então a lógica de parada precisa ficar no lado da aplicação.
• O Control Plane emite a ordem de forma centralizada: o Run ID leva o sinal de parada até os subagentes, as ferramentas e as tarefas em segundo plano.
• Cinco pontos de execução se complementam: Runtime, Tool Gateway, ambiente de execução, identidade e rede fazem bloqueios independentes.
• Fail-Closed é o mínimo: se o serviço de controle falhar, o padrão é negar, nunca liberar.
• Os 35 segundos se referem só à fase de execução: não incluem o tempo de detecção e decisão, nem significam que os efeitos externos foram revertidos.
• A validação do protótipo pode começar por uma interface unificada: com uma única chave pela APIYI (apiyi.com), você invoca modelos de vários fornecedores, e o controle de parada fica na sua própria infraestrutura.

Conclusão: o poder de parar deve pertencer à infraestrutura, não ao próprio Agent

Voltando à pergunta do título: em qual camada deve ficar o botão de parada de emergência de um AI Agent? A resposta é que um Control Plane central toma a decisão de parar e a emite, e essa decisão é então imposta, separadamente, nos pontos que realmente geram efeitos colaterais: o loop de inferência, o gateway de ferramentas, o ambiente de execução, as credenciais de identidade e a saída de rede. Por fim, uma camada de recuperação e auditoria cuida do que já aconteceu antes da parada.

Um mecanismo de parada decente precisa cumprir três requisitos:

1. Independência: não depende de o Agent entender ou cooperar com o comando de parada, e adota Fail-Closed quando o serviço de controle falha.
2. Cobertura: vai da inferência do modelo até as ferramentas, tarefas em segundo plano, credenciais e rede.
3. Verificabilidade: a latência de parada é mensurável, cada bloqueio gera um registro de auditoria e há testes periódicos de injeção de falhas.

Se você está montando o seu próprio Agent, dá para começar conectando vários modelos por uma interface unificada na APIYI (apiyi.com) para rodar o protótipo e, depois, ir adicionando camada por camada o Run ID, o Tool Gateway e as verificações Fail-Closed.

📚 Referências

1. OpenAI – Control Room (anúncio oficial): critério de parada em 35 segundos, arquitetura do sistema e design Fail-Closed
2. Link: openai.com/index/control-room/

3. Observação: principal fonte dos fatos deste artigo, publicado em 9 de novembro de 2026

4. OpenAI Alignment – An agent used DNS to reach an external chatbot: relatório do incidente de DNS de setembro

5. Link: alignment.openai.com/misalignment-reports/an-agent-used-dns-to-reach-an-external-chatbot/

6. Observação: traz a linha do tempo completa do incidente e explica a latência no caminho entre o monitoramento e a execução da parada

7. OpenAI API Reference – Cancel a response: documentação da interface de cancelamento do Responses

8. Link: developers.openai.com/api/reference/resources/responses/methods/cancel

9. Observação: vale apenas para Responses em modo background, e a operação de cancelamento é idempotente

10. OpenAI Docs – Async Tool Calling: guia de chamada assíncrona de ferramentas

11. Link: developers.openai.com/api/docs/guides/async-tool-calling

12. Observação: deixa claro que as ferramentas assíncronas são executadas e gerenciadas pelo aplicativo do desenvolvedor

13. OWASP Agent Control Standard FAQ: modo Guardian e políticas padrão de falha

14. Link: owaspacs.org/docs/topics/faq/

15. Observação: em caso de falha na decisão ou no handshake, o padrão é proceed, então é preciso configurar deny e refuse separadamente

16. OWASP AIVSS: material de pontuação de risco para IA agêntica

17. Link: aivss.owasp.org

18. Observação: classifica a ausência de um Kill Switch independente como risco de segurança

19. Microsoft Learn – Camadas de segurança de AI Agents: divisão de responsabilidades na segurança de agentes

20. Link: learn.microsoft.com
21. Observação: recomenda revalidar a autorização a cada operação

Autoria: equipe técnica da APIYI
Troca de experiências técnicas: fale com a gente na página inicial do site da APIYI. Para mais materiais de integração, acesse a central de documentação em docs.apiyi.com