Quais funções abrir aos agentes de IA?

Torne uma função da sua empresa acessível a assistentes de IA quando uma tarefa específica do cliente se beneficiar disso e seus sistemas puderem impor os limites. Comece pela tarefa, pelos dados necessários e pela pessoa responsável pelo resultado. Uma FAQ pública pode precisar apenas de uma página mais clara. O status privado de um pedido exige acesso controlado. Uma reserva exige um processo definido de aprovação e confirmação.

Uma função “acionável por agentes” é uma função que você disponibiliza para um assistente usar, como consultar disponibilidade. Isso não significa dar acesso geral aos seus sistemas.

Escolha a primeira tarefa e seus limites

Imagine uma empresa de serviços cujos clientes perguntam com frequência se o trabalho está pronto. Uma primeira ferramenta útil poderia informar o status de uma única ordem de serviço. Suas regras deveriam dizer:

• Quem faz a chamada precisa ter autorização para consultar aquela ordem; conhecer o número de referência não basta.
• A resposta contém o status autorizado para o cliente, a última atualização e um canal de suporte. Exclui notas internas e registros de outros clientes.
• A ferramenta não pode editar a ordem, emitir reembolso nem prometer uma data de conclusão ausente no sistema de origem.
• Se a fonte estiver indisponível ou o acesso falhar, informa essa situação sem inventar um status.

Compare isso com o portal do cliente existente antes de construir outra interface. Se o portal já resolve a tarefa, confirme por que os clientes precisam da conexão com assistentes e como você vai mantê-la.

Na primeira versão, mantenha pagamentos, reembolsos, alterações destrutivas e exportações em massa de dados pessoais fora do escopo acionável. Qualquer ampliação proposta deve ter aprovação e testes próprios. Pedir ao modelo que se comporte bem não é controle de acesso.

A leitura também exige proteção

Uma leitura pode divulgar um documento privado, revelar o pedido de outro cliente ou apresentar um preço antigo como atual. Esses resultados podem prejudicar clientes mesmo sem alterar um registro.

Determine o acesso pela identidade verificada e pelas permissões aplicadas no servidor. Um account_id informado pelo assistente não prova que a conta pertence ao usuário. Mesmo dentro da mesma organização, um funcionário pode não ter direito a todos os documentos.

O que MCP oferece e o que você precisa implementar

O Model Context Protocol (MCP) é uma forma de disponibilizar ferramentas a assistentes. As referências abaixo usam a revisão de 28 de julho de 2026, verificada em 9 de outubro de 2026. Confirme as versões que seu cliente e servidor realmente suportam.

A especificação de autorização cobre autorização HTTP, incluindo validação de tokens e escopos de permissão. Ela faz mais do que transportar um login. Sua implementação ainda precisa relacionar as permissões concedidas às operações e aos registros permitidos. Um token válido destinado a outro serviço não deve ser aceito.

A especificação de ferramentas exige validação de entradas, controles de acesso, limites de chamadas e sanitização de saídas no servidor. Recomenda supervisão humana e pedidos de confirmação, mas não impõe um único modelo de interação. Conectar um cliente MCP não comprova que esses controles funcionam na sua aplicação.

As orientações de segurança também alertam que possuir um identificador de estado não equivale a autenticação. Uma referência de fluxo ou carrinho identifica algo a verificar; não comprova quem pode usá-lo.

Torne a aprovação específica e obrigatória

Para uma reserva proposta, mostre ao cliente serviço, fuso horário, data, preço e condições de cancelamento antes da confirmação. Registre o que foi aprovado. Se um detalhe importante mudar, obtenha nova aprovação. Um campo “aprovado” gerado pelo modelo não comprova que o cliente concordou.

Separe a preparação da proposta da confirmação do compromisso. Se salvar um rascunho cria um registro ou envia uma notificação, isso já é uma escrita que precisa entrar no projeto de permissões. O servidor deve recusar o compromisso sem a aprovação exigida para aquelas condições exatas.

Nossa oferta de sistemas acionáveis por agentes começa com ferramentas de leitura e acrescenta por último ações que criam obrigações, com confirmação do cliente para o que for irreversível. Nosso piloto tem requisitos próprios de aprovação humana para escritas nos sistemas, mensagens a clientes e movimentação de dinheiro. Um exemplo geral de arquitetura não amplia esse escopo contratado.

Teste recusas e recuperação antes do lançamento

Use contas e registros de teste. Guarde o resultado esperado ao lado do observado para que outro desenvolvedor possa repetir o teste.

Use permissões restritas, credenciais com validade e revogação testada. Separe credenciais quando o limite de segurança exigir; um login diferente para cada ferramenta não é uma regra universal. Defina tempos máximos de espera, limites de tentativas e cotas por solicitante. Nas escritas, use um identificador estável da operação e tratamento de duplicatas no servidor, sem depender da memória do modelo.

Registre solicitante, operação, decisão de permissão, referência pertinente de aprovação e resultado. Oculte segredos e dados pessoais desnecessários; defina quem lê os logs e por quanto tempo são mantidos. Designe um operador capaz de retirar uma ferramenta e esclarecer um resultado incerto. O guia de pilotos para compras explica como documentar essas responsabilidades.

O que nosso exemplo público comprova

Em 9 de outubro de 2026, examinamos tools/list em mcp.strataigize.com, os metadados públicos de autorização e auth.md. A lista anunciava sete ferramentas públicas de leitura e uma ferramenta autenticada, request_growth_audit, para solicitar uma consulta gratuita de crescimento. Apesar do nome antigo, ela solicita uma consulta, não a AI Opportunity Audit paga.

Essa solicitação é uma escrita. A documentação exige o pedido de uma pessoa específica e informa que alguém analisa os envios; nada é agendado automaticamente. Ela também distingue explicitamente o cadastro aberto de um cliente de software da comprovação da identidade de uma pessoa.

Essa inspeção confirma a interface e as regras publicadas. Não enviamos uma solicitação nem testamos sua segurança nesta revisão. A lista de ferramentas não comprova uso externo ou vendas.

Antes de contratar uma interface, registre primeira tarefa do cliente, dados permitidos, ações proibidas, ponto de aprovação, testes de falha, operador e procedimento de retirada. Meça tarefas concluídas corretamente junto com recusas, exceções e tempo de revisão. A contagem bruta de chamadas inclui novas tentativas e falhas; não é uma contagem de sucesso. A consultoria em IA pode ajudar a definir o escopo antes de contratar a integração.