Proteger um agente de IA exige seis controles: identidade delimitada, permissões de ferramentas com privilégio mínimo, tokenização de PII, varredura de injeção de prompt, um kill switch e uma trilha de auditoria. Cada um fecha um modo de falha distinto — identidade para você saber qual agente fez o quê, permissões para que um agente comprometido não possa chamar qualquer coisa que quiser, tokenização para que um vazamento não pareça o agente apenas fazendo seu trabalho, varredura de injeção para que uma entrada manipulada não possa sequestrar uma chamada de ferramenta, um kill switch para você conseguir parar um agente sem esperar que ele coopere, e uma trilha de auditoria para que haja evidências quando algo dá errado. Isto é o que cada um faz, onde vive e em qual plano está disponível.
Proteger um agente de IA significa fechar seis modos de falha distintos em tempo de execução — identidade, acesso a ferramentas, exposição de dados, instruções manipuladas, substituição do operador e evidência — com controles que operam fora do próprio raciocínio do agente. Uma instrução no system prompt dizendo ao agente o que não fazer não é um controle; é um pedido do qual o modelo pode ser convencido a se desviar. Cada item abaixo é aplicado em uma camada sobre a qual o agente não tem nenhum voto.
Na ordem em que a maioria das equipes os implementa — identidade e a camada de decisão primeiro, já que tudo o mais depende de saber qual agente você está observando.
POST /v1/credentials/issue, verificável contra /.well-known/jwks.json) é o piso gratuito — ilimitado em todos os planos. A identidade mais completa — verificação de propriedade, manifestos assinados declarando o que um agente pode fazer, e delegações delimitadas a partir de uma conta humana — é o VeriSwarm Passport, no plano Pro e acima. Plano: credenciais básicas gratuitas; Passport a partir do Pro. Como funciona a verificação de identidade do agente.POST /v1/suite/guard/tool-permissions) permitem que você defina uma lista de permissões por ferramenta em vez de confiar no próprio julgamento do agente sobre o que ele deveria chamar. Plano: Max (Guard).[VS:EMAIL:a1b2c3]) antes de cruzar o limite de uma ferramenta, não depois. O VeriSwarm Guard executa isso em POST /v1/suite/guard/pii/tokenize, apoiado por um motor de detecção NER baseado em Presidio, e o Guard Proxy o aplica de forma transparente a cada chamada de ferramenta MCP sem alterações no código do agente. Plano: Max (Guard). Os três vetores que isso fecha.POST /v1/suite/guard/scan) verifica o texto não confiável antes que ele chegue a uma etapa capaz de agir sobre ele, combinando detecção de padrões estruturais com um classificador de ML DeBERTa. Plano: Max (Guard). Como funciona a varredura.POST /v1/suite/guard/kill/{agent_id}) bloqueia toda verificação de decisão e emissão de credencial subsequente para esse agente, independentemente do que seu próprio prompt diga. Ele vive totalmente fora do raciocínio do agente — o agente não é solicitado a parar, ele é negado na camada de política na próxima vez que tentar agir. Plano: Max (Guard). Como o kill switch realmente funciona.É tentador ler uma checklist de seis itens como seis coisas que você precisa comprar. Não é assim que os planos se dividem. A camada de decisão por trás de todos os controles — o VeriSwarm Gate — é gratuita: pontuação de confiança completa, 5.000 verificações de permitir/revisar/negar por dia, ingestão de eventos ilimitada, e emissão ilimitada de credenciais básicas. Você pode estabelecer identidade e começar a pontuar o comportamento do agente sem cartão cadastrado. O que é restrito é a camada de aplicação — as permissões de ferramentas do Guard, a tokenização, a varredura de injeção e o kill switch, além do livro-razão consultável e exportável do Vault — que é Max. A identidade Passport mais completa (verificação, manifestos, delegações) fica no meio, no Pro. Não deixe um fornecedor insinuar que o plano gratuito é uma demo reduzida; para grande parte dos agentes internos de baixo raio de impacto, identidade mais a camada de decisão já bastam por si só.
Os seis controles não são interruptores independentes — eles alimentam uma única decisão. A identidade diz ao motor de políticas qual agente está pedindo. A pontuação de confiança, alimentada pelo fluxo de eventos no qual tanto o Guard quanto o Gate escrevem, diz a ela como esse agente vem se comportando. As permissões de ferramentas, a tokenização de PII e a varredura de injeção são os pontos de aplicação onde uma solicitação específica avança ou é interrompida. O kill switch é a substituição que supera tudo isso. A trilha de auditoria é o que permite reconstruir, depois do fato, por que uma determinada solicitação foi permitida ou negada. Essa decisão — allow, review, or deny — é a camada de confiança que sustenta todos os seis controles. O que realmente é uma camada de confiança.
Identidade delimitada (saber qual agente é esse, e quem é responsável por ele), permissões de ferramentas com privilégio mínimo (restringir quais ferramentas ele pode chamar e sob quais condições), tokenização de PII (remover dados sensíveis antes que cruzem o limite de uma ferramenta), varredura de injeção de prompt (detectar instruções manipuladas antes que disparem uma chamada de ferramenta), um kill switch (uma substituição do operador que vive fora do próprio raciocínio do agente), e uma trilha de auditoria (um registro imutável do que o agente realmente fez). Nenhum dos seis substitui o outro — um agente com identidade perfeita e sem kill switch ainda está a apenas um prompt ruim de distância de um incidente.
A camada de decisão por trás de todos os seis é gratuita: a pontuação de confiança do VeriSwarm Gate, as decisões de política permitir/revisar/negar (5.000 verificações/dia), a ingestão de eventos ilimitada, e a emissão ilimitada de credenciais portáteis básicas (tokens de identidade JWT, verificáveis por JWKS) não custam nada. A camada de aplicação — as permissões de ferramentas do Guard, a tokenização de PII, a varredura de injeção e o kill switch, além do livro-razão de auditoria consultável e exportável do Vault — é um recurso do plano Max. A verificação de identidade mais completa com manifestos assinados e delegações (Passport) fica no Pro. Você pode conectar a identidade e começar a pontuar o comportamento no nível gratuito; a aplicação é onde o plano pago começa a fazer o trabalho.
Não. Uma instrução de system prompt é um pedido do qual o modelo pode ser convencido a se desviar — é exatamente isso que a injeção de prompt explora. Todo controle nesta lista, exceto identidade, opera fora do próprio raciocínio do modelo: as permissões de ferramentas são verificadas antes que uma chamada seja executada, a tokenização de PII age sobre o texto independentemente do que o agente pretendia, e o kill switch nega na camada de política não importa o que o prompt do agente diga. O padrão nos quatro controles de aplicação é o mesmo — mover a verificação para uma camada com a qual o modelo não pode discutir.
Identidade e a camada de decisão (Gate) são o piso mínimo — implantar sem eles significa não ter como saber qual agente fez o quê, nem agir sobre um padrão de mau comportamento assim que você o percebe. Os outros quatro escalam de acordo com o que o agente realmente pode fazer. Um agente interno somente leitura, sem exposição de PII, tem uma superfície de risco muito mais fina do que um que chama uma API de pagamentos e manipula registros de clientes — mas no momento em que um agente pode chamar uma ferramenta externa ou tocar em dados sensíveis, as permissões de ferramentas e a tokenização de PII deixam de ser opcionais. O kill switch e a trilha de auditoria são baratos o suficiente, em termos de engenharia, para que raramente haja um bom motivo para pulá-los quando Guard e Vault já estão conectados.
As proteções de framework (callbacks do LangChain, os validadores de tarefas do CrewAI, um try/except personalizado em torno de uma chamada de ferramenta) rodam dentro do mesmo processo do agente e dependem da execução correta do próprio caminho de código do agente. Os seis controles aqui são externos a esse processo — o VeriSwarm fica entre o agente e as ferramentas/decisões que ele está tentando tomar, então um bug ou uma injeção bem-sucedida na própria lógica do agente também não desativa o controle que a monitora. É a mesma razão pela qual um firewall não é implementado como uma configuração dentro da aplicação que ele protege.
Cada controle fecha um modo de falha distinto, então pular um deixa exatamente esse modo aberto. Pule a identidade e você não conseguirá atribuir um incidente a um agente específico nem revogar apenas o acesso daquele agente. Pule as permissões de ferramentas e um agente comprometido poderá chamar qualquer coisa para a qual tenha credenciais. Pule a tokenização de PII e um vazamento de dados vai parecer o agente apenas fazendo seu trabalho. Pule a varredura de injeção e uma entrada manipulada poderá disparar uma chamada de ferramenta não autorizada antes que alguém a revise. Pule o kill switch e não haverá uma forma rápida de parar um agente com mau comportamento, além de retirar suas credenciais. Pule a trilha de auditoria e você não terá nenhuma evidência do que aconteceu, o que importa tanto para o pós-morte quanto para o próprio incidente.
A pontuação de confiança do Gate, as verificações de decisão e a emissão de credenciais básicas não custam nada. Adicione os controles de aplicação do Guard e o livro-razão exportável do Vault quando o raio de impacto de um agente justificar.