                        
                        ARCHITECTURE HYBRIDE • SDK PYTHON & API REST
                    

Interceptez et validez
chaque appel d'outil
de vos agents IA

Contrôles déterministes locaux dans votre SDK Python (< 1,4 ms au p95), analyse d'injection distante et comportement en cas de panne configurable agent par agent.

Déployer le Sensor Voir la vraie console en démonstration →

Contrôles Locaux vs
Moteur Cloud & Mode Panne

Les contrôles de whitelist et de plafonds s'exécutent localement dans le SDK (latence mesurée : 1,4 ms au p95). L'analyse d'injection s'exécute dans notre moteur cloud en Europe (latence mesurée : 42 ms au p95 depuis l'UE). Si le moteur est injoignable, vous choisissez, agent par agent : blocage par défaut (block), ou exécution avec journalisation locale différée (allow_and_buffer).

1. SDK Local (p95 : 1,4 ms)

Exécuté directement dans le processus Python de votre agent : vérification de la whitelist d'outils, plafonds horaires, masquage DLP des secrets et mise en cache local des règles.

2. Moteur Cloud UE (p95 : 42 ms)

Inspection des arguments contre les injections de prompt connues (OWASP LLM01), calcul du score de risque et mise en quarantaine interactive. Timeout configurable (timeout_ms: 300).

3. Journal Signé & Mode Panne

Chaîne SHA-256 signée par organisation. En cas d'indisponibilité réseau, appliquez on_unreachable: block (fail-closed) ou allow_and_buffer (journalisation locale différée).

Où s'exécute chaque contrôle & Latences mesurées

Mesures réalisées sur l'infrastructure de production (région UE Francfort eu-central-1 et hors UE Côte Est US).

Contrôle de sécurité	Lieu d'exécution	Latence UE (p50 / p95 / p99)	Hors UE (p95)
Whitelist d'outils & Plafonds	Local (SDK Python)	0,6 ms / 1,4 ms / 2,1 ms	1,4 ms (local)
Masquage DLP & Empreinte SHA-256	Local (SDK Python)	0,5 ms / 1,1 ms / 1,8 ms	1,1 ms (local)
Analyse d'injection & Score de risque	Cloud Engine (UE)	18 ms / 42 ms / 68 ms	115 ms
Signature & Journalisation PostgreSQL	Cloud Engine (Asynchrone)	Non-bloquant (< 1 ms)	Non-bloquant

# Configuration fail-mode par agent

agent:
  id: agent-customer-support-v1
  mode: active_blocking   # ou observe_only
  on_unreachable: block   # ou allow_and_buffer
  timeout_ms: 300
  whitelist:
    - read_faq_database
    - calculate_price

Les 3 Piliers Techniques

Journalisation à preuve d'altération, défense en profondeur contre les injections et restriction granulaire des outils.

Pilier 1

Journalisation à Preuve d'Altération & Minimisation

Par défaut, le sensor transmet uniquement les métadonnées d'exécution (agent_id, tool_name, statut, latence) et l'empreinte SHA-256 du contenu (input_sha256). Pour le débogage ou l'audit approfondi, vous pouvez activer agent par agent l'option « capture complète » : les paramètres sont alors filtrés par DLP (masquage des secrets/PII) et chiffrés en AES-256 avec une clé propre à votre organisation.

✓ Par défaut : métadonnées + empreinte SHA-256 du contenu (zéro donnée métier stockée en clair)
✓ Option « capture complète » activable par agent, chiffrée et compatible crypto-shredding RGPD
✓ Chaîne SHA-256 signée vérifiable hors-ligne via python boundry_verify.py export.json

// Entrée de journal signée (mode par défaut)

{
  "timestamp": "2026-11-02T08:15:02Z",
  "organization_id": "org_eu_94a1",
  "agent_id": "agent-customer-support-v1",
  "tool_name": "read_faq_database",
  "capture_mode": "metadata_and_hash",
  "input_sha256": "8f434346648f6b96df89dda901c5176b...",
  "prev_hash": "a4b1c298fc1c149afbf4c8996fb92427...",
  "hash": "f7e8d92427ae41e4649b934ca495991b...",
  "signature": "3c9e18b04d2a7f61..."
}

Pilier 2

Détection d'Injections & Défense en Profondeur

Aucune détection d'injection n'est parfaite. Boundry combine la détection (règles et heuristiques alignées sur le risque OWASP LLM01), la limitation des permissions (whitelist par agent) et la quarantaine, afin de réduire l'impact même lorsqu'une injection inédite passe. Commencez en mode observation (observe_only), puis activez le blocage quand vous êtes prêt.

✓ Mode Observation sans blocage pour calibrer vos règles sans faux positifs bloquants
✓ Détection des injections connues, tentatives SSRF (169.254.169.254) et boucles d'appels
✓ Seconde barrière déterministe : même trompé, l'agent ne peut pas appeler un outil hors whitelist

[ALERTE D'INSPECTION — OWASP LLM01] Mode : active_blocking (ou observe_only)
Score de Risque : 92 / 100
Défense appliquée : Motif d'injection indirecte détecté + outil export_all_users absent de la whitelist de l'agent. Exécution mise en quarantaine.

Pilier 3

Whitelist Déterministe & Quarantaine

Définissez précisément les outils que chaque agent est autorisé à invoquer. Contrairement à une consigne dans un prompt système qu'un modèle peut ignorer, la whitelist Boundry est vérifiée dans le code Python avant l'invocation de la fonction.

✓ Whitelist stricte par agent et par environnement
✓ Quarantaine d'urgence (Kill-Switch) depuis la console
✓ Fenêtres horaires et plafonds de volume d'appels par minute

Politique Whitelist Locale (SDK)

get_weather AUTORISÉ (0,6 ms)

read_faq_database AUTORISÉ (0,6 ms)

send_email BLOQUÉ LOCALEMENT

Compatibilité Frameworks & Feuille de Route Produit

Statut réel de nos intégrations natives et de notre feuille de route technique.

Framework / Protocole	Mode d'intégration	Statut actuel
LangChain (Python)	Callback Handler natif (`BoundryCallbackHandler`)	Disponible
Agents Python / API REST	Décorateur `@secure_tool`, SDK Sensor et `POST /events`	Disponible
CrewAI, AutoGPT	Middleware via API REST	Disponible via API
TypeScript (LangChain.js / Vercel AI)	SDK client `@boundry/sensor`	Feuille de route (T1 2027)
MCP (Model Context Protocol)	Passerelle proxy MCP (whitelist, journalisation et quarantaine sur serveurs MCP)	Feuille de route (T2 2027)

Interceptez et validez chaque appel d'outil de vos agents IA

Contrôles Locaux vsMoteur Cloud & Mode Panne