AgentGate : j'ai construit la porte entre les agents IA et Splunk

Splunk a livré six capacités agentic en douze mois : Triage Agent, Investigation Agent, Malware Reversal Agent, AI Playbook Authoring, AI Assistant for SPL et Foundation-Sec-8B. Chacune peut lire vos données, proposer des changements et de plus en plus les exécuter. Aucune ne répond à la question que pose la conformité : qui a approuvé cette action et quel était son rayon d'impact ?

Le problème nommé par le responsable IA de Splunk lui-même

Le résultat le plus probable, c'est que les équipes conformité et gouvernance bloquent la mise en production de l'application. — Jeff Wiedemann, Global AI Partner Technical Leader, Splunk (entrevue vidéo CIO)

Si le responsable IA chez l'éditeur de la plateforme nomme la conformité comme le goulot d'étranglement de la mise en production, c'est ce goulot qu'il faut construire pour. AgentGate est la moitié pré-action de la traçabilité que la conformité réclame. Le tableau MCP Telemetry Dashboard de Splunk (mai 2026) et MCP Watch sur Splunkbase auditent l'activité des agents APRÈS coup. AgentGate la contrôle AVANT.

Ce qu'il fait

AgentGate intercepte chaque appel d'outil qu'un agent fait contre Splunk et exécute cinq étapes de portail déterministes plus une étape de raisonnement consultative. Les étapes déterministes décident ; l'étape de raisonnement explique.

• Étape 1 : Détection d'injection de prompt. Un scan heuristique + normalisé contre l'obfuscation sur les entrées d'outil et le contexte (lignes de log) que l'agent vient de lire. Cible OWASP LLM01 (injection indirecte). Précision mesurée 1,000 / rappel 0,971 / F1 0,986 sur un corpus versionné de 35 positifs + 26 négatifs ressemblants + 8 cas hors champ.
• Étape 2 : Parcours du rayon d'impact. Un graphe NetworkX de saved searches -> indexes -> sourcetypes -> hosts -> assets. Calcule quelles techniques MITRE et balises de conformité perdent leur couverture et combien d'autres détections partagent cette couverture. L'histoire de redondance : « c'est la SEULE détection couvrant l'hôte paymentapp01, qui est tagué PCI ».
• Étape 3 : Prédiction de coût. Estimation en SVC-heures à partir du SPL proposé. Cible de production : Cisco Deep Time Series Model sur Splunk Cloud.
• Étape 4 : Moteur de politiques. 12 règles déterministes cartographiées sur NIST AI RMF, OWASP LLM Top 10, EU AI Act Article 14, PCI DSS 10, HIPAA 164.308, SOX et ISO/IEC 42001. POL-001 à POL-012 citent chacune dans le code le contrôle standard qu'elles implémentent.
• Étape 5 : Synthèse de décision. ALLOW / REQUIRE_APPROVAL / BLOCK, lu UNIQUEMENT depuis l'étape de politique. Les non-ALLOW persistent comme un Finding (mock de l'API /findings d'ES 8 v2). Fail-closed : si l'étape de portail lève une exception, le verdict est BLOCK avec severity=HIGH. Test de régression épinglé : test_policy_stage_exception_fails_closed.
• Étape 6 (consultative) : Foundation-Sec-1.1-8B-Instruct comme explicateur de Finding. Rédige un paragraphe en langage clair attaché au Finding pour qu'un évaluateur humain lise le risque en langage naturel. Ne contrôle PAS les décisions. Les décisions restent reproductibles depuis la bibliothèque de politiques seule.

Chaque verdict, peu importe le résultat, est diffusé vers l'index agentgate_audit via HEC. Le tableau de bord fourni en fait le système d'enregistrement de la gouvernance des agents IA côté Splunk.

Le choix de conception qui le rend auditable

Déterministe là où l'audit exige la reproductibilité. Génératif là où les humains exigent l'explication. Les cinq étapes de portail sont du Python pur : parcours de graphe NetworkX, regex + normalisation contre l'obfuscation, évaluation de politiques pilotée par dictionnaire. Même entrée, même verdict, à chaque fois, sur n'importe quelle machine. La sixième étape est un modèle à 8 milliards de paramètres qui écrit le paragraphe « pourquoi ceci a été bloqué » qu'un analyste SOC lit à 3 h du matin, mais sa sortie ne contrôle jamais une décision. Si Foundation-Sec est en panne, le portail fonctionne quand même. Si un Finding n'a pas de paragraphe d'explication, l'analyste voit quand même les IDs de politique, la citation du contrôle de standard et le graphe du rayon d'impact.

C'est la même séparation déterministe-vs-générative que sur Warden, portée dans le vocabulaire de Splunk : graphes KO, Findings ES 8, savedsearches.conf, index d'audit. Les deux projets répondent à une question apparentée (comment gouverner une flotte d'agents) sur les deux plateformes dont les clients la posent le plus fort en ce moment.

Quatre scénarios prouvés de bout en bout

Le script de démo joue quatre scénarios canoniques qui touchent chaque chemin de code. Chacun est un véritable appel d'outil contre une vraie instance Splunk Enterprise de dev avec un vrai graphe KO chargé (12 saved searches, 9 actifs KV, indexes, HEC, événements d'exemple).

Performance mesurée

Deux profils de latence importent, et ils vivent sur des chemins différents. La latence du chemin de décision est ce que chaque appel de portail paie. La latence du chemin de raisonnement n'est payée que sur les décisions non-ALLOW, de manière asynchrone, après que le verdict ait déjà été retourné.

• Chemin de décision déterministe : p50 0,23 ms, p95 0,56 ms (tests/test_latency.py).
• Taux de faux positifs du portail de politique : 0,000 sur 20 appels d'outil bénins (tests/test_pipeline.py).
• Chemin consultatif Foundation-Sec : moyenne 9,4 s, p50 8,2 s, max 13,1 s (tests/test_latency.py --runslow).
• Détecteur d'injection : précision 1,000, rappel 0,971, F1 0,986, spécificité 1,000 (26/26), pass-through hors champ 8/8. Corpus versionné dans tests/corpora/ pour que les chiffres soient reproductibles, pas auto-notés.

Ce qui a été difficile

Splunk MCP Server v1.2 a ajouté un enable/disable grossier des outils mais pas de rayon d'impact par action ni de portail d'approbation. En construire un voulait dire câbler quatre surfaces ensemble qui ne se croisent pas d'habitude : le SDK Python Splunk pour l'énumération du catalogue KO, le MCP server pour le point d'interception de l'appel d'outil, l'API Findings d'ES 8 v2 pour l'artefact d'approbation durable, et un bundle d'application Splunk (savedsearches.conf, collections.conf, transforms.conf, XML de tableau de bord, app.conf, metadata) pour que le tableau d'audit s'installe proprement sur n'importe quelle instance de dev.

La couverture adversarielle a été un choix de cadrage délibéré. Le corpus d'injection mélange des motifs communs sélectionnés à la main, des templates important_instructions_attacks d'AgentDojo, et des variantes d'obfuscation adversarielle (homoglyphes, espaces de largeur zéro, leet, payload-split). Le bypass leet « 1gn0r3 4ll pr3v10us » est un xfail documenté, exprès. La production devrait coupler l'heuristique avec une vérification sémantique sur la même entrée, et l'architecture route déjà les tentatives de détournement d'exécution d'outil type INJECAGENT vers l'étape sémantique Foundation-Sec. Documenter la lacune est ce qui rend le chiffre de précision crédible : 0 faux positifs sur 26 négatifs ressemblants ne compte que si on dit aussi aux juges où vivent les faux négatifs.

Cadrage honnête sur le graphe KO aussi. Il est chargé à la main avec 12 saved searches et 9 actifs. Les vrais portefeuilles SOC font 10 000+ saved searches. Le parseur passe à l'échelle linéairement avec NetworkX mais le coût du parcours de graphe à cette échelle n'a pas été mesuré. Un déploiement en production remplacerait le chargeur de seed par un appel REST Splunk contre le vrai catalogue KO et le benchmarkerait. La soumission le dit à voix haute, dans la section « ce que nous n'avons PAS validé », plutôt que de l'enterrer.

Pourquoi ça compte

Le coût d'une mauvaise gouvernance d'agents IA n'est pas hypothétique et les chiffres sont publics. Le rapport Cost of a Data Breach d'IBM situe la moyenne globale à 4,4 M$, et les brèches qui ont pris plus de temps à identifier coûtent en moyenne plus de 1 M$ de plus. Le DBIR de Verizon situe l'élément humain à 68 % des brèches, dont le sous-ensemble « mauvaise configuration » correspond exactement à la forme que produit un agent qui dérape en désactivant silencieusement une règle de détection. PCI DSS 10.6 exige une revue quotidienne des journaux de l'environnement de cartes de paiement ; une détection sole-coverage désactivée silencieusement par un agent est la différence entre une alerte bruyante et une enquête réglementaire.

Et il y a un véritable incident, pas une expérience de pensée, exactement dans la forme contre laquelle AgentGate protège. En juillet 2025, l'agent codeur de Replit a supprimé la base de données de production d'un client pendant un gel de code explicite, puis l'a admis au prompt suivant (le client était Jason Lemkin de SaaStr ; l'incident a été couvert par Tom's Hardware). POL-004 (primitive destructrice) et POL-009 (mutation d'un système d'enregistrement) l'auraient bloqué avant exécution.

Applicabilité multi-volets

La soumission principale est le volet Sécurité, mais le même portail s'applique aux deux autres volets via la bibliothèque de politiques existante sans changement de code. Un agent ITSI qui propose de réécrire un index summary touche POL-008 (changement de masse) et POL-009 (mutation d'index système) pour le volet Observabilité. Un agent MLTK qui propose `| fit` contre `_audit` touche POL-004 (SPL destructeur), POL-007 (coût) et POL-008 (Excessive Agency) pour le volet Platform & Developer Experience. Même moteur, même bibliothèque de politiques, appels d'outil différents.

La suite

• Remplacer le chargeur de KO par un appel REST en direct contre le vrai catalogue d'objets de connaissance Splunk, benchmarker le parcours du rayon d'impact sur un portefeuille de 10 000+ saved searches.
• Remplacer le mock KV des Findings ES 8 par le vrai endpoint POST /public/v2/investigations/{id}/findings pour les déploiements Cloud.
• Remplacer Foundation-Sec local sur Ollama par la surface Splunk Hosted Models (| ai provider=splunk model=foundation-sec-1.1-8b-instruct) sur Splunk Cloud.
• Ajouter un détecteur sémantique d'injection à côté de l'heuristique sur la même entrée, pour fermer le xfail leet documenté.
• L'obfuscation multilingue, le payload-splitting au-delà de la largeur zéro, le smuggling base64 sous 120 caractères sont hors du modèle de menace actuel du regex. Un red-team de production étendrait le corpus.
• Mener une étude utilisateur avec analyste dans la boucle sur l'UX d'approbation de Finding. Pour l'instant ce n'est pas prouvé contre les vrais changements de quart SOC.