Saltar para o conteúdo principal
Agentes modernos instalam capacidades na hora: uma skill de um registro, um servidor MCP da comunidade, um plugin de uma URL. Cada uma entrega um manifesto, um conjunto de ferramentas e um conjunto de permissões solicitadas — e cada uma é um risco de cadeia de suprimentos no momento em que um agente a carrega. Uma skill que silenciosamente pede shell.exec e um escopo de rede externo é exatamente o tipo de coisa que deveria ser revisada antes de rodar, não descoberta em um incidente. A governança de Skills do Firewall é essa revisão. Cada capacidade instalável é registrada como um registro com escopo de workspace, escaneada por um motor de risco determinístico, recebe uma faixa de risco e um modo de enforcement, e — em runtime — esse modo anda por cima dos vereditos de regra do firewall.

​
1. O que é uma “skill” aqui

Um registro de skill é uma capacidade instalável de agente. Um único modelo generaliza três tipos para que um plano de escaneamento, pontuação e aprovação governe tudo o que um agente autoinstala:
TipoO que é
skillUma capacidade empacotada — um manifesto mais um conjunto de ferramentas e um fragmento de system-prompt.
mcp_serverUm servidor MCP bring-your-own registrado como um artefato governado.
pluginUma extensão estilo plugin.
Cada registro também tem uma fonte — builtin, registry, private, byo_mcp ou auto_detected — que alimenta a avaliação de confiança.

​
2. O scanner

No registro (e sob demanda), o scanner roda um conjunto de passes determinísticos e sem dependências sobre o manifesto e os escopos declarados. Cada pass emite findings com uma severidade de info, warn ou error:
PassSinalizaSeveridade
prompt_injectionTexto de manifesto que tenta sobrescrever instruções (ignore previous instructions, you are now, um system: no início…).warn
tool_creepNomes de ferramenta que o manifesto usa mas não declarou em allowed_tools.error
network_egressHosts HTTP(S) no manifesto que não estão aprovados nos escopos de rede da skill.warn
fs_write_unsafeUm escopo de filesystem em modo de escrita em um path fora de /tmp (traversal-safe).error
data_scopeEscopos de dados sensíveis (pii, financial, customer).info
unsignedUma skill registry sem assinatura.warn
Os findings se consolidam em um veredito de scan: qualquer error → blocked; caso contrário qualquer warn → flagged; caso contrário clean.

​
3. Score de risco & faixas

Os mesmos findings alimentam um score de risco determinístico (0–100, aditivo com tetos por categoria). Os contribuidores mais pesados são capacidades perigosas:
CapacidadePeso
Execução de shell+30
Eval de código arbitrário+30
Escrita no filesystem fora de /tmp+25
Leitura de segredos+25
Egress de rede externo+20
Findings de tool-creep, prompt-injection, egress e data-scope se somam por cima (cada um com teto), uma skill de registry sem assinatura adiciona +15, e mitigações subtraem — uma skill assinada é −10, um manifesto sem findings de erro −5. O score mapeia para uma faixa:
FaixaScore
low0–25
medium26–50
high51–75
critical76–100
Esses pesos são fixados por um teste de drift-guard — eles não se movem sem uma mudança deliberada de spec, então uma faixa significa a mesma coisa em todo workspace.

​
4. Modo de enforcement

A faixa e o veredito juntos derivam um modo de enforcement — o que o firewall de fato faz quando uma ferramenta de propriedade desta skill é chamada:
ModoEfeito em runtime
allowA skill não impõe nada de próprio; os vereditos de regra decidem.
quarantineEscala qualquer coisa aquém de um deny para pending_approval — as ferramentas da skill rodam apenas depois que um humano aprova.
blockForça um deny nas ferramentas da skill.
A derivação toma o mais estrito de dois sinais: a faixa (low/medium → allow, high → quarantine, critical → block) e o veredito de scan (blocked → block, flagged → quarantine). Um único finding de error que torna o veredito blocked irá quarantine-or-block mesmo quando a faixa numérica é low — a direção cautelosa. Um operador pode definir o modo explicitamente; em um re-scan o modo só aperta mais, nunca relaxando um block ou quarantine que você definiu.

​
5. Sinais de confiança

Dois sinais além do scan estático informam como uma skill é tratada:
  • Publicadores assinados. Uma skill carregando uma assinatura de um publicador confiável é tratada como mais confiável (a mitigação de assinatura reduz seu score de risco); uma skill de registry sem assinatura é penalizada. Você gerencia quais publicadores seu workspace confia.
  • Reputação de recurso. O standing de uma skill pode ser ajustado por seu comportamento ao vivo ao longo do tempo — negações e anomalias elevam seu risco, sequências limpas o reduzem — de modo que um artefato que se comporta mal em produção deriva em direção à quarentena mesmo se seu manifesto escaneou limpo.

​
6. Capacidades auto-detectadas

O scanner não roda apenas quando você registra algo manualmente. Quando um agente autoinstala uma capacidade e suas ferramentas cruzam o gateway pela primeira vez, o Firewall a auto-detecta (fora do caminho quente, assincronamente), sintetiza um manifesto a partir do que observou, e roda o mesmo scan, score e derivação de modo — com source = auto_detected.
Capacidades auto-detectadas ficam em quarentena até serem revisadas. Qualquer coisa auto-detectada que de outra forma resolveria para allow é rebaixada para quarantine (e critical permanece block) até que um humano a revise. Uma capacidade que ninguém aprovou não recebe um passe livre só porque escaneou benigna — ela roda apenas depois que você a examinou.

​
7. Enforcement em runtime

Quando uma chamada de ferramenta chega ao motor do firewall, ela é atribuída a uma skill proprietária, e então o modo da skill é aplicado por cima do veredito da regra:
  1. Atribuição. A chamada é correspondida a uma skill por seus allowed_tools declarados, depois pelo prefixo de namespace mcp_server, depois por um fallback de enforcement mais-restritivo de todo o workspace.
  2. Veredito da regra. As regras da política rodam como de costume — e o skill_name_glob de uma regra permite que você dê escopo a uma regra para skills específicas.
  3. Override de modo. Uma skill block força um deny; uma skill quarantine escala qualquer coisa aquém de deny para pending_approval; allow deixa o veredito intocado.
A atribuição de skill falha fechado. Se uma ferramenta não pode ser atribuída (um erro de DB sem cache, ou uma ferramenta não declarada sob uma fonte curada), a chamada é retida para revisão em vez de permitida. E o modo de skill é independente do shadow mode — uma skill em quarentena ou bloqueada ainda é aplicada mesmo enquanto uma política está em rollout de shadow.

​
8. Ciclo de vida

  • Register — POST /skills valida e escaneia sincronamente, retornando a skill mais seus findings e veredito. O modo é derivado (ou seu modo explícito é honrado).
  • Update — re-escaneia o novo manifesto; o modo aperta mais em um scan piorado mas nunca relaxa seu block/quarantine armazenado.
  • Rescan — POST /skills/:id/rescan re-roda o scan; se o veredito recém degrada para flagged ou blocked, ele emite um evento de firewall para que o drift apareça no seu feed.
  • Delete — soft-delete e libera o slot de nome para re-registro.

​
API reference

Escopo de workspace; leituras de lista são abertas a qualquer membro (e redigem campos que carregam segredos), todo o resto exige Developer+.
Método & pathPapelPropósito
GET /api/workspace/firewall/skillsMemberLista skills (redigidas; filtre por ?kind= e ?source=).
GET /api/workspace/firewall/skills/:idDeveloper+Registro completo da skill.
POST /api/workspace/firewall/skillsDeveloper+Registra + escaneia (409 em nome duplicado).
PUT /api/workspace/firewall/skills/:idDeveloper+Atualiza + re-escaneia.
POST /api/workspace/firewall/skills/:id/rescanDeveloper+Re-escaneia; emite um evento em degradação.
DELETE /api/workspace/firewall/skills/:idDeveloper+Soft-delete.
Um register/update/rescan retorna: 
{
  "skill": { "id": 7, "name": "creepy", "risk_band": "high", "mode": "quarantine", "...": "..." },
  "findings": [
    { "kind": "tool_creep", "target": "shell.exec", "severity": "error" }
  ],
  "scan_verdict": "blocked"
}
Os nomes são únicos por workspace entre tipos — uma skill chamada github e um mcp_server chamado github colidem no mesmo workspace. Escolha nomes distintos por artefato.

​
FAQ

As Regras gateiam chamadas de ferramenta por nome e argumentos. As Skills gateiam as capacidades que um agente carrega — o pacote, seu manifesto e suas permissões solicitadas — antes que qualquer uma de suas ferramentas rode. O modo da skill então anda por cima do que quer que as regras decidam, então os dois se compõem: uma regra pode dar allow a http.fetch em geral enquanto uma skill em quarentena que o possui ainda é retida.
Várias coisas. A detecção de tool-creep sinaliza ferramentas usadas mas não declaradas; a auto-detecção re-escaneia a partir do que de fato cruzou o gateway, não apenas o manifesto alegado; o modo aperta mais (não menos) em um re-scan; a reputação de recurso deriva um artefato que se comporta mal em direção à quarentena ao longo do tempo; e a atribuição falha fechado quando uma ferramenta não pode ser vinculada a uma skill declarada.
Não. Registre as que você quer pré-aprovar; o resto é auto-detectado no primeiro uso e colocado em quarentena até você revisá-las. Ligue o observe mode para revelar tudo o que um agente instala sem bloquear, depois aperte a partir de dados reais.

​
Veja também

Aprofundando-se em segurança de agentes? Os guias Proteja seus agentes (Zero Trust) colocam este recurso em um fluxo de trabalho zero-trust.

Baseline de Agentes Seguros

Aplique uma postura zero-trust a cada capacidade de agente com um único interruptor.

Guardrails agênticos

Guardrails construídos para agentes autônomos que usam ferramentas.