✓ Retenue via Show HN 3e sur 18 proposéesVenture Sécurité 4 nov. 2026

Tests adversariaux continus pour les dispositifs anti-fraude

Un service de red team qui attaque vos règles et modèles antifraude avec des fraudeurs simulés et adaptatifs, et mesure la vitesse à laquelle chaque défense est contournée, avant que de vrais attaquants ne s'en aperçoivent.

Ouvrir la discussion ↗

Un brief prêt à coller dans Claude Code, Cursor ou tout agent de code (en anglais).

I want to build a venture-scale product. Help me plan and start the MVP.

Product: Continuous adversarial testing for fraud defense stacks
What it is: A red-team service that attacks your fraud rules and models with simulated adaptive fraudsters, measuring how fast each defense gets bypassed before real attackers find out.
Who pays: Heads of fraud/risk at mid-market fintechs and marketplaces (500–5,000 employees), $3–10k/mo from the existing fraud tooling budget alongside Sift/Sardine spend.
Closest alternatives: Sift, Sardine, SEON, Kairos (the launched product)
The gap: All existing fraud platforms, including Kairos, are detection engines: they score and decide on live traffic. None continuously probes the customer's own ruleset and models with mutated, adversarial identities and behaviors to report time-to-bypass and decay curves before real fraudsters exploit the holes. Pen-testing firms do this manually for appsec, not for fraud decisioning logic.
Why now: LLM agents make it newly cheap to generate large volumes of plausible adversarial behavior (varied identities, devices, narratives, session patterns), and the shift to agent-tuned fraud stacks (as Kairos shows) creates machine-readable rulesets and models that can be attacked programmatically via the same APIs.
Moat to build toward: Compounding advantage: every engagement generates a proprietary corpus of bypass techniques and decay benchmarks across customers, which improves the attack generator and becomes a defensible dataset no detection vendor has.
Biggest risk: Fraud teams treat this as a nice-to-have audit rather than a recurring need, and the detection vendors (Sift, Sardine, Kairos) add basic simulation as a feature, collapsing the standalone market.

First three steps:
1. Build an attack generator that mutates identity/device/session/event payloads and replays them against a customer's ruleset via API to find bypasses.
2. Ship a rule-decay report: replay historical confirmed-fraud events weekly and quantify how detection recall degrades over time per rule/model.
3. Deliver a prioritized fix list (which rule, which variant, expected lift) that fraud engineers can hand to their decisioning platform.

Start by asking me up to five questions about constraints (stack, budget, timeline), then propose the smallest version a paying customer would use, and scaffold it.

Global6.2/10

Douleur7

Volonté de payer6

Timing6

Manque7

Avantage défensif5

Faisabilité5

Pour

Qui paie

Responsables fraude et risque dans des fintechs et marketplaces de taille moyenne (500 à 5 000 employés) ; 3 000–10 000 $/mois sur le budget outillage antifraude existant, en complément des dépenses Sift ou Sardine.

Ce que les gens ont dit · 3

L'article lui-même indique que les modèles et règles entraînés deviennent obsolètes en quelques semaines, car les fraudeurs rétro-ingénient la logique de détection, ce qui oblige à un réentraînement constant. Tiré de l'article ↗
Un vétéran des guerres anti-spam d'AOL affirme que chaque technique défensive construite en plusieurs semaines ou mois a été contournée par les adversaires en un seul week-end, et que les attaquants n'ont fait qu'accélérer depuis. Lire le commentaire ↗
Un commentateur écarte les heuristiques de surface, comme demander à un modèle si un e-mail semble jetable, en soutenant que les vrais signaux de fraude sont beaucoup plus profonds que les apparences, ce qui suggère que les défenses sont validées bien trop superficiellement. Lire le commentaire ↗

Reformulé à partir de la discussion. Suivez les liens pour lire les commentaires d'origine.

Concurrents et manque

SiftSardineSEONKairos (the launched product)

Toutes les plateformes antifraude existantes, Kairos compris, sont des moteurs de détection : elles scorent et décident sur le trafic en direct. Aucune ne sonde en continu le jeu de règles et les modèles du client avec des identités et comportements adverses mutés, pour mesurer le temps de contournement et les courbes de dégradation avant que de vrais fraudeurs n'exploitent les failles. Les cabinets de tests d'intrusion font cela manuellement pour l'appsec, pas pour la logique de décision antifraude.

Pourquoi maintenant

Les agents LLM rendent soudainement peu coûteuse la génération de gros volumes de comportements adverses plausibles (identités, appareils, récits et schémas de session variés). Et le passage à des dispositifs antifraude réglés par agents, comme le montre Kairos, produit des règles et des modèles lisibles par machine, qui peuvent être attaqués de façon programmatique via les mêmes API.

Avantage défensif · 5/10

Un avantage cumulatif : chaque mission produit un corpus propriétaire de techniques de contournement et de référentiels de dégradation, couvrant plusieurs clients. Cela améliore le générateur d'attaques et constitue un jeu de données défendable qu'aucun éditeur de détection ne possède.

Contre

Équipe rouge: Les éditeurs de détection (Sift, Sardine) n'attaquent pas en continu les règles propres du client pour mesurer le temps de contournement, et les cabinets de tests d'intrusion ne touchent pas à la logique de décision antifraude. Il reste donc un vrai manque, avec un acheteur qui dépense déjà dans l'outillage antifraude.
Ce qui la ferait échouer: Les équipes antifraude considèrent ce service comme un audit agréable à avoir plutôt qu'un besoin récurrent, et les éditeurs de détection (Sift, Sardine, Kairos) ajoutent une simulation de base comme fonctionnalité, ce qui fait s'effondrer le marché autonome.

Démarrer

Les trois premières étapes: Construire un générateur d'attaques qui mute les payloads d'identité, d'appareil, de session et d'événement, et les rejoue contre le jeu de règles du client via API pour trouver des contournements.
Livrer un rapport de dégradation des règles : rejouer chaque semaine les événements de fraude confirmés historiques et quantifier la baisse du rappel de détection par règle ou par modèle.
Fournir une liste de corrections priorisée (quelle règle, quelle variante, gain attendu) que les ingénieurs antifraude peuvent transmettre à leur plateforme de décision.
Discussion d'origine: Show HN: Kairos – Open-source risk and fraud decisioning platform ↗ 103 points30 commentairesDe l'articleArticle lié

Traduit de l'anglais. Lire l'original

#	Note	Idée	Type	Catégorie	Douleur	Payer	Timing	Manque	Défense	Faisable
1	6.5	Détection de falsification des configs d'agents IA et des serveurs MCPAnalyse en continu les machines des développeurs pour détecter les plugins d'agents installés à leur insu, les hooks auto-approuvés et les endpoints MCP distants non autorisés dans Claude Code, Codex et Cursor.	Indie	Sécurité	7	6	8	6	5	7
2	6.4	Plateforme d'exploitation pour les flottes de Mac de build sans écranLogiciel d'exploitation de flotte qui automatise la récupération, le déverrouillage et l'imaging de racks de Mac sans écran utilisés comme nœuds de build CI.	Indie	Outils de développement	7	6	7	6	5	7

Pour

Contre

Démarrer

Plus dans cette édition