Architecture de sécurité appliquée par le code

Les bots IA ne devraient faire confiance à rien par défaut.

Une architecture zero-trust en 5 couches pour bots IA, conçue pour rester utile sans faire confiance ni au prompt, ni à l'utilisateur, ni au contexte, ni aux outils, ni même à la sortie du modèle.

Voir le repo GitHub Lire l'architecture

pipeline en 5 couches

contrôles avant + après modèle

contrat testable

pipeline d'exécution

01 Résolveur d'authentification qui, où, rôle, confiance, quota

02 Filtre des outils listes d'autorisation explicites avant les outils

03 Filtre des skills les comportements workspace restent bornés

04 Assembleur de prompt Les contextes restreints sont rédigés avant injection.

05 Garde de sortie la sortie du modèle reste non fiable

rétrogradation active Les admins sont rétrogradés dans les groupes non fiables, les probes sont bloqués avant le modèle, et l'incertitude n'augmente jamais le privilège.

le modèle peut être réduit au silence Les workflows multi-étapes peuvent acquérir un verrou de portée pour empêcher toute improvisation du modèle.

Pourquoi cela existe

La sécurité basée seulement sur le prompt casse dès que le bot devient utile.

Plus un bot IA gagne des outils, du contexte, de la mémoire et des actions privilégiées, plus il faut des frontières applicables en code plutôt que de simples instructions narratives.

Injection de prompt

Un utilisateur peut pousser le modèle à révéler les règles internes ou à contourner des contraintes qui n'étaient imposées que par le prompt.

Dérive de privilèges

Les rôles bruts ne suffisent pas. Un admin dans un groupe non fiable ne doit pas conserver un accès admin en aval.

Surexposition des outils

Si le modèle voit tout le catalogue d'outils avant filtrage, la simple découverte des capacités devient déjà une fuite.

Fuites en sortie

Même un prompt bien encadré peut encore produire des détails sensibles si la sortie finale n'est ni vérifiée ni bloquée.

Pipeline en couches

Cinq couches, un ordre fixe, un contrôle indépendant.

Chaque couche peut bloquer, restreindre ou enrichir la requête. Aucune couche tardive ne suppose que la précédente était correcte.

Resolution d'identite et de confiance

Auth Resolver

Normalise les IDs utilisateur et canal, resout bans, confiance, inscription, role, effectiveRole, quotas et detection des probes avant que le modele ne voie quoi que ce soit.

Input Evenement brut de plateforme plus contexte runtime.

Output Un objet authContext avec action, safeReply, effectiveRole, facts de confiance, quotas et probe flags.

Guardrail Les admins sont retrogrades dans les groupes non fiables, les probes sont bloques avant le modele, et l'incertitude n'augmente jamais le privilege.

Filtrage des capacites

Tool Gate

Filtre le catalogue d'outils runtime avec des allowlists explicites avant que le modele ne recoive un acces aux outils.

Input Catalogue d'outils detecte, effectiveRole et facts de confiance.

Output Noms d'outils autorises, noms bloques et liste filtree exposee en aval.

Guardrail Les outils inconnus sont refuses par defaut, et le matching se fait par appartenance exacte a un ensemble.

Scope des comportements workspace

Skill Gate

Restreint les skills, bundles de prompt ou comportements internes visibles, et borne les lectures de fichiers meme pour les skills autorises.

Input Definitions de skills workspace, chemins de fichiers, effectiveRole et contexte de confiance.

Output Un bloc available-skills reconstruit ne contenant que les skills et metadata autorises.

Guardrail Les sessions restreintes ne lisent que les metadata de skills autorises; aucune lecture arbitraire du workspace.

Assemblage du contexte

Prompt Assembler

Assemble seulement le contexte que la session courante est autorisee a voir, en suivant un ordre de priorite strict et des tiers memoire dependants du role.

Input Etat d'action, contexte local, contexte base de donnees, memoire, commandes actives et directives trust-aware.

Output Le system prompt exact, ou le prepend context autorise pour cette session.

Guardrail Les contextes restreints sont rediges avant injection, les forced responses reduisent la liberte du modele, et la memoire globale n'apparait qu'en full access.

Controle post-generation

Output Guard

Traite la sortie du modele comme un contenu non fiable, detecte les fuites d'architecture ou de donnees sensibles, puis bloque et journalise avec snippets rediges.

Input Contenu genere, contexte de requete initial et action determinee en amont.

Output Une safe reply, une reponse bloquee, ou le contenu approuve pour les sessions admin full access.

Guardrail Le support de redaction n'est pas une autorisation: si un pattern sensible matche, la reponse est bloquee et non pas nettoyee puis envoyee.

Regles non negociables

Ce repo compte parce que le modele de securite est executable, pas simplement inspirant.

Ces invariants font la difference entre une promesse marketing et un systeme qui peut vraiment etre audite, porte et teste.

effectiveRole partout

L'autorisation en aval suit le role runtime demote, pas le role brut capture a l'entree.

Filtrage pre-model

Les probes d'architecture sont detectes et bloques avant que le modele ne recoive le texte.

Validation post-model

La sortie generee est encore verifiee pour les fuites d'architecture, secrets, domaines, fichiers et identifiants sensibles.

Allowlists explicites

Outils, skills et lectures de fichiers sont autorises par appartenance exacte uniquement.

Rejet silencieux

Les groupes non enregistres ne recoivent aucune reponse, ce qui evite de divulguer des capacites ou politiques.

Quotas et locks atomiques

Les quotas sont consommes cote serveur et les workflows deterministes peuvent couper le modele completement.

Preuve equilibree

Ce n'est pas juste un document de philosophie.

Le repo inclut des scenarios de verification, un schema de reference et des regles de workflow lock pour qu'une implementation puisse etre verifiee dans un systeme reel.

Checks de conformite

matrix

Groupe non enregistre

Resultat attendu: action = cancel, aucune reponse visible.

Probe de securite

Resultat attendu: forced response, le modele ne voit jamais la requete.

Admin en groupe non fiable

Resultat attendu: effectiveRole = moderator, hasFullAccess = false.

Sortie sensible

Resultat attendu: reponse bloquee et incident journalise avec snippets rediges.

Workflow lock

Resultat attendu: l'utilisateur initiateur est route vers le handler pendant que les autres continuent sur le flux IA normal.

Contrat de persistence de reference

SQL

Users, groups, bans, quotas, memory et audit logs sont traites comme des primitives de securite, pas comme du simple stockage annexe.

CREATE TABLE groups (
  id BIGSERIAL PRIMARY KEY,
  platform_channel_id BIGINT UNIQUE NOT NULL,
  trust_config JSONB DEFAULT '{}'::jsonb
);

CREATE TABLE quotas (
  platform_user_id BIGINT NOT NULL,
  platform_channel_id BIGINT NOT NULL,
  date DATE NOT NULL DEFAULT CURRENT_DATE,
  usage_count INT DEFAULT 0,
  PRIMARY KEY (platform_user_id, platform_channel_id, date)
);

CREATE OR REPLACE FUNCTION consume_quota(...) RETURNS INT;

Les flux deterministes peuvent couper le modele

lock

Les workflows multi-etapes comme les approvals, creations de commandes ou collectes structurees peuvent acquerir un lock scope pour empecher toute improvisation du modele.

Un seul workflow actif par groupe + thread.
Seuls les evenements correspondants de l'utilisateur initiateur sont detournes.
Les locks perimes expirent automatiquement et ne hijackent pas les autres utilisateurs.

Portable par design

Le contrat peut se deplacer entre plateformes sans perdre sa semantique de securite.

DMs, canaux, callbacks, skills et outils sont mappes a chaque stack hote, mais les invariants restent fixes.

Bots Telegram

Mappe naturellement chats prives, groupes, callback queries, getChatMember et onboarding par approbation de groupe.

Assistants Discord

Les guild channels, threads, interactions et permissions membre reproduisent le meme modele de confiance, de lock et d'allowlists.

Workflows Slack

Les payloads interactifs deviennent des actions structurees, tandis que channels et DMs conservent le meme least-privilege behavior.

Copilotes internes

Des room IDs, ACL lookups et modules de capacites scopes peuvent rejouer exactement la meme chaine en 5 couches dans une web app.

Ne d'une contrainte de production reelle

Du hardening IKOBOT/OpenClaw vers un contrat public reutilisable.

Le repository package l'architecture dans une forme reutilisable: overview lisible, contrat normatif, regles d'adaptation, scenarios de verification et schema de reference.

Ouvrir le repository GitHub Lire le contrat complet

Vue d'ensemble lisible

La narration courte: pourquoi le design existe, quelles sont les cinq couches et ce que le contrat promet.

Specification normative

L'ordre exact des couches, les action values, les data contracts, les regles fail-safe et la semantique des workflow locks.

Matrice de conformite testable

Des scenarios concrets qui doivent passer avant de revendiquer une implementation fidele.

FAQ

Les questions qu'un decideur tech ou un ingenieur pose en premier.

Des reponses courtes pour decider vite, puis le contrat complet a un clic dans le repo.

Pourquoi ne pas compter seulement sur le prompt ?

Parce que le prompt influence le modele, mais n'impose ni l'autorisation runtime, ni l'exposition des outils, ni la validation de sortie, ni l'execution least-privilege.

Pourquoi exactement cinq couches ?

Parce que l'identite, le filtrage des capacites, le scope des comportements, l'assemblage du contexte et la validation de sortie resoudent des problemes differents et doivent echouer independamment.

Est-ce que cela marche en dehors de Telegram ?

Oui. Les regles d'adaptation mappent DMs, channels, callbacks, outils et skills vers Discord, Slack, web apps et autres runtimes sans affaiblir les invariants.

Qu'est-ce qu'un demoted admin ?

Un admin dans un groupe non fiable est traite comme moderator en aval, ce qui evite qu'un privilege prive ou de confiance fuite dans un contexte partage ou inconnu.

Est-ce pret pour la production ?

Le repo fournit un contrat d'implementation solide et une matrice de tests. Le niveau production depend encore de la qualite d'implementation, de validation et d'operation du systeme hote.