Passer au contenu principal
Les agents modernes installent des capacités à la volée : un skill depuis un registre, un serveur MCP communautaire, un plugin depuis une URL. Chacun livre un manifeste, un ensemble d’outils et un ensemble de permissions demandées — et chacun est un risque de chaîne d’approvisionnement dès l’instant où un agent le charge. Un skill qui demande discrètement shell.exec et une portée réseau externe est exactement le genre de chose qui devrait être passé en revue avant de s’exécuter, pas découvert dans un incident. La gouvernance des Skills du Firewall est cette revue. Chaque capacité installable est enregistrée comme un enregistrement à portée d’espace de travail, scannée par un moteur de risque déterministe, assignée à une bande de risque et un mode d’application, et — à l’exécution — ce mode se superpose aux verdicts de règles du firewall.

​
1. Ce qu’est un « skill » ici

Un enregistrement de skill est une capacité d’agent installable. Un modèle unique généralise trois types afin qu’un seul plan de scan, de scoring et d’approbation gouverne tout ce qu’un agent s’auto-installe :
TypeCe que c’est
skillUne capacité packagée — un manifeste plus un ensemble d’outils et un fragment de prompt système.
mcp_serverUn serveur MCP bring-your-own enregistré comme un artefact gouverné.
pluginUne extension de type plugin.
Chaque enregistrement a aussi une source — builtin, registry, private, byo_mcp, ou auto_detected — qui alimente l’évaluation de confiance.

​
2. Le scanner

À l’enregistrement (et à la demande), le scanner exécute un ensemble de passes déterministes et sans dépendance sur le manifeste et les portées déclarées. Chaque passe émet des findings avec une sévérité de info, warn, ou error :
PasseSignaleSévérité
prompt_injectionTexte du manifeste qui tente d’outrepasser les instructions (ignore previous instructions, you are now, un system: en tête…).warn
tool_creepNoms d’outils que le manifeste utilise mais qu’il n’a pas déclarés dans allowed_tools.error
network_egressHôtes HTTP(S) dans le manifeste qui ne sont pas approuvés dans les portées réseau du skill.warn
fs_write_unsafeUne portée de système de fichiers en mode écriture sur un chemin hors de /tmp (traversal-safe).error
data_scopePortées de données sensibles (pii, financial, customer).info
unsignedUn skill registry sans signature.warn
Les findings s’agrègent en un verdict de scan : tout error → blocked ; sinon tout warn → flagged ; sinon clean.

​
3. Score de risque & bandes

Les mêmes findings alimentent un score de risque déterministe (0–100, additif avec des plafonds par catégorie). Les contributeurs les plus lourds sont des capacités dangereuses :
CapacitéPoids
Exécution shell+30
Eval de code arbitraire+30
Écriture sur le système de fichiers hors de /tmp+25
Lecture de secrets+25
Egress réseau externe+20
Les findings de tool-creep, prompt-injection, egress et data-scope s’ajoutent par-dessus (chacun plafonné), un skill de registre non signé ajoute +15, et les mitigations soustraient — un skill signé vaut −10, un manifeste sans finding d’erreur −5. Le score se mappe à une bande :
BandeScore
low0–25
medium26–50
high51–75
critical76–100
Ces poids sont épinglés par un test garde-dérive — ils ne bougent pas sans un changement de spec délibéré, de sorte qu’une bande signifie la même chose à travers chaque espace de travail.

​
4. Mode d’application

La bande et le verdict dérivent ensemble un mode d’application — ce que le firewall fait réellement quand un outil appartenant à ce skill est appelé :
ModeEffet à l’exécution
allowLe skill n’impose rien de propre ; les verdicts de règles décident.
quarantineEscalade tout ce qui est en-deçà d’un deny vers pending_approval — les outils du skill ne s’exécutent qu’après l’approbation d’un humain.
blockForce un deny sur les outils du skill.
La dérivation prend le plus strict de deux signaux : la bande (low/medium → allow, high → quarantine, critical → block) et le verdict de scan (blocked → block, flagged → quarantine). Un seul finding error qui rend le verdict blocked mettra en quarantaine ou bloquera même lorsque la bande numérique est low — la direction prudente. Un opérateur peut définir le mode explicitement ; sur un re-scan, le mode ne fait jamais que se resserrer, sans jamais relâcher un block ou une quarantine que vous avez définis.

​
5. Signaux de confiance

Deux signaux au-delà du scan statique informent la façon dont un skill est traité :
  • Éditeurs signés. Un skill portant une signature d’un éditeur de confiance est traité comme plus digne de confiance (la mitigation de signature abaisse son score de risque) ; un skill de registre non signé est pénalisé. Vous gérez quels éditeurs votre espace de travail considère de confiance.
  • Réputation de ressource. La position d’un skill peut être ajustée par son comportement en direct au fil du temps — les refus et les anomalies élèvent son risque, les séries propres l’abaissent — de sorte qu’un artefact qui se comporte mal en production dérive vers la quarantaine même si son manifeste a scanné propre.

​
6. Capacités auto-détectées

Le scanner ne s’exécute pas seulement quand vous enregistrez quelque chose à la main. Lorsqu’un agent s’auto-installe une capacité et que ses outils franchissent la passerelle pour la première fois, le Firewall l’auto-détecte (hors du chemin à chaud, de manière asynchrone), synthétise un manifeste à partir de ce qu’il a observé, et exécute le même scan, score et dérivation de mode — avec source = auto_detected.
Les capacités auto-détectées sont mises en quarantaine jusqu’à revue. Tout ce qui est auto-détecté et qui se résoudrait autrement à allow est plancher-né à quarantine (et critical reste block) jusqu’à ce qu’un humain le passe en revue. Une capacité que personne n’a approuvée n’obtient pas un passe-droit juste parce qu’elle a scanné bénin — elle ne s’exécute qu’après que vous l’ayez regardée.

​
7. Application à l’exécution

Lorsqu’un appel d’outil atteint le moteur de firewall, il est attribué à un skill propriétaire, puis le mode du skill est appliqué par-dessus le verdict de règle :
  1. Attribution. L’appel est mis en correspondance avec un skill par ses allowed_tools déclarés, puis par le préfixe de namespace mcp_server, puis par un repli appliquant le plus restrictif à l’échelle de l’espace de travail.
  2. Verdict de règle. Les règles de la politique s’exécutent comme d’habitude — et le skill_name_glob d’une règle vous permet de scoper une règle à des skills spécifiques.
  3. Override de mode. Un skill block force un deny ; un skill quarantine escalade tout ce qui est en-deçà d’un deny vers pending_approval ; allow laisse le verdict intact.
L’attribution de skill fail closed. Si un outil ne peut pas être attribué (une erreur de BD sans cache, ou un outil non déclaré sous une source curatée), l’appel est mis en attente de revue plutôt qu’autorisé. Et le mode de skill est indépendant du mode shadow — un skill en quarantaine ou bloqué est toujours appliqué même pendant qu’une politique est en déploiement shadow.

​
8. Cycle de vie

  • Enregistrer — POST /skills valide et scanne de manière synchrone, en renvoyant le skill plus ses findings et son verdict. Le mode est dérivé (ou votre mode explicite est honoré).
  • Mettre à jour — re-scanne le nouveau manifeste ; le mode se resserre sur un scan aggravé mais ne relâche jamais votre block/quarantine stocké.
  • Re-scanner — POST /skills/:id/rescan ré-exécute le scan ; si le verdict se dégrade nouvellement en flagged ou blocked, il émet un événement firewall afin que la dérive apparaisse dans votre flux.
  • Supprimer — supprime en douceur et libère le créneau de nom pour ré-enregistrement.

​
Référence API

À portée d’espace de travail ; les lectures de liste sont ouvertes à tout membre (et redactent les champs porteurs de secrets), tout le reste nécessite Developer+.
Méthode & cheminRôleObjectif
GET /api/workspace/firewall/skillsMemberLister les skills (redacté ; filtrer par ?kind= et ?source=).
GET /api/workspace/firewall/skills/:idDeveloper+Enregistrement complet du skill.
POST /api/workspace/firewall/skillsDeveloper+Enregistrer + scanner (409 sur nom dupliqué).
PUT /api/workspace/firewall/skills/:idDeveloper+Mettre à jour + re-scanner.
POST /api/workspace/firewall/skills/:id/rescanDeveloper+Re-scanner ; émet un événement en cas de dégradation.
DELETE /api/workspace/firewall/skills/:idDeveloper+Suppression douce.
Un enregistrement/mise à jour/re-scan renvoie : 
{
  "skill": { "id": 7, "name": "creepy", "risk_band": "high", "mode": "quarantine", "...": "..." },
  "findings": [
    { "kind": "tool_creep", "target": "shell.exec", "severity": "error" }
  ],
  "scan_verdict": "blocked"
}
Les noms sont uniques par espace de travail à travers les types — un skill nommé github et un mcp_server nommé github entrent en collision dans le même espace de travail. Choisissez des noms distincts par artefact.

​
FAQ

Les Règles verrouillent les appels d’outils par nom et arguments. Les Skills verrouillent les capacités qu’un agent charge — le package, son manifeste et ses permissions demandées — avant qu’aucun de ses outils ne s’exécute. Le mode du skill se superpose ensuite à ce que les règles décident, donc les deux se composent : une règle peut allow http.fetch en général tandis qu’un skill en quarantaine qui le possède reste mis en attente.
Plusieurs choses. La détection de tool-creep signale les outils utilisés mais non déclarés ; l’auto-détection re-scanne à partir de ce qui a réellement franchi la passerelle, pas seulement le manifeste revendiqué ; le mode se resserre (et non se relâche) au re-scan ; la réputation de ressource fait dériver un artefact qui se comporte mal vers la quarantaine au fil du temps ; et l’attribution fail closed lorsqu’un outil ne peut pas être rattaché à un skill déclaré.
Non. Enregistrez ceux que vous voulez pré-approuver ; le reste est auto-détecté à la première utilisation et mis en quarantaine jusqu’à ce que vous le passiez en revue. Activez le mode observe pour faire remonter tout ce qu’un agent installe sans bloquer, puis resserrez à partir de données réelles.

​
Voir aussi

Vous souhaitez approfondir la sécurité des agents ? Les guides Sécurisez vos agents (Zero Trust) replacent cette fonctionnalité dans un workflow zero-trust.

Référence de base Secure Agents

Appliquez une posture zero-trust à chaque capacité d’agent en un seul commutateur.

Guardrails agentiques

Des guardrails conçus pour les agents autonomes utilisant des outils.