Quinze adversaires attaquent notre défense 24 h/24. Chaque percée la rend plus forte.
Chaque persona se spécialise dans une classe d'attaque différente — injection de prompt, ingénierie sociale, exfiltration de données, compromission de la chaîne d'approvisionnement — sur les quatre checkpoints, sans relâche. Dès que l'une trouve une faille, cette faille devient une détection examinée et signée cryptographiquement qui protège chaque agent du réseau, pas seulement l'arène.
Quinze adversaires, chaque menace sur chaque checkpoint
Chacun de nos quinze adversaires nommés occupe une cellule de la matrice des menaces — une classe d'attaque précise à un checkpoint précis. The Substrate Mole, par exemple, mène des attaques de chaîne d'approvisionnement au checkpoint d'intégrité. À mesure que la défense se durcit, chaque adversaire mute dans sa spécialité — creusant plus profond plutôt que de s'éparpiller — pour une couverture complète et une pression ciblée.
front door
Porte avant — prompts entrants et résultats d'outils : injection de prompt, injection indirecte, fraude au PDG, jailbreaks, détournements multi-tours, usurpation d'agent, variantes multilingues et bruit en rafale.
inside.autonomy
Checkpoint d'autonomie — ce que l'agent est autorisé à faire : sondage des limites des outils, appels d'outils non déclarés et actions hors du mandat de l'agent.
inside.integrity
Checkpoint d'intégrité — comment l'agent raisonne : intégrité de la chaîne de raisonnement, compromission de la chaîne d'approvisionnement (The Substrate Mole), blanchiment de prompt et dérive des valeurs.
back door
Porte arrière — réponses sortantes : prévention des pertes de données, exfiltration d'identifiants et de canaris, fuites de PII/PHI et fuites du prompt système.
Quand la défense commence à gagner, les attaques évoluent
L'arène passe le plus clair de son temps à chercher de nouvelles brèches. Mais lorsque la défense intercepte de façon fiable une classe d'attaque donnée, l'arène change de braquet : elle cesse de répéter les attaques connues et se met à les muter, mettant à l'épreuve la défense corrigée au lieu de s'en contenter. Chaque classe d'attaque est suivie indépendamment, l'arène peut donc durcir un domaine tout en en explorant un autre.
Seuil d'entrée
95% interceptés, durablement
Assez de volume (180–360 sondes) pour réagir vite sans courir après le bruit.
Fenêtre
48h glissante
Fenêtre glissante continue, pas des périodes calendaires.
Hystérésis d'entrée
24h soutenues
Un pic ne le déclenche pas — le taux doit tenir une journée entière.
Hystérésis de sortie
24h soutenues
Un bucket doit rester sous le seuil de sortie pendant 24 heures avant de revenir en mode recherche.
Seuil de sortie
90% interceptés
Sous le seuil d'entrée pour que le système ne vacille pas à la frontière.
Indépendance par bucket
par substrat, secteur, schéma et source
Un agent financier peut se durcir contre la fraude au PDG tout en explorant encore l'injection de prompt — chacun suivi séparément.
Cadrage honnête
Ce déclenchement adaptatif est construit et déployé dans notre arène. Nous signalerons sa première activation en production sur /trust/advisories — nous ne considérons pas le code terminé comme prouvé sur le terrain.
L'arène peut trouver une faille. Elle ne peut pas déployer le correctif toute seule.
L'arène fonctionne avec sa propre identité au périmètre restreint. Elle ne peut faire qu'une chose : soumettre une détection candidate à une revue humaine. Elle ne peut pas promouvoir une règle, en modifier une active, en retirer une, ni toucher à quoi que ce soit d'autre. Chaque candidate est estampillée — par le serveur, jamais le client — de son origine, si bien qu'une trouvaille de l'arène ne peut jamais se faire passer pour un signalement client ou une action d'opérateur.
writer_identity = arena-bypass
auth = ARENA_RECIPE_CANDIDATE_TOKEN
write_scope = recipe_candidates only
read_scope = none (no live-rule visibility)
promote_scope = none (separate reviewer auth required)Scope
Les identifiants de l'arène n'ouvrent qu'une seule porte — soumettre une candidate à la revue. Aucun accès en lecture aux règles actives. Aucun accès en écriture à quoi que ce soit d'autre.
Origine estampillée par le serveur
La source de chaque candidate est définie par le serveur à partir de l'identité authentifiée, jamais par le client. L'arène ne peut usurper un signalement client ni un opérateur.
Audit en ajout seul
Chaque action sur chaque règle est consignée dans un journal en ajout seul — qui a fait quoi, quand. Promouvoir une trouvaille de l'arène exige toujours un relecteur humain authentifié séparément.
Double contrôle, imposé
Les règles capables de bloquer du trafic de production réel ne s'auto-promeuvent jamais — quelle que soit la source ou la configuration. Deux relecteurs authentifiés sont requis, et cette exigence est imposée par la base de données elle-même, pas par un processus contournable.
D'une percée dans l'arène à une protection active — cinq étapes vérifiées
Cinq étapes transforment une percée de l'arène en protection active. Chaque étape est consignée dans une piste d'audit en ajout seul. C'est le même pipeline qu'empruntent les signalements clients et notre renseignement inter-clients — l'arène est l'une des trois sources de signal, pas un raccourci.
1 · Contournement détecté
Un adversaire passe. La trouvaille est soumise comme candidate à la revue — rien n'est encore actif.
2 · Revue humaine
Les opérateurs trient chaque candidate. Par défaut, c'est une approbation manuelle ; l'auto-approbation plus rapide est optionnelle et ne s'applique qu'aux règles de conseil — tout ce qui peut bloquer du trafic réel exige toujours deux humains.
3 · Promotion signée
Les règles approuvées sont signées cryptographiquement, et chaque approbation — créée, examinée, signée — est consignée dans la piste d'audit en ajout seul.
4 · Distribution redondante
Chaque règle signée est écrite dans deux dépôts à clés indépendantes et vérifiée avant qu'une passerelle ne la charge. Empoisonner le plan des règles supposerait de compromettre plusieurs systèmes indépendants à la fois.
5 · Observer, puis appliquer
Les nouvelles règles s'exécutent en mode observe pendant 24 heures. Si leur taux de faux positifs reste propre, elles sont promues en application ; sinon, elles font l'objet d'un rollback — confirmé par un opérateur aujourd'hui, automatique dans une phase ultérieure.
Ce que cette page affirme — et ce qu'elle n'affirme pas.
Chaque affirmation porteuse sur cette page cite une référence publique. Les points ci-dessous sont les reports que nous nommons à dessein — les CISOs respectent la divulgation honnête des contraintes ; ils sanctionnent la contrainte découverte.
Le test de pression adaptatif est construit et déployé dans notre arène. Il ne s'est pas encore activé en production — le moment venu, nous le publierons sur /trust/advisories.
L'arène est le laboratoire. Les contournements trouvés ici ne comptent pas comme des détections réelles. Une détection promue passe par l'approbation d'un relecteur et une période d'observation de 24 heures avant de s'appliquer — ce que vous voyez sur /dashboard/threats est le résultat de ce pipeline, pas l'arène directement.
À la GA, la liste advisories affiche un seul post-mortem synthétique, clairement étiqueté comme synthétique. L'IoC feed est vide par conception. Le système dit la vérité — nous ne simulons pas d'activité pour paraître occupés.
Les règles de conseil sont déployées auto-promues au lancement. Les règles capables de bloquer du trafic de production exigent deux relecteurs authentifiés — et cette exigence est imposée dès aujourd'hui par la plateforme.
De l'arène à votre flotte.
L'arène est l'une des trois sources de signal alimentant l'AEGIS Protection Network — aux côtés des signalements clients et de notre renseignement inter-clients. Toutes trois passent par le même pipeline de promotion signée.
Votre threat thermometer
État live pour votre flotte sur /dashboard/threats. Calm at GA by design — quand quelque chose change, vous le voyez en premier.
Le réseau L0-L5 complet
Identité des menaces, renseignement inter-clients, la surcouche sous attaque, la distribution des règles gérées, votre thermomètre de menaces et le flux d'IoC — tout le réseau de protection, de bout en bout.
Parlez-nous
Entreprise, secteurs réglementés, déploiements self-hosted — les sujets qui méritent une conversation, pas un checkout.
