Vai al contenuto principale
Gli agent moderni installano capability al volo: una skill da un registry, un MCP server della community, un plugin da un URL. Ognuno porta con sé un manifest, un insieme di tool e un insieme di permessi richiesti — e ognuno è un rischio di supply-chain nel momento in cui un agent lo carica. Una skill che chiede di nascosto shell.exec e uno scope di rete esterna è esattamente il genere di cosa che dovrebbe essere revisionata prima che giri, non scoperta in un incidente. La governance delle Skill del Firewall è quella revisione. Ogni capability installabile viene registrata come un record con scope a livello di workspace, scansionata da un motore di rischio deterministico, alla quale vengono assegnate una banda di rischio e una modalità di applicazione, e — a runtime — quella modalità si sovrappone ai verdetti delle regole del firewall.

​
1. Cos’è una “skill” qui

Un record di skill è una capability di agent installabile. Un singolo modello generalizza tre tipi così che un unico piano di scansione, scoring e approvazione governi tutto ciò che un agent auto-installa:
TipoCos’è
skillUna capability impacchettata — un manifest più un insieme di tool e un frammento di system-prompt.
mcp_serverUn MCP server bring-your-own registrato come artefatto governato.
pluginUn’estensione in stile plugin.
Ogni record ha anche una source — builtin, registry, private, byo_mcp o auto_detected — che alimenta la valutazione di fiducia.

​
2. Lo scanner

Alla registrazione (e su richiesta), lo scanner esegue un insieme di passate deterministiche e prive di dipendenze sul manifest e sugli scope dichiarati. Ogni passata emette finding con una severità di info, warn o error:
PassataSegnalaSeverità
prompt_injectionTesto del manifest che tenta di sovrascrivere le istruzioni (ignore previous instructions, you are now, un system: iniziale…).warn
tool_creepNomi di tool che il manifest usa ma non ha dichiarato in allowed_tools.error
network_egressHost HTTP(S) nel manifest che non sono approvati negli scope di rete della skill.warn
fs_write_unsafeUno scope di filesystem in modalità write su un path fuori da /tmp (traversal-safe).error
data_scopeScope di dati sensibili (pii, financial, customer).info
unsignedUna skill registry senza firma.warn
I finding si aggregano in un verdetto di scansione: qualsiasi error → blocked; altrimenti qualsiasi warn → flagged; altrimenti clean.

​
3. Punteggio di rischio e bande

Gli stessi finding alimentano un punteggio di rischio deterministico (0–100, additivo con tetti per categoria). I contributori più pesanti sono le capability pericolose:
CapabilityPeso
Esecuzione shell+30
Eval di codice arbitrario+30
Scrittura su filesystem fuori da /tmp+25
Lettura di segreti+25
Egress di rete esterna+20
I finding di tool-creep, prompt-injection, egress e data-scope si aggiungono in cima (ciascuno con tetto), una skill registry non firmata aggiunge +15, e le mitigazioni sottraggono — una skill firmata è −10, un manifest senza finding di error −5. Il punteggio mappa su una banda:
BandaPunteggio
low0–25
medium26–50
high51–75
critical76–100
Questi pesi sono fissati da un test drift-guard — non si muovono senza una modifica deliberata della spec, così una banda significa la stessa cosa in ogni workspace.

​
4. Modalità di applicazione

La banda e il verdetto insieme derivano una modalità di applicazione — cosa fa effettivamente il firewall quando viene chiamato un tool di proprietà di questa skill:
ModalitàEffetto a runtime
allowLa skill non impone nulla di proprio; decidono i verdetti delle regole.
quarantineEscala qualsiasi cosa al di sotto di un deny a pending_approval — i tool della skill girano solo dopo che un umano approva.
blockForza un deny sui tool della skill.
La derivazione prende il più severo di due segnali: la banda (low/medium → allow, high → quarantine, critical → block) e il verdetto di scansione (blocked → block, flagged → quarantine). Un singolo finding di error che rende il verdetto blocked metterà in quarantine-or-block anche quando la banda numerica è low — la direzione cauta. Un operatore può impostare la modalità esplicitamente; a una ri-scansione la modalità si stringe sempre solo più stretta, senza mai allentare un block o un quarantine che hai impostato.

​
5. Segnali di fiducia

Due segnali oltre la scansione statica informano come una skill viene trattata:
  • Publisher firmati. Una skill che porta una firma da un publisher fidato viene trattata come più affidabile (la mitigazione di firma abbassa il suo punteggio di rischio); una skill registry non firmata viene penalizzata. Gestisci tu quali publisher il tuo workspace si fida.
  • Reputazione delle risorse. La posizione di una skill può essere aggiustata dal suo comportamento live nel tempo — i deny e le anomalie alzano il suo rischio, le serie pulite lo abbassano — così un artefatto che si comporta male in produzione deriva verso la quarantine anche se il suo manifest ha scansionato pulito.

​
6. Capability auto-rilevate

Lo scanner non gira solo quando registri qualcosa a mano. Quando un agent auto-installa una capability e i suoi tool attraversano per la prima volta il gateway, il Firewall la auto-rileva (fuori dall’hot path, in modo asincrono), sintetizza un manifest da ciò che ha osservato, ed esegue la stessa scansione, scoring e derivazione di modalità — con source = auto_detected.
Le capability auto-rilevate sono in quarantine finché non vengono revisionate. Qualsiasi cosa auto-rilevata che altrimenti si risolverebbe in allow viene portata al pavimento di quarantine (e critical resta block) finché un umano non la revisiona. Una capability che nessuno ha approvato non ottiene un lasciapassare solo perché ha scansionato benigna — gira solo dopo che ci hai guardato.

​
7. Applicazione a runtime

Quando una chiamata a tool raggiunge il motore del firewall, viene attribuita a una skill proprietaria, poi la modalità della skill viene applicata in aggiunta al verdetto della regola:
  1. Attribuzione. La chiamata viene abbinata a una skill tramite i suoi allowed_tools dichiarati, poi tramite il prefisso di namespace mcp_server, poi tramite un fallback applicativo più restrittivo a livello di workspace.
  2. Verdetto della regola. Le regole della policy girano come al solito — e lo skill_name_glob di una regola ti permette di dare scope a una regola su skill specifiche.
  3. Override di modalità. Una skill block forza un deny; una skill quarantine escala qualsiasi cosa al di sotto di deny a pending_approval; allow lascia il verdetto intatto.
L’attribuzione delle skill fa fail closed. Se un tool non può essere attribuito (un errore del DB senza cache, o un tool non dichiarato sotto una source curata), la chiamata viene messa in attesa per revisione anziché consentita. E la modalità della skill è indipendente dalla shadow mode — una skill in quarantine o bloccata è comunque applicata anche mentre una policy è in rollout shadow.

​
8. Ciclo di vita

  • Register — POST /skills valida e scansiona in modo sincrono, restituendo la skill più i suoi finding e il verdetto. La modalità viene derivata (o la tua modalità esplicita viene onorata).
  • Update — ri-scansiona il nuovo manifest; la modalità si stringe più stretta su una scansione peggiorata ma non allenta mai il block/quarantine memorizzato.
  • Rescan — POST /skills/:id/rescan riesegue la scansione; se il verdetto degrada di nuovo a flagged o blocked emette un evento del firewall così il drift compare nel tuo feed.
  • Delete — soft-delete e libera lo slot del nome per la ri-registrazione.

​
Riferimento API

Con scope a livello di workspace; le letture di elenco sono aperte a ogni membro (e redigono i campi che portano segreti), tutto il resto richiede Developer+.
Metodo & pathRuoloScopo
GET /api/workspace/firewall/skillsMemberElenca le skill (redatte; filtra per ?kind= e ?source=).
GET /api/workspace/firewall/skills/:idDeveloper+Record completo della skill.
POST /api/workspace/firewall/skillsDeveloper+Register + scan (409 su nome duplicato).
PUT /api/workspace/firewall/skills/:idDeveloper+Update + ri-scansione.
POST /api/workspace/firewall/skills/:id/rescanDeveloper+Ri-scansione; emette un evento su degrado.
DELETE /api/workspace/firewall/skills/:idDeveloper+Soft-delete.
Un register/update/rescan restituisce: 
{
  "skill": { "id": 7, "name": "creepy", "risk_band": "high", "mode": "quarantine", "...": "..." },
  "findings": [
    { "kind": "tool_creep", "target": "shell.exec", "severity": "error" }
  ],
  "scan_verdict": "blocked"
}
I nomi sono unici per workspace tra i tipi — una skill chiamata github e un mcp_server chiamato github collidono nello stesso workspace. Scegli nomi distinti per artefatto.

​
FAQ

Le Regole mettono sotto controllo le chiamate a tool per nome e argomenti. Le Skill mettono sotto controllo le capability che un agent carica — il package, il suo manifest e i suoi permessi richiesti — prima che qualsiasi suo tool giri. La modalità della skill si sovrappone poi a qualunque cosa decidano le regole, così le due si compongono: una regola può fare allow su http.fetch in generale mentre una skill in quarantine che lo possiede viene comunque messa in attesa.
Diverse cose. La detection di tool-creep segnala i tool usati ma non dichiarati; l’auto-detection ri-scansiona da ciò che ha effettivamente attraversato il gateway, non solo il manifest dichiarato; la modalità si stringe più stretta (non più larga) alla ri-scansione; la reputazione delle risorse fa derivare nel tempo un artefatto che si comporta male verso la quarantine; e l’attribuzione fa fail closed quando un tool non può essere legato a una skill dichiarata.
No. Registra quelle che vuoi pre-approvare; le altre vengono auto-rilevate al primo uso e messe in quarantine finché non le revisioni. Attiva l’observe mode per far emergere tutto ciò che un agent installa senza bloccare, poi stringi a partire dai dati reali.

​
Vedi anche

Vuoi approfondire la sicurezza degli agent? Le guide Proteggi i tuoi agenti (Zero Trust) inseriscono questa feature in un workflow zero-trust.

Baseline Secure Agents

Applica una postura zero-trust a ogni capability dell’agent con un unico switch.

Guardrail agentici

Guardrail progettati per agent autonomi che usano tool.