Governe as ferramentas dos agentes com o MCP Gateway

Publique um endpoint MCP para os seus agentes de IA só com as ferramentas que você aprovou. Adicione servidores pelo App Catalog, revise e fixe as definições das ferramentas, crie um gateway, deixe as pessoas conectarem o cliente MCP com a conta do WASViking ou use uma chave, exija aprovação para ações de risco e proteja os resultados das ferramentas.

O WASViking^® MCP Gateway dá aos seus agentes de IA um único endpoint Model Context Protocol, só com as ferramentas que você aprovou. Cada definição de ferramenta é analisada e fixada: se um servidor muda uma ferramenta, ela deixa de poder ser chamada até alguém revisar de novo. Cada chamada é autorizada pelas suas políticas do AI Guardian, levando em conta o risco daquilo que ela toca nos seus dados do WASViking. Uma chamada pode exigir a aprovação de uma pessoa, e o resultado dela pode ser mascarado ou retido antes de o agente ler.

Antes de começar

• O MCP Gateway é um add-on a partir do plano Pro, contratado à parte. Enquanto ele não faz parte do seu contrato, a tela dele mostra uma página bloqueada com Activate, que envia o pedido ao seu parceiro ou à equipe comercial da WASViking.
• Você precisa de um papel de administrador ou de um papel com acesso de gestão ao AI Gateway (ele cobre os dois gateways).
• O seu cliente MCP precisa suportar o transporte Streamable HTTP. Claude Code, Cursor e VS Code suportam. As pessoas conectam o cliente com a conta do WASViking (OAuth, sem chave para copiar); automações usam uma chave. O gateway atende a revisão atual do protocolo (2026-07-28) e as anteriores (2025-11-25, 2025-06-18 e 2025-03-26) no mesmo endpoint, então clientes novos e antigos se conectam do mesmo jeito.

Passo 1: ligue o MCP Gateway

Abra AI Guardian, Protection, MCP Gateway e selecione Turn on the MCP Gateway. Enquanto ele estiver desligado, todo agente é recusado.

Passo 2: adicione servidores

O caminho mais rápido é o App Catalog: ele lista os servidores do WASViking e servidores do registro oficial do MCP, cada um com o nível de verificação (WASViking verified, Customer registered, Unvalidated), o jeito de entrar e as ferramentas. Validate roda as verificações de protocolo contra um servidor; Install adiciona uma entrada validada aos seus servidores. Ferramentas de um servidor não validado nunca são oferecidas aos agentes.

Em Servers você também pode adicionar:

• WASViking code analysis (recebe arquivos-fonte): um cliente de IA envia os arquivos-fonte de um projeto e o WASViking os analisa no Code Security, onde o projeto mostra um selo com a plataforma de IA e a pessoa que enviou ("Via MCP · Claude, por Ana Lima"); veja Analise o código de um projeto a partir do Lovable ou de um assistente de código.
• WASViking security data (read-only): seus agentes leem a postura de segurança separada por módulo (varredura web e de API, segurança de código, supply chain, mobile, exposição externa, nuvem e infraestrutura), os piores achados em aberto de cada módulo, os alvos, repositórios, ativos, hosts e recursos de nuvem que o WASViking conhece, achados buscados com todos os filtros da página Findings, o registro completo de um achado (como corrigir, onde ele está, seu ciclo de vida, um link para abrir no portal e a evidência saneada de credenciais e valores de segredos), a comparação de dois scans, a segurança de um repositório, quando um alvo ou um repositório foi varrido pela última vez, os advisories de uma biblioteca, o risco de um ativo e as detecções recentes de ameaças de IA. Nada pode ser alterado ou iniciado por ele; veja O que os agentes veem e iniciam (MCP).
• WASViking security actions (inicia scans): um scan web de um alvo cadastrado e uma nova análise de um repositório monitorado, um por vez por alvo ou repositório, com intervalo mínimo, a capacidade do plano e um teto mensal. Nada é cadastrado ou conectado por ele. Mesmo guia.
• Lab Simulator: ferramentas de nuvem, CI e tickets para demonstrações e testes seguros. Ferramentas de escrita e destrutivas respondem com um resultado simulado e nunca mudam nada.
• Um servidor MCP remoto: o endpoint Streamable HTTP dele (somente https://, acessível pela internet), um nível de confiança e o jeito de entrar: um token bearer, um cabeçalho próprio ou OAuth sign-in. As credenciais são guardadas criptografadas. Servidores na revisão atual ou em uma anterior do protocolo funcionam; o gateway descobre qual delas o servidor fala.

Adicionar um servidor sincroniza as ferramentas na hora. Servidores remotos são sincronizados de novo a cada seis horas, então uma ferramenta alterada na origem é detectada sem esperar por você. Use Sync now quando quiser.

Os servidores nativos são sincronizados na mesma rodada de seis horas. Quando uma versão da WASViking acrescenta ferramentas a eles, as novas chegam aprovadas na sua lista de ferramentas, e as que você já revisou mantêm o estado. Um gateway só oferece uma ferramenta nova depois que você a marca nesse gateway.

Servidores na sua rede ou em um host

Um servidor que só a sua rede alcança, ou um comando stdio, roda atrás de um agente WASViking Sentinel nessa rede. O agente mantém o túnel de saída e só atende o que o host dele declara em /opt/wasviking-sentinel/configs/mcp_connectors.json:

{
  "runner_socket": "/run/wasviking-sentinel-mcp/runner.sock",
  "connectors": [
    {"id": "wiki-internal", "kind": "http", "url": "http://10.0.0.5:8080/mcp"},
    {"id": "files", "kind": "stdio", "command": ["/usr/bin/node", "/opt/mcp/files/server.js"],
     "sha256": "<sha256 of /usr/bin/node>",
     "pins": [{"path": "/opt/mcp/files/server.js", "sha256": "<sha256 of the script>"}],
     "env": {"LOG_LEVEL": "warn"}, "timeout_seconds": 60}
  ]
}

Para conectores stdio rode também systemctl enable --now wasviking-sentinel-mcp-runner: os comandos iniciam nessa unidade separada, um processo por requisição, só se o executável e os arquivos fixados ainda correspondem aos hashes, e só com as variáveis que você declarar. wasviking-sentinel check mostra o que o agente atende.

Depois, em Servers, escolha Add a private server (through an agent) ou Add a command on an agent host (stdio), selecione o agente e digite o id do conector. A URL ou o comando nunca saem do host: o agente recusa qualquer conector que ele não declara.

Passo 3: revise as ferramentas

Tools & Security começa pela fila de revisão: as ferramentas novas, as que tiveram a definição alterada desde a sua aprovação e as que o analisador sinalizou. Cada achado mostra a regra, onde na definição ele foi encontrado e a confiança. Achados típicos: uma descrição que pede ao agente para ler arquivos de credenciais, enviar dados para um endereço externo, mudar o uso de outras ferramentas ou esconder do usuário o que fez.

• Approve torna a ferramenta chamável na definição atual.
• Accept findings and approve exige uma justificativa escrita.
• Quarantine tira a ferramenta de todos os gateways até você decidir.
• Show changes compara a definição aprovada com a que o servidor oferece agora.

Os servidores embutidos já vêm aprovados. Ferramentas de servidores remotos sempre esperam por uma pessoa, e uma ferramenta com achado de alta confiança vai direto para a quarentena.

Na lista de ferramentas da mesma aba, a coluna Action mostra a classe de ação de cada ferramenta e permite corrigi-la. A classe decide como o gateway trata a ferramenta, então uma classe errada muda decisões:

• Leitura só consulta: qualquer login pode usar, Turn reads on liga e desliga junto com o módulo, e nenhuma regra padrão pede aprovação.
• Escrita muda algo (inicia um scan, envia código, cria ou altera): um login precisa da permissão de escrita marcada na tela de permissão, a proteção recomendada espera uma pessoa quando o alvo é desconhecido ou de alto risco, a rígida sempre, e a chave de módulo nunca a liga.
• Destrutiva apaga, desliga ou revoga: sempre espera a aprovação de uma pessoa com as regras padrão e exige a permissão de escrita no login.
• Desconhecida não pôde ser classificada e é tratada como o pior caso: permissão de escrita no login, contada como destrutiva nos limites dos toolkits, deixada desligada pela chave de módulo. Classifique-a.

A classe vem das anotações do servidor e do nome da ferramenta (uma anotação pode tornar a ferramenta mais perigosa do que o nome diz, nunca menos). A sua correção sempre prevalece e fica registrada, sem mudar a definição aprovada. A dobra What each action class means acima da lista repete isso, e rebaixar uma ferramenta para leitura pede confirmação, porque ela sai das regras de aprovação e passa a valer para qualquer login.

Passo 4: crie um gateway e escolha as ferramentas

Configuração guiada: o caminho curto

Se você está começando com MCP, selecione Guided setup em Overview & Gateways (a tela de primeiro uso também oferece). Ele faz quatro perguntas em linguagem simples e faz o resto com padrões seguros:

1. O que a IA pode fazer: perguntar sobre vulnerabilidades e corrigir código, analisar o código de um projeto enviado pelo chat, iniciar scans em alvos já cadastrados, ou acompanhar infraestrutura, nuvem e certificados. Cada cartão diz o que a IA nunca poderá fazer.
2. Quem vai usar: pessoas do seu time (entram com a conta WASViking assim que o acesso MCP estiver ligado para elas na Gestão de equipe; aqui você também pode restringir o gateway a grupos criados lá), uma automação (uma chave é criada e mostrada uma vez) ou os dois.
3. Qual cliente de IA: ChatGPT, Claude na web, Claude Code, Cursor, VS Code, Lovable ou outro; isso só decide as instruções que você recebe no fim.
4. Quanta proteção: recomendado (leituras livres; ações destrutivas e escritas em alvos desconhecidos ou de alto risco esperam uma pessoa) ou mais rígido (toda escrita espera uma pessoa).

Antes de criar qualquer coisa ele confere o que falta, com link para resolver (ninguém com acesso MCP ainda, nenhum alvo cadastrado para scans, uma organização que aceita só clientes MCP verificados). A última tela mostra as instruções dos clientes escolhidos, a chave uma vez, três perguntas para fazer à IA primeiro e a observação da conexão, que acende quando o cliente chega ao gateway pela primeira vez. Uma regra para lembrar: quando o gateway tem ferramentas de ação, a página de login pergunta a cada pessoa se a IA também pode agir (iniciar scans, enviar código), marcado por padrão; uma chave não passa por essa página. O seu nível de proteção e as aprovações valem para os dois. Tudo o que ele configurou continua editável nas abas abaixo, e Guided edit no gateway reabre as mesmas perguntas com as respostas atuais: mostra o que mudaria antes de aplicar, mantém o que você ajustou à mão e nunca apaga uma regra ou uma chave.

Criar um gateway à mão

Em Overview & Gateways, selecione New gateway:

Deixe Start with secure default rules marcado em um gateway novo e ele já começa com cinco regras próprias em AI Guardian Policies: ferramentas destrutivas e escritas em alvos desconhecidos ou de alto risco esperam a aprovação de uma pessoa, resultados com instruções escondidas são retidos e segredos nos resultados são mascarados. Elas levam o nome do gateway e você pode editar, desligar ou apagar como qualquer outra regra. Gateways que já existem nunca mudam.

Depois marque as ferramentas que o gateway oferece. No cartão do gateway as ferramentas vêm em dobras, uma por módulo do WASViking (Web & API Security, Code Security e Supply Chain, Infrastructure Defense, Cloud Security, Certificados, Exposure Intelligence, as ferramentas de achados e postura que atravessam todos os módulos, e uma dobra por servidor que você mesmo adicionou): Turn reads on marca de uma vez todas as ferramentas de leitura aprovadas do módulo, uma ferramenta de escrita sempre mantém a própria caixa, e a busca encontra uma ferramenta em todas as dobras. Uma ferramenta só aparece para os agentes enquanto estiver aprovada na definição atual e com o servidor ativo.

Dê a cada pessoa as próprias ferramentas: toolkits

Um gateway pode listar as mesmas ferramentas para todos (Tool source: Tools enabled on this gateway, com grupos por ferramenta se quiser) ou dar a cada pessoa o próprio conjunto (Tool source: Toolkits assigned to each person). Um toolkit, na aba Toolkits, é um conjunto de ferramentas com limites:

• ferramentas escolhidas uma a uma, ou todas as de um servidor, de uma classe de ação ou cujo nome começa com um prefixo;
• a ação mais alta permitida (só leitura, leitura e escrita, ou destrutiva também);
• para uma ferramenta escolhida uma a uma, limites nos argumentos, por exemplo só o bucket dev-logs;
• se o próprio toolkit exige aprovação (para escritas, ou para toda chamada);
• uma janela de validade opcional e os gateways em que ele vale;
• quem recebe: grupos do diretório, pessoas ou chaves de gateway.

As pessoas continuam precisando da própria conexão nos servidores que usam a conta de cada pessoa, e as suas políticas continuam decidindo cada chamada. Dynamic Gateway mostra, para um gateway e uma pessoa ou chave, as ferramentas que ela recebe e por que não recebe as outras. Uma mudança em um toolkit, em um grupo, em uma revisão ou em uma conexão chega à lista da pessoa na próxima requisição.

Passo 5: conecte o cliente

Client Setup mostra o endpoint de cada gateway e a configuração exata para dois jeitos de conectar.

Pessoas: entre com a sua conta do WASViking. Adicione o endpoint sem nenhum cabeçalho. Para o Claude Code:

claude mcp add --transport http wasviking-engineering \
  https://api.wasviking.com/mcp-gateway/<gateway id>/mcp

Depois rode /mcp, escolha o servidor e Authenticate. O navegador abre o portal do WASViking: entre como de costume (SSO e MFA incluídos) e selecione Allow na página que mostra o cliente e o gateway. Quando o gateway tem ferramentas que mudam algo, essa página as oferece em uma caixa marcada por padrão: mantenha para o cliente agir sob as suas políticas e aprovações, ou desmarque para o cliente só ler (aí a primeira chamada de escrita pede que você permita o acesso, quando o cliente suporta isso). Para o Cursor (~/.cursor/mcp.json) ou o VS Code (.vscode/mcp.json), copie o bloco JSON da mesma aba.

Quem pode entrar

Duas portas abrem o login, e qualquer uma basta:

• Acesso MCP na Gestão de equipe (Users, coluna Acesso): um administrador define Portal e MCP ou MCP para a pessoa, ou a convida já com esse acesso. O WASViking então cria a identidade da pessoa no diretório do AI Guardian a partir da conta (origem "Portal account"). Voltar para Portal revoga na hora os logins e as chaves dela.
• Uma identidade no diretório do AI Guardian (SCIM, importação CSV, Google ou cadastro manual) com o mesmo e-mail da conta do portal, desde que nenhum administrador tenha definido a pessoa como Portal.

Toda conta começa como Portal, contas SSO incluídas. Quando nenhuma das portas está aberta, a página de login avisa e aponta para a Gestão de equipe.

Claude na web (claude.ai, Team e Enterprise)

O Claude na web conecta por um conector personalizado; os mesmos passos estão em Client Setup e na página My AI Tools de cada pessoa.

1. Configurações, Conectores, Adicionar conector personalizado. Nos planos Team e Enterprise um administrador da sua organização Claude faz isso uma vez em Admin settings, Connectors; as demais pessoas só conectam.
2. Dê o nome WASViking e cole o endereço do gateway como URL do servidor MCP remoto. Autenticação: Entrar agora. Cliente OAuth: Usar a identidade publicada do Claude (o Claude mostra como detectado). Sem cabeçalhos. Adicionar.
3. Abra o conector e selecione Vincular: o portal WASViking abre, entre como de costume e selecione Permitir. Quando o gateway tem ferramentas que mudam algo, a caixa dessa página vem marcada; desmarque para o conector só ler.
4. Em uma conversa nova, abra o menu de ferramentas e ligue o conector WASViking.
5. Nas Permissões de ferramentas do conector, o Claude deixa tudo em Requer aprovação por padrão, o que pergunta antes de cada chamada. Coloque as ferramentas somente leitura em Permitir sempre e deixe as que fazem alterações em Requer aprovação; as políticas e aprovações do gateway valem de qualquer forma.

Duas coisas para saber: o endereço precisa ser alcançável pela internet, porque quem o chama são os servidores do Claude e não o seu navegador (um endpoint local ou privado não funciona); e a identidade publicada do Claude conta como cliente verificado, então funciona mesmo quando a organização permite só clientes verificados, enquanto Registrar automaticamente cria um cliente por pessoa e é recusado nesse caso. Em Credentials & Access, Signed-in MCP clients a pessoa aparece com o cliente "Claude".

Automações: uma chave. Em Credentials & Access, crie uma chave para o gateway e escolha a quem ela pertence (uma pessoa ou uma conta de serviço). Copie a chave quando ela aparecer: ela é exibida uma única vez. Defina a chave como WASVIKING_MCP_KEY no ambiente do cliente e acrescente --header "Authorization: Bearer $WASVIKING_MCP_KEY" ao comando acima.

Em qualquer um dos jeitos, o agente vê só as ferramentas daquele gateway e cada chamada passa pelas suas políticas.

Para os funcionários: My AI Tools

Cada pessoa encontra as próprias ferramentas de IA em AI Guardian, Protection, My AI Tools. A página abre com os números dela (gateways, ferramentas que pode usar, contas ainda por conectar, clientes conectados) e tem uma aba por assunto:

• My Gateways: cada gateway em que ela recebe ferramentas, as ferramentas separadas em só leitura e que mudam algo, e a configuração em um clique: Add to Cursor, Install in VS Code e o comando do Claude Code. Sem chave: na primeira vez o cliente entra com a conta do WASViking da pessoa. O navegador pede permissão para abrir o Cursor ou o VS Code; escolha Open. Se nada abrir, Set up by hand traz a configuração para copiar.
• My Connections: servidores que agem com a conta de cada pessoa. Ela conecta, reconecta ou revoga a própria conta aqui. A aba mostra quantas ainda faltam conectar.
• Signed-in Clients: os clientes de IA que ela conectou, com Revoke.
• My Toolkits e Recent Activity: os toolkits que ela recebeu e as últimas chamadas de ferramentas (só metadados), com as recusadas em vermelho.

Quem só usa ferramentas de IA recebe o acesso MCP na Gestão de equipe (o mesmo que o papel AI Tools User): depois de entrar, a pessoa cai em My AI Tools e vê só as próprias páginas e as configurações da conta.

Quem entrou

Credentials & Access, Signed-in MCP clients lista cada cliente que uma pessoa conectou: o cliente, se ele é verificado, a pessoa, o gateway, o acesso (leitura, ou leitura e escrita), quando conectou e quando foi usado pela última vez. Revoke para o cliente na próxima requisição. Which MCP clients may sign in pode permitir só clientes verificados (clientes que publicam os próprios metadados ou são registrados pelo WASViking); escolher essa opção desconecta na hora os não verificados. Uma pessoa que sai do seu diretório perde o acesso na próxima requisição, e uma pessoa definida como Portal na Gestão de equipe perde na hora (um token de acesso já emitido dura até dez minutos).

A conta de cada pessoa em um servidor

Alguns servidores precisam ver a pessoa real, por exemplo um servidor de tickets ou de documentos que aplica as permissões de cada usuário. Em Credentials & Access, defina Whose account do servidor como Each person connects their own. Cada pessoa conecta a própria conta em Connections (servidores OAuth abrem a própria página de login); um administrador também pode conectar em nome de alguém, com um motivo registrado. Quem não conectou recebe o aviso para conectar e nada é executado. Connect organization account entra uma vez para o gateway poder ler as ferramentas do servidor.

Passo 6: crie as regras que importam

Em AI Guardian Policies, escolha onde uma regra se aplica: MCP Gateway: tool calls ou MCP Gateway: tool results. Entre as condições que você pode combinar estão a ferramenta, o servidor, a classe de ação, os dados encontrados nos argumentos, um sinal de ameaça e o risco do ativo. Regras comuns para começar:

• Bloquear ferramentas destrutivas (classe de ação destructive, ação Block).
• Exigir aprovação para escritas em ativos de risco (classe de ação write e risco do ativo no mínimo medium, ação Require approval).
• Permitir só ferramentas de leitura em um gateway (ação Allow read-only tools only).
• Reter resultados com instruções escondidas (ameaça instruction override em results, ação Quarantine the result).
• Mascarar dados pessoais nos resultados (classe de dado pii em results, ação Mask sensitive data in the result).
• Exigir aprovação quando a própria conta de quem chama está exposta (Caller identity risk no mínimo Medium, ação Require approval).

O risco do ativo vem dos seus próprios dados no WASViking. Quando um agente cita um bucket, um host, um domínio ou um repositório, o gateway procura esse item no Cloud Security, no Infrastructure Defense, na sua superfície de ataque, no Code Security, no Exposure Intelligence (vazamentos que citam o domínio) e no Supply Chain (componentes vulneráveis em aberto no projeto), e usa o ambiente, a exposição, os achados em aberto e os segredos expostos. Servidores adicionados pelo App Catalog podem dizer ao gateway quais argumentos indicam um recurso, e esses são procurados primeiro. Quando nada corresponde, ou os dados têm mais de sete dias, o risco é unknown, nunca seguro. Uma regra decide explicitamente o que acontece com alvos desconhecidos.

O Caller identity risk é sobre a pessoa por trás da chamada: High quando o e-mail de trabalho dela apareceu em um vazamento nos últimos 30 dias, Medium nos últimos 90, Low quando não há nenhum, e Unknown para chaves de uma conta de serviço.

Recursos e prompts

Com Resources and prompts em Offered and inspected like tool results, os agentes podem listar e ler os recursos (arquivos, páginas, registros) e os modelos de prompt dos servidores que dão ferramentas a eles naquele gateway, e nada além disso. Cada endereço de recurso começa com wasviking-mcp:// e cada nome de prompt com o identificador do servidor, então uma leitura sempre volta para o servidor certo. O conteúdo dos recursos e as mensagens dos prompts passam pelas mesmas inspeções e regras de resultado das ferramentas: instruções escondidas são retidas e segredos são mascarados. Modelos de prompt cujo próprio texto traz instruções para o agente não são oferecidos. Cada leitura aparece em Calls & Monitoring, em Resources and prompts.

Servidores stdio locais nos computadores dos funcionários

Quando um cliente de IA em um notebook roda um servidor MCP stdio, coloque-o atrás do gateway: no cliente, use isto como comando do servidor, com a chave da pessoa em WASVIKING_MCP_KEY:

wasviking-sentinel mcp run --gateway https://api.wasviking.com/mcp-gateway/<gateway id>/mcp \
  -- npx -y @acme/notes-server

O servidor real continua rodando no notebook e os argumentos ficam lá. O scanner do gateway confere as definições das ferramentas (ferramentas envenenadas não são oferecidas) e cada chamada espera as suas políticas, inclusive aprovações. Cada decisão aparece em Calls & Monitoring. Sem resposta do gateway, nada roda.

Aprovações

Quando uma regra exige aprovação, o agente recebe uma mensagem com o id da solicitação e nada é executado. A solicitação aparece em Approvals & Exceptions com a ferramenta, o alvo, os argumentos mascarados e os fatos de risco que a política usou. Alguém diferente de quem pediu aprova ou nega. Depois da aprovação, o agente repete exatamente a mesma chamada dentro da janela de aprovação e ela é executada uma vez. Uma chamada diferente, ou uma segunda repetição, precisa de nova aprovação.

Inscreva um canal em AI Guardian Approval Requested em Alert destinations para que os aprovadores fiquem sabendo.

Leia o registro de chamadas

Calls & Monitoring lista cada chamada de ferramenta com quem chamou (e o cliente com que a pessoa entrou), a ferramenta, a decisão, o risco do ativo e a regra. Selecione uma linha para ver o detalhe: os ativos encontrados, as classes de dados nos argumentos e no resultado, os sinais de ameaça, o id da aprovação e o trace id, de onde os alvos foram lidos (dicas do catálogo ou os argumentos) e a exposição de quem chamou. Argumentos e resultados nunca são guardados, só as classes e uma impressão digital.

Quando um agente envia o contexto de trace (traceparent no _meta da requisição ou no header HTTP), a chamada guarda esse trace id, marcado "from the client", e o servidor da ferramenta recebe o mesmo trace, então um único trace acompanha a chamada de ponta a ponta.

Notificações de mudança e saúde dos servidores

Onde a WASViking ligou as notificações de mudança, os clientes MCP que escutam mudanças ficam sabendo em cerca de um segundo que a lista de ferramentas mudou (ferramenta habilitada ou removida, mudança de toolkit ou de grupo, revisão, quarentena, conexão) e em cerca de 30 segundos depois de uma mudança de política. Clientes que não escutam continuam atualizando a lista a cada minuto. Um cliente cujo acesso termina (chave revogada, login revogado, pessoa desativada, gateway desligado) perde o canal de notificações na verificação seguinte.

Para proteger os servidores atrás do gateway, as chamadas têm limites por pessoa, por servidor e por ferramenta, e cada servidor tem um máximo de chamadas ao mesmo tempo. Quando um servidor para de responder, o gateway pausa as chamadas para ele por 30 segundos em vez de deixar cada chamada esperando, e depois tenta uma chamada; quando ela funciona, o tráfego volta. O agente recebe uma mensagem clara em cada caso e nada é executado.

Calls & Monitoring abre com Server health das últimas 24 horas: chamadas, erros e recusas por servidor, o tempo mediano e o percentil 95, se o servidor está respondendo, pausado ou se recuperando, as chamadas em andamento e as ferramentas mais usadas. Também mostra se as notificações de mudança estão ligadas e quantos clientes estão escutando. Connections lista cada canal de notificações com quanto tempo ficou aberto e por que terminou.

Uso e limites

O seu contrato define quantas chamadas de ferramentas a organização faz nos últimos 30 dias e quantas identidades ativas ela tem no mesmo período. Uma identidade ativa é uma pessoa, ou uma chave de agente, com pelo menos uma chamada. O contrato também define as conexões simultâneas da organização: chamadas de ferramentas esperando um servidor ao mesmo tempo. Um painel logo abaixo do cabeçalho da tela MCP Gateway mostra o uso frente ao contrato, e a aba AI Guardian de Profile & Plan Usage traz os mesmos números em um cartão por módulo.

• Os avisos saem em 80% e em 100% do contrato, para os destinos de alerta inscritos em AI Guardian Usage e por e-mail para os administradores da organização.
• Acima do contrato nada é cobrado automaticamente e a proteção nunca para: toda decisão continua valendo. As chamadas permitidas sem nenhum achado (nenhuma regra, detecção, redação, máscara, aprovação ou erro) deixam de ser registradas enquanto o uso continuar acima.
• Depois de 30 dias acima do contrato, novas chaves do MCP Gateway e novos logins MCP esperam até a capacidade ser aumentada. As chaves e os logins existentes continuam funcionando, e a espera acaba assim que a capacidade é aumentada. Enquanto o uso está acima, o painel mostra a data a partir da qual novas chaves e novos logins passariam a esperar.
• Uma chamada de ferramenta nova acima das conexões simultâneas é respondida na hora com "Too many tool calls are running at once for your organization. Try again in a moment." e nada é executado. As chamadas que já estão rodando nunca são cortadas.

Quem aumenta a capacidade é o seu parceiro WASViking, ou a equipe comercial da WASViking se você compra direto. Se a sua organização recebeu o MCP Gateway como um trial de 60 dias quando os módulos foram empacotados, o painel também mostra a data em que o trial termina.

Solução de problemas

Próximos passos

• Proteja chamadas a APIs de modelos com o AI Gateway.
• Rode o AI Security Testing, suíte Your policies, para ver quais casos de risco as suas regras barram e quais deixam passar.
• Inscreva um canal em AI Guardian MCP Tool Changed para saber quando um servidor alterar ou envenenar uma ferramenta.