Architecture de sécurité multi-agents avec jetons à portée limitée, application des règles par passerelle API, appels workers protégés par mTLS et agrégation des résultats par un orchestrateur.
Orchestrator { # Orchestrator Agent
n1: circle label:"Receive task"
n2: rectangle label:"Decompose subtasks"
n3: rectangle label:"Send subtask A"
n4: rectangle label:"Receive result A"
n5: rectangle label:"Send subtask B"
n6: rectangle label:"Receive result B"
n7: rectangle label:"Aggregate results"
n8: circle label:"Return answer"
n1.handle(right) -> n2.handle(left)
n2.handle(right) -> n3.handle(left)
n3.handle(bottom) -> Gateway.n9.handle(top) [label="Subtask A + scoped token"]
n4.handle(right) -> n5.handle(left)
n5.handle(bottom) -> Gateway.n13.handle(top) [label="Subtask B + scoped token"]
n6.handle(right) -> n7.handle(left)
n7.handle(right) -> n8.handle(left)
}
Gateway { # API Gateway
n9: rectangle label:"Validate request A"
n10: rectangle label:"Route to worker A"
n11: rectangle label:"Receive result A"
n12: rectangle label:"Forward result A"
n13: rectangle label:"Validate request B"
n14: rectangle label:"Route to worker B"
n15: rectangle label:"Receive result B"
n16: rectangle label:"Forward result B"
n9.handle(right) -> n10.handle(left)
n10.handle(right) -> WorkerA.n17.handle(left) [label="Validated request A"]
n11.handle(right) -> n12.handle(left)
n12.handle(top) -> Orchestrator.n4.handle(bottom) [label="Result A"]
n13.handle(right) -> n14.handle(left)
n14.handle(right) -> WorkerB.n19.handle(left) [label="Validated request B"]
n15.handle(right) -> n16.handle(left)
n16.handle(top) -> Orchestrator.n6.handle(bottom) [label="Result B"]
}
WorkerA { # Worker Agent A
n17: rectangle label:"Validate token + execute"
n18: rectangle label:"Return result A"
n17.handle(right) -> n18.handle(left)
n18.handle(top) -> Gateway.n11.handle(bottom) [label="mTLS result A"]
}
WorkerB { # Worker Agent B
n19: rectangle label:"Validate token + execute"
n20: rectangle label:"Return result B"
n19.handle(right) -> n20.handle(left)
n20.handle(top) -> Gateway.n15.handle(bottom) [label="mTLS result B"]
}
Une architecture multi-agents superviseur-travailleur où un agent orchestrateur reçoit un objectif de haut niveau, le décompose en sous-tâches, délègue chacune à des agents travailleurs spécialisés (chercheur, rédacteur, QA), surveille l'exécution, gère les échecs et synthétise les résultats. L'orchestrateur gère mais n'exécute pas les tâches lui-même.
Pattern de coordination multi-agents où un orchestrateur décompose le travail en sous-tâches, les agents spécialistes tirent de et poussent vers un store d'état partagé, et l'orchestrateur compose la réponse finale depuis cet état partagé. Les configurations multi-agents semblent cohérentes au lieu que chaque assistant ait sa propre mémoire inconsistante.
Diagramme d'architecture de maillage de services avec proxys sidecar Istio ou Linkerd gérant le chiffrement mTLS, les politiques de trafic, le disjoncteur et le traçage distribué à travers les microservices. Ce modèle visualise comment un maillage de services abstrait les préoccupations réseau du code applicatif, permettant une communication zero-trust entre les services. Essentiel pour les équipes adoptant une infrastructure de maillage de services pour améliorer l'observabilité et la sécurité.
Diagramme d'architecture de sécurité zero trust avec vérifications de posture des appareils, vérification d'identité MFA, décisions de politique basées sur le risque, jetons JWT à courte durée de vie, micro-segmentation, chiffrement mTLS, application du moindre privilège et surveillance continue. Ce modèle représente le paradigme de sécurité « ne jamais faire confiance, toujours vérifier » où chaque requête est authentifiée et autorisée indépendamment de l'emplacement réseau. Essentiel pour les architectes sécurité implémentant des frameworks zero-trust modernes dans des environnements cloud-native.
Une architecture orchestrateur-travailleur où un agent orchestrateur décompose un objectif en sous-tâches, les distribue à des travailleurs spécialisés, puis synthétise une réponse finale. C'est l'architecture 'orchestration d'agents' la plus courante—puissante mais l'orchestrateur peut devenir un goulot d'étranglement à mesure que le nombre de travailleurs augmente.
Une architecture multi-agents hiérarchique qui scalde l'orchestration en empilant superviseurs et chefs d'équipe (une structure arborescente), ce qui reflète les structures organisationnelles d'entreprise et aide à partitionner le contexte. C'est l'architecture 'IA agentique de niveau entreprise' quand un seul orchestrateur ne peut pas gérer tous les travailleurs directement.