Sua empresa deve ser acionável por agentes de IA ou é risco?

Um crédito pode aparecer no seu livro contábil sem que nenhum funcionário o tenha emitido e sem que nenhum invasor o tenha forçado. Um cliente conversou com um assistente de IA, a janela do ChatGPT, do Claude ou do Gemini que esse cliente já usa. O assistente chamou uma tarefa que você tornou acionável por agentes: uma tarefa que seus sistemas executam quando esse assistente pede. Ele concluiu que um reembolso era o próximo passo útil, apresentou um login válido, e o seu sistema aceitou a chamada, exatamente como foi construído para fazer.

Segunda-feira: escreva as três tarefas que um assistente nunca poderá iniciar. Pagamentos e reembolsos. Edições destrutivas e exclusões. Exportação em massa de qualquer dado pessoal. Depois, procure uma tarefa já conectada que não pertença a essa lista. Você não começa configurando um servidor.

Um login não é uma permissão.

Respostas erradas são baratas. Ações erradas, não.

A falha para a qual as pessoas se preparam é uma resposta ruim. Um preço errado informado por um chatbot custa um e-mail de correção.

A falha que realmente dói é uma mudança de estado: um reembolso emitido, um registro excluído, uma lista de clientes exportada, uma reserva sobrescrita. As taxas de chargeback chegam semanas depois. Uma exportação de dados pessoais que sai do seu perímetro vira uma decisão de notificação. Se os seus logs não conseguem responder “quem fez isso” com uma consulta, aquela semana vira duas.

Tarefas de escrita são lançadas porque a demonstração fica melhor com elas. Uma conexão somente leitura é um vídeo de Loom sem graça. Uma conexão que agenda o horário ganha o orçamento. A Callable vende um software de voz que atende o telefone de uma empresa 24 horas por dia, 7 dias por semana, agendando horários e fazendo reservas, porque agendar é o que fecha a venda do software. Esse incentivo é o motivo pelo qual a superfície arriscada é construída primeiro.

O login chega. Você decide o que ele pode fazer.

A conexão mais comum é o Model Context Protocol (MCP), publicado em 18 de junho de 2025: uma especificação que permite a um assistente chamar uma tarefa nos seus sistemas. Ela diz que uma pessoa precisa consentir antes que uma tarefa seja executada e, em seguida, diz que a própria especificação não garante isso. A garantia é sua, e a fatura também.

A página de tarefas orienta os implementadores a validar entradas, limitar quem pode chamar o quê, conter tempestades de novas tentativas e tratar as respostas do assistente como não confiáveis. Nada disso vem com a conexão MCP. Cada item é trabalho que sua equipe constrói.

A seção de login da mesma revisão do MCP se apoia na infraestrutura comum de login para que uma credencial possa chegar por HTTP e ser rejeitada quando estiver ausente ou fraca demais. Quais tarefas esse login deve poder iniciar fica fora da especificação, fora do seu provedor de login e fora do kit que você instalou. É um julgamento que sua empresa faz uma vez e depois precisa defender.

As notas de segurança existem porque os implementadores continuam supondo que o formato de transmissão faz o trabalho de segurança. Um login vinculado ao público errado, uma sessão fácil de adivinhar, um ID de cliente estático: esses são os caminhos comuns pelos quais uma demonstração que funciona vira um incidente. Leia as notas. Não trate a versão do MCP como um programa de controles.

Algo mudou em dezembro de 2025 que tornou isso urgente. O Google começou a lançar conexões MCP hospedadas, começando pelo Maps e pelo BigQuery, sob o lema “agent-ready by design”. A Cloudflare lançou uma forma de expor um método em uma linha por chamada remota. Quando as plataformas transformam a exposição em um padrão de uma linha, a decisão de escopo deixa de ser uma fase de design. Vira algo que um desenvolvedor faz no meio da sprint sem avisar ninguém.

Permita quatro tarefas, recuse três, confirme uma

Esta é a divisão que defendemos, e o raciocínio importa mais que a lista.

Permitidas, somente leitura:

Recusadas de cara: pagamentos e reembolsos, edições destrutivas e exclusões, exportação em massa de qualquer dado pessoal. Não vamos construir essas tarefas como acionáveis por agentes, com nenhum orçamento. O pior resultado dessas tarefas é uma ação errada. Reforçar o prompt não move uma tarefa para o outro lado dessa linha.

Um nível intermediário: criação de rascunhos. Um assistente pode propor uma reserva, um chamado ou um pedido. Um humano confirma. O MCP tem uma etapa de confirmação embutida (perguntar à pessoa no meio da tarefa e deixar essa pessoa editar a resposta). A maioria das implementações pula essa etapa.

Permita tarefas cujo pior resultado é uma resposta errada. Recuse tarefas cujo pior resultado é uma ação errada.

Não vem aqui nenhuma construção de servidor. O código é a parte que sua equipe já sabe escrever. Se você está orçando o trabalho, quanto custam de fato os agentes de IA e construir ou comprar são mais úteis que outro tutorial.

Dê a cada tarefa sua própria chave

Quatro padrões decorrem de tratar quem chama como uma máquina.

Um login por tarefa, não um por integração. Uma credencial que lê faturas não deveria alcançar o sistema de chamados.

Vincule o login à conta. O assistente é só o mensageiro. Mensageiros são trocados, descontinuados e adquiridos.

Limites de taxa dimensionados para algo que nunca se cansa. Um humano desiste depois de três tentativas. Um assistente tenta de novo até acabarem os tokens, as unidades cobradas que um modelo gasta em um prompt. Coloque chaves de idempotência em tudo que escreve, para que a segunda chamada idêntica não tenha efeito.

Dê a cada credencial de tarefa uma data de expiração, para que a revogação continue sendo manutenção de rotina.

E registre o nome da tarefa, os argumentos, a identidade de quem chama e a mudança de estado resultante, em um só lugar. Esse é o artefato que decide se uma semana ruim vira apenas uma tarde ruim. Se o setor de compras vai perguntar sobre isso, um piloto de agente que sobrevive ao setor de compras explica o que esse setor lê.

O loop entediante custa mais que o ataque engenhoso

Todo mundo se prepara para o prompt malicioso. A falha mais banal custa mais.

Digamos que uma tarefa receba um parâmetro ambíguo. Um assistente a chama. A resposta parece incompleta, então ele chuta um valor ligeiramente diferente e chama de novo. Nada vaza. Nenhuma credencial é abusada. A fila se enche de registros quase idênticos, e o dano é volume e conciliação.

O mecanismo está documentado. Um estudo de servidores em produção que expõem tarefas a assistentes diz isso diretamente: os modelos escolhem tarefas apenas pelas descrições em linguagem comum, ignorando documentação e schemas. Uma tarefa que um engenheiro acha óbvia pode ser ambígua para quem chama.

Então o padrão é uma cota por chamador e um schema de argumentos que recusa valores ambíguos de cara. Um parâmetro com três leituras plausíveis é um bug.

Também nos recusamos a reportar “ações resolvidas pelo assistente” como métrica de sucesso. Ela conta chamadas que aconteceram, não decisões que estavam certas, e é o número com mais chance de fazer uma superfície perigosa parecer uma vitória em uma apresentação ao conselho.

Como é a nossa, para você conferir

Nosso próprio site é acionável por agentes, e a superfície é pequena de propósito. mcp.strataigize.com responde ao tools/list do protocolo de assistentes com oito tarefas: sete leituras públicas (quem somos, nossos serviços, estudos de caso, ferramentas gratuitas, uma busca de conteúdo, como contratar, a obtenção de uma página) e uma ação autenticada, solicitar uma consultoria de crescimento em nome de uma pessoa identificada, sob um único escopo chamado audit:request. Nada nesse servidor pode movimentar dinheiro, exportar uma lista ou alterar um registro. O documento de recurso protegido indica o servidor de autorização, e um auth.md em texto simples explica tudo; ambos ficam onde um assistente procura primeiro. Buscamos o servidor, sua lista de ferramentas, esse documento e o auth.md em 13 de setembro de 2026 para escrever este parágrafo, e você também pode buscá-los.

O número honesto que acompanha: nos sete dias até 6 de setembro de 2026, nossos logs mostraram que nenhum cliente de assistente externo o havia chamado. Construir a superfície e o mercado usá-la são eventos diferentes, e só o segundo conta como adoção.

Escreva primeiro a lista de recusas

A maioria das equipes dimensiona isso como um projeto de integração: define o escopo como o de um conector, entrega para quem cuida da API e lança em uma sprint. Dimensionada assim, a decisão de permissões ainda é tomada. Ela é tomada por padrão, por quem escreveu a descrição da tarefa, e ninguém assina a lista.

Dimensione, em vez disso, pelo que você defenderia por escrito depois da pior chamada que seus logs permitem. Comece pela lista de recusas. Escreva as três tarefas que nunca serão iniciadas por um assistente antes das quatro que serão, e transforme essa lista em um documento que seu CTO e seu jurídico assinem, datado, ao lado da revisão do MCP de 18 de junho de 2025 sobre a qual você construiu.

Para a maioria das empresas, a resposta é uma pequena superfície somente leitura, um nível de rascunhos que uma pessoa confirma, e pagamentos e exportação em massa que um assistente nunca pode iniciar. Essa versão rende uma demonstração pior e um feriado prolongado mais seguro.

Escreva primeiro a lista de recusas. Depois, vá encontrar a tarefa já conectada que não pertence à lista. Se você quer essa superfície projetada em vez de adivinhada, comece pela consultoria em IA. A versão pública do que entregamos são as superfícies acionáveis por agentes.