Gateway de ações para agentes de IA vs. proxy MITM: pontos de controle

Um gateway de ações para agentes de IA e um proxy man-in-the-middle podem ficar entre um agente e um serviço externo. Essa semelhança superficial leva a decisões ruins de arquitetura. Um modelo executa uma ação autenticada em nome do agente enquanto mantém a credencial. O outro encaminha ou intercepta um tráfego que o agente já decidiu criar.

A diferença determina onde você pode dizer não, o que o agente pode roubar, o que uma aprovação significa e se o seu registro de auditoria descreve uma operação deliberada ou um fluxo de pacotes reconstruído. Se o requisito é «o agente nunca pode possuir credenciais de produção», um proxy geralmente é o limite primário errado. Ele ainda pode ter uma função, mas não consegue consertar um segredo que já vive no processo cliente.

Um gateway executa ações nomeadas, enquanto um proxy lida com conexões

Um gateway de ações para agentes de IA aceita uma solicitação para realizar uma operação externa, seleciona uma credencial armazenada, executa a operação e retorna o resultado. O agente solicita o trabalho. Ele não recebe o token bearer, a senha ou a chave privada necessários para repetir esse trabalho em outro lugar.

Um proxy de encaminhamento recebe uma conexão de rede de um cliente e a encaminha para um destino. O cliente continua sendo o dono da solicitação. No HTTP simples, o proxy pode ler o método, a URL, os cabeçalhos e o corpo porque o cliente envia HTTP para ele. No HTTPS, o caso comum é um túnel CONNECT: o proxy estabelece uma conexão TCP com o destino e retransmite bytes criptografados nas duas direções.

Um proxy MITM muda o caso do HTTPS. Ele encerra a conexão TLS do cliente, inspeciona ou modifica a mensagem HTTP descriptografada e cria outra conexão TLS com o servidor upstream. O cliente precisa confiar em uma autoridade certificadora controlada pelo proxy, porque o proxy apresenta um certificado para o host de destino.

Esses modelos respondem a perguntas diferentes:

• Um proxy pergunta para onde o tráfego pode ir e, com interceptação, o que o tráfego diz.
• Um gateway de ações pergunta se executará uma operação autenticada específica.
• Um proxy pode adicionar ou remover material de uma solicitação pertencente ao cliente.
• Um gateway pode manter a credencial e criar sozinho a solicitação autenticada.

Esse último ponto não é apenas uma questão de palavras. Ele determina se um agente comprometido pode pegar uma credencial e chamar o serviço de outra máquina, em outro momento e por outra rota.

Considere um agente encarregado de criar uma implantação. Em um modelo com proxy, o agente normalmente prepara POST /deployments, escolhe o corpo JSON e envia a solicitação. O proxy pode permitir, negar, registrar ou inserir um cabeçalho Authorization. Em um modelo com executor, o agente chama uma ação como create_deployment com argumentos. O gateway resolve o destino e o segredo configurados, faz a chamada HTTP e retorna o status e o corpo da resposta que a ação permite devolver.

O executor ainda precisa de um projeto cuidadoso. Uma ação genérica mal definida, como «enviar uma solicitação HTTP arbitrária», pode recriar grande parte do modelo de proxy. Mas o limite da credencial continua diferente: o gateway possui a credencial e o agente não.

O TLS transforma a inspeção em um problema de autoridade certificadora

O tráfego HTTPS não fica visível para um proxy de encaminhamento comum apenas por passar por ele. Esse ponto é declarado de forma incorreta com tanta frequência que as equipes criam controles baseados em uma suposição que falha na primeira vez que um cliente usa CONNECT.

A RFC 9110 descreve CONNECT como uma solicitação para estabelecer um túnel até um host e uma porta de destino. Depois que o túnel é estabelecido, o proxy retransmite bytes. O handshake TLS acontece dentro desse túnel entre o cliente e o servidor de origem. Um proxy pode registrar o host de destino, a porta, os horários, a quantidade de bytes e o resultado da conexão, mas não pode ler POST /v1/... nem uma chave de API em um cabeçalho criptografado.

Para inspecionar HTTPS, um proxy de interceptação precisa se tornar o endpoint TLS do cliente. O TLS 1.3, especificado na RFC 8446, exige que o cliente valide a cadeia de certificados e o nome do host. Um proxy só consegue passar nessa validação se o cliente confiar em uma autoridade certificadora capaz de emitir certificados para os sites interceptados.

Esse requisito cria trabalho operacional real:

1. Instalar e proteger uma CA privada em toda máquina ou runtime usado por um agente.
2. Fazer runtimes de linguagens, gerenciadores de pacotes, ferramentas de linha de comando, contêineres e clientes incorporados confiarem nela.
3. Lidar com clientes que fixam certificados públicos ou usam seu próprio repositório de certificados.
4. Proteger os corpos de solicitações e as credenciais descriptografados depois que o proxy os recebe.
5. Explicar por que um processo projetado para desconfiar de emissores de certificados desconhecidos agora confia na sua CA de interceptação.

Isso pode ser apropriado em um ambiente empresarial gerenciado. Não é um detalhe pequeno de implementação. Um proxy que descriptografa todo o tráfego de agentes se torna um local de alto valor, com todos os segredos, corpos de solicitações e respostas que passam por ele.

Um executor que mantém credenciais não precisa se passar por cada certificado de destino para observar uma operação. Ele atua como o cliente HTTP da operação que possui. Cria uma conexão TLS normal com o destino, valida o certificado público do destino como qualquer cliente deveria fazer e adiciona a credencial armazenada no momento da execução.

Isso não elimina as preocupações com TLS. O gateway precisa validar certificados corretamente e proteger seu repositório de segredos. Mas elimina a necessidade de distribuir uma CA privada de interceptação ao processo do agente apenas para obter visibilidade sobre uma ação.

Há um teste útil: se o seu documento de projeto diz que o proxy inspecionará solicitações HTTPS, pergunte onde o cliente confia na CA de interceptação. Se ninguém consegue responder de forma clara, o proxy só verá túneis, ou o sistema falhará quando uma ferramenta validar certificados corretamente.

A custódia das credenciais muda o dano que um agente comprometido pode causar

O limite de segurança útil não é «o agente fez uma solicitação de rede através da nossa caixa». A questão é saber se o agente consegue obter uma autoridade reutilizável.

Os tokens bearer deixam isso claro. Um servidor de API normalmente aceita um token bearer de qualquer processo que consiga alcançá-lo. Se um agente recebe a string, pode gravá-la em um arquivo, colocá-la na saída de uma ferramenta, transmiti-la para outro endpoint ou usá-la depois do fim da sessão de aprovação. Redigir os registros depois desse evento não ajuda. A credencial já saiu do limite pretendido.

Um proxy pode reduzir a exposição se inserir o token por conta própria. Ainda assim, o projeto merece análise. O agente controla a solicitação que chega ao proxy. A menos que o proxy entenda a semântica da API e a imponha de forma confiável, o agente pode usar o token inserido em qualquer endpoint, método ou payload permitido pelo token.

Por exemplo, uma regra de proxy que diga «insira este token para api.example.internal» dá ao processo solicitante a autoridade efetiva do token em todo esse host. O agente nunca vê a string do token, mas pode pedir ao proxy que faça chamadas destrutivas. Isso pode ser aceitável para uma conta de serviço com escopo muito limitado. Não é o mesmo controle que permitir uma ação de implantação nomeada e recusar endpoints administrativos não relacionados.

Um gateway de ações pode vincular uma credencial ao caminho da ação que a utiliza. O agente fornece argumentos, não material de autorização. O gateway pode mostrar a uma pessoa a identidade da credencial e a operação pretendida antes de criar a solicitação de rede. Também pode rejeitar uma solicitação que não se encaixe no canal configurado sem tentar uma conexão.

A distinção essencial é entre não divulgação do segredo e contenção da autoridade.

Não divulgação do segredo significa que o agente nunca vê as credenciais brutas. Um proxy que insere cabeçalhos pode oferecer isso.

Contenção da autoridade significa que o agente não consegue transformar uma integração permitida em um transporte autenticado de uso geral. Isso exige definições de ações, tratamento do destino, validação de argumentos e controles aplicados antes do efeito colateral. Um proxy genérico não oferece isso automaticamente.

O SSH torna o problema ainda mais evidente. A autenticação por chave pública SSH prova que um cliente possui a chave privada durante a troca de protocolo. Se o agente tem a chave privada, pode se autenticar onde quer que essa chave seja aceita. Se ele só possui um comando SSH roteado por um gateway, o gateway ou seu auxiliar precisa realizar a autenticação sem exportar a chave.

A RFC 4253 descreve o protocolo de transporte SSH e a arquitetura de autenticação relacionada. A consequência prática é simples: não é possível «inserir uma chave privada SSH em um cabeçalho» com segurança. Ou o processo possui a autoridade de assinatura, ou outro processo realiza a conexão autenticada por ele.

A autorização precisa acontecer antes do efeito externo

Um ponto de controle só tem valor se agir antes daquilo que você pretende controlar. Registrar uma solicitação depois que um servidor upstream a aceitou fornece evidências. Não fornece poder de veto.

Proxies MITM frequentemente oferecem sistemas de políticas e aprovação baseados em atributos da solicitação: host, URL, método, cabeçalhos, corpo da solicitação, identidade do cliente ou categoria do destino. Esses controles podem ser fortes quando o proxy vê o tráfego descriptografado e entende o protocolo da aplicação. Eles também se transformam em um problema de regras. Alguém precisa decidir se /projects/123/members é seguro, se um payload JSON transforma uma atualização inofensiva em uma concessão de privilégios e se uma solicitação codificada contorna uma correspondência de texto.

Já vi equipes começarem com três regras de proxy e terminarem mantendo uma linguagem não documentada de exceções. O problema não é que regras sejam sempre ruins. O problema é fingir que o formato arbitrário de solicitação de um agente oferece uma superfície de políticas estável e pouco ambígua.

Um gateway de ações pode usar um vocabulário menor. A decisão de autorização pode considerar o processo chamador, a credencial configurada, a ação solicitada e os argumentos fornecidos. Uma pessoa não precisa examinar um comando curl opaco e deduzir qual segredo armazenado será anexado no downstream.

O Sallyport segue esse caminho com uma escada fixa de decisão, em vez de uma linguagem de políticas. Seu cofre bloqueado recusa todas as ações. Um novo processo de agente precisa de autorização de sessão por padrão, e a aprovação identifica a autoridade de assinatura de código do processo. Credenciais individuais também podem exigir aprovação a cada uso. São controles deliberadamente amplos, mas acontecem antes de o app executar a ação HTTP ou SSH.

Essa abordagem tem uma limitação que vale declarar: um modelo fixo de aprovação não consegue expressar todas as regras condicionais de uma organização. Se você precisa de uma regra como «permitir gravações apenas durante uma janela de manutenção quando um campo do ticket tiver determinado valor», precisa de um sistema capaz de avaliar e manter essa regra. Não disfarce um gateway de ações simples como um mecanismo de políticas de uso geral.

A vantagem de manter o conjunto de controles pequeno é que um operador consegue prever seu comportamento. O cofre está bloqueado ou desbloqueado. Uma execução de processo foi aprovada ou não. Uma credencial exige aprovação a cada vez ou não. Os controles de segurança falham na prática quando ninguém consegue explicar por que uma chamada foi aceita.

Visibilidade das solicitações e autoridade de ação são propriedades separadas

As equipes frequentemente exigem «visibilidade total» quando, na verdade, precisam de duas coisas diferentes: um registro de qual agente iniciou o trabalho e um registro de cada ação externa. A visibilidade em nível de pacote pode ajudar na depuração, mas substitui mal um registro de ações.

Um registro de proxy pode conter endereço de origem, destino, detalhes de TLS, campos HTTP se a interceptação tiver funcionado e bytes brutos. Isso é material forense útil. Também cria um problema de identidade confuso. Uma conexão informa qual processo se conectou apenas se o ambiente fornecer e preservar essa identidade. Uma solicitação informa o que chegou ao proxy, não necessariamente qual instrução do modelo ou sessão do agente a causou.

Um gateway de ações começa pelo limite da operação. Ele pode registrar a execução do agente que solicitou a operação e a chamada individual que executou. Esses registros respondem a perguntas diferentes:

• Qual processo de agente autorizado tinha uma sessão ativa?
• Qual ação externa essa sessão solicitou?
• Qual credencial ou canal o executor usou?
• Qual resultado voltou, ou onde a chamada falhou?

Não confunda uma trilha de auditoria com um sistema de controle de acesso. Um registro detalhado não impedirá um agente de apagar dados se você concedeu essa ação. Ele pode tornar alterações posteriores detectáveis e fazer com que a análise de incidentes dependa muito menos do banco de dados do próprio serviço.

O Sallyport projeta seus diários Sessions e Activity a partir de um único registro de auditoria criptografado e encadeado por hashes. O comando sp audit verify verifica essa cadeia offline sobre o texto cifrado e não precisa de uma chave do cofre. Esse projeto separa a verificação da capacidade de descriptografar segredos, que é a divisão certa para um investigador que deve validar o histórico sem obter acesso às credenciais.

Um fluxo de verificação concreto deve ter um formato de saída que as pessoas reconheçam. Por exemplo:

$ sp audit verify
Verifying audit chain...
Entries checked: 184
Chain status: valid

O número exato vai variar. A propriedade importante é que um registro alterado, ausente ou reordenado deve fazer a verificação falhar, em vez de produzir silenciosamente um histórico mais curto. Mantenha uma cópia dos dados de auditoria criptografados fora da máquina que os produziu se precisar de proteção contra exclusão total. Uma cadeia de hashes detecta adulterações nos registros que você mantém. Ela não pode provar a existência de arquivos que um invasor destruiu junto com a máquina.

HTTP e SSH expõem limites de mediação diferentes

HTTP parece simples porque tem cabeçalhos, URLs e verbos. Essa aparência pode levar as equipes a tratar toda integração como um problema de inserção de cabeçalhos.

Em uma API HTTP com token bearer, o executor pode manter um registro de credencial que informa como autenticar e onde ela se aplica. Quando um agente solicita uma operação, o executor adiciona o cabeçalho bearer por conta própria. Em um esquema de cabeçalho personalizado, ele adiciona o cabeçalho configurado sem devolver seu valor ao agente. A autenticação básica segue a mesma regra de custódia, embora o executor precise tratar o nome de usuário e a senha como segredos, não como simples texto de configuração.

O resultado prático é a divisão dos dados de entrada. O agente pode fornecer dados da solicitação, como estes:

{
  "method": "POST",
  "path": "/repos/acme/widget/deployments",
  "body": {
    "environment": "staging",
    "revision": "7d3c1a"
  }
}

O agente não deve fornecer isto:

{
  "authorization": "Bearer token-value-goes-here"
}

Essa separação evita a falha comum em que o esquema de uma ferramenta anuncia um campo secreto, o modelo coloca um valor nele e esse valor aparece em rastreamentos, no histórico do terminal, em fixtures de teste ou em trechos de conversa copiados. Tratar um token como argumento de uma ferramenta é um erro de projeto, mesmo que a interface o oculte depois da chamada.

A mediação HTTP ainda precisa de limites. Se o gateway aceitar URLs arbitrárias, o agente poderá alcançar serviços internos, endpoints de metadados de nuvem ou hosts não relacionados por um caminho com credenciais. Se aceitar cabeçalhos arbitrários, o agente poderá tentar contrabando de solicitações ou substituir a semântica de autenticação. Se aceitar corpos arbitrários, o gateway precisa aceitar que a própria API se torne a linguagem de políticas.

O SSH tem limites diferentes. Uma ação pode precisar executar um comando remoto, copiar um arquivo ou consultar um host. O gateway precisa de um destino e de uma chave privada que ele retenha. Um auxiliar sem estado pode criar a conexão SSH e devolver a saída padrão, o erro padrão e o status de saída sem colocar a chave no ambiente do agente.

O limite do comando importa. Uma solicitação como:

host: build-host
command: git rev-parse HEAD

tem uma superfície de revisão mais estreita do que um agente executando um shell local com acesso a ~/.ssh, configurações arbitrárias de proxy e uma linha de comando sem restrições. Ainda é um comando remoto autenticado. Se a credencial puder executar rm -rf remotamente, o gateway não o tornará seguro apenas mudando o transporte. Limite as permissões da conta remota e escolha credenciais para os trabalhos que elas realmente executam.

Um proxy pode transportar SSH por um túnel TCP, mas não pode inspecionar o comando SSH apenas roteando a porta 22. Para inspecionar o conteúdo do protocolo SSH, teria de atuar como um endpoint SSH e estabelecer outra conexão SSH com o upstream, assumindo todas as obrigações de confiança no host, autenticação, registro e compatibilidade que vêm com isso. Chamar isso de proxy não reduz o trabalho de engenharia.

Um proxy continua útil quando controla a camada certa

O argumento contra usar um proxy MITM como gateway de ações de um agente não é um argumento contra proxies. Proxies resolvem vários problemas muito bem quando operam na camada de que você realmente precisa.

Use um proxy de encaminhamento ou gateway de saída quando precisar restringir quais redes ou nomes de host um runtime pode alcançar, forçar o tráfego por uma rota conhecida, controlar o acesso de saída de ferramentas comuns ou coletar metadados de conexão. Esses controles podem impedir que um agente chame um host não aprovado, mesmo que ele não entenda nada do seu modelo de ações.

Use um proxy MITM quando você controla os clientes, consegue administrar uma CA confiável, precisa diagnosticar ou impor comportamentos em muitos clientes HTTP convencionais e aceita a responsabilidade de lidar com tráfego descriptografado. Ambientes de teste de segurança e frotas de dispositivos gerenciados frequentemente atendem a essas condições.

Use um gateway de ações quando o requisito estiver ligado à identidade e à autoridade de um agente autônomo: o agente precisa solicitar uma ação externa, não pode manter a credencial e precisa deixar um registro revisável da ação executada por um executor.

Muitas implantações sérias combinam os dois. O runtime do agente recebe acesso restrito à rede de saída, para que não possa fazer chamadas diretas arbitrárias. O gateway de ações recebe o acesso de rede limitado necessário para alcançar serviços externos aprovados. O gateway mantém as credenciais e as aprovações. A camada de rede bloqueia caminhos de fuga.

Não coloque todos os controles no proxy apenas porque ele já está no caminho da rede. Essa escolha frequentemente força a autorização em nível de aplicação para padrões de URL e transfere o tratamento de segredos para um serviço de interceptação criado para retransmitir tráfego. Ela é popular porque os diagramas de implantação parecem organizados. O limite operacional piora.

Um projeto plausível com proxy falha na transferência

Considere um agente de programação rodando em um ambiente de desenvolvimento. Ele precisa consultar um rastreador de issues, criar uma implantação e inspecionar um host de build por SSH. A equipe instala um proxy HTTPS e configura variáveis de ambiente como estas:

HTTPS_PROXY=http://proxy.internal:8080
HTTP_PROXY=http://proxy.internal:8080

O proxy insere um token de API para o rastreador de issues. A equipe considera o token protegido porque o agente nunca o lê de um arquivo de configuração.

O agente agora envia uma solicitação para um endpoint administrativo no mesmo host. O proxy vê um nome de host permitido e insere o mesmo token. Se a regra não entender a semântica dos endpoints, acabou de dar ao agente toda a autoridade do token por meio de uma interface indireta.

A equipe tenta corrigir isso com listas de caminhos permitidos. Em pouco tempo, precisa de exceções para paginação, endpoints de upload de anexos, redirecionamentos, versões alternativas da API e um fluxo que inclui uma gravação seguida de uma leitura. O proxy agora transporta uma política de aplicação que muda sempre que a API do serviço muda.

Enquanto isso, uma ferramenta não respeita HTTPS_PROXY. Outra usa um repositório privado de certificados e falha na interceptação TLS. Uma terceira está em um contêiner com outro pacote de CAs. Alguém adiciona uma exceção para manter o trabalho funcionando. Essa exceção cria exatamente o caminho que um agente manipulado por prompt ou uma dependência comprometida escolherá mais tarde.

O SSH chega por último e expõe o desencontro. O proxy não consegue inserir a chave privada SSH em um túnel. A equipe monta a chave no ambiente do agente «temporariamente» ou inicia um processo de agente que consegue acessar um agente SSH local. Nesse ponto, o sistema perdeu a propriedade que pretendia preservar.

Um projeto de execução de ações muda essa transferência. O agente invoca uma ferramenta MCP por uma conexão local stdio. O executor mantém a credencial de API ou a chave SSH, faz a conexão externa e retorna o resultado. O MCP transporta a solicitação da ferramenta. Não dá ao agente acesso livre aos segredos. A especificação do Model Context Protocol define o limite de interação com a ferramenta, mas a custódia das credenciais continua sendo responsabilidade de quem implementa o sistema.

Esse projeto não elimina a injeção de prompts. Uma instrução maliciosa ainda pode convencer um agente a solicitar uma ação prejudicial que ele tem permissão para solicitar. Ele limita a falha à autoridade exposta pelo gateway, oferece ao operador um ponto para aprovar ou recusar e evita transformar cada chamada de ferramenta bem-sucedida em uma oportunidade de exfiltrar um segredo reutilizável.

Escolha a arquitetura a partir da autoridade que você se recusa a entregar

Comece pela frase que precisa ser verdadeira. Se for «o processo só pode alcançar destinos aprovados», coloque um controle de rede no caminho. Se for «o processo nunca pode possuir esta chave de API ou chave privada SSH», faça outro processo executar a ação autenticada. Se for «uma pessoa precisa aprovar cada uso desta credencial», garanta que a aprovação aconteça antes de o executor chamar o serviço remoto.

Depois, teste a afirmação contra possíveis desvios. O agente pode ler uma variável de ambiente com um token? Pode acessar um arquivo de credenciais, um agente SSH local, uma sessão do navegador, um serviço de metadados de nuvem ou uma rede de saída sem restrições? Pode pedir a uma ferramenta HTTP genérica que chame outro caminho com a mesma credencial inserida? Uma configuração de interceptação TLS que falha faz o operador desabilitar a validação de certificados ou criar uma rota direta?

Uma revisão curta e útil tem quatro perguntas:

1. Qual processo mantém cada segredo na memória?
2. Qual processo cria a conexão autenticada?
3. Onde uma pessoa pode recusar a chamada antes que o serviço remoto a veja?
4. Qual registro relaciona uma execução específica do agente à operação concluída?

Se a resposta às duas primeiras perguntas for «o agente», nenhuma regra de proxy muda o risco básico. Se a resposta for «o proxy», decida se está preparado para operar a interceptação TLS e a política de aplicação. Se a resposta for «um executor que mantém a credencial», certifique-se de que ele tenha uma superfície de ações estreita e de que o agente não possa ignorá-lo.

O Sallyport foi criado para o último modelo no macOS: seu shim sp mcp permite que agentes compatíveis com MCP solicitem ações HTTP e SSH enquanto o app mantém os segredos e executa essas ações. Ele não é um proxy MITM e não deve ser apresentado como tal.

A primeira tarefa de implementação costuma ser pouco glamorosa: remover as credenciais diretas do runtime do agente. Enquanto isso não for verdade, aprovações e registros de tráfego serão apenas barreiras ao redor de um processo que ainda carrega as chaves.