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.
Une sécurité bot expliquée simplement
Un bot IA ne devrait jamais avoir tous les droits par défaut.
Ici, le zero-trust est concret : on filtre d'abord le message, on vérifie qui parle, on limite le contexte donné au modèle, on borne les outils et les skills, puis on recontrôle la réponse avant envoi.
5 filtres concrets
avant, pendant et après le modèle
règles vérifiables
du message à la réponse
01
Filtre d'entrée
on bloque déjà ce qui ne doit pas entrer
02
Identité et accès
on vérifie qui parle et dans quel contexte
03
Contexte du modèle
on choisit ce que le modèle a le droit de voir
04
Outils et skills
Tout ce qui n'est pas explicitement autorisé reste interdit.
05
Sortie finale
on vérifie encore ce qui sort
les droits baissent quand le contexte devient moins sûr
Si l'entrée n'est pas légitime, on n'essaie pas d'être malin : on bloque tôt.
le modèle n'a pas toujours le dernier mot
Pour certains flux, le runtime reprend la main et empêche le modèle d'improviser.
Pourquoi cela existe
Dès qu'un bot a de la mémoire, des outils et des droits, le prompt seul ne suffit plus.
Si toute la sécurité tient dans des instructions au modèle, il finira un jour par trop voir, trop faire ou trop dire. Il faut donc des barrières appliquées par le code.
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 concrètes entre le message reçu et la réponse envoyée.
Chaque couche a un rôle simple. L'une bloque l'entrée, l'autre décide des droits, une autre limite le contexte, puis on borne les capacités et on vérifie la sortie.
01
Ce qui a le droit d'entrer
Filtre d'entrée
Avant même de parler du modèle, on décide si le message a le droit d'entrer dans le pipeline : utilisateur banni, groupe non autorisé, workflow exclusif ou flux à détourner.
Input
Message brut de la plateforme, callbacks et contexte de session.
Output
Une décision simple : laisser passer, répondre de façon imposée, ou couper le flux tout de suite.
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.
02
Qui parle et avec quels droits
Identité et accès
On résout l'identité réelle, le type de chat, le niveau d'accès, la confiance du groupe, l'onboarding, les bans et les quotas journaliers.
Input
Message accepté à l'entrée plus données runtime et base d'autorisation.
Output
Un contexte de sécurité clair : qui parle, où, avec quels droits, et ce qu'on doit déjà refuser.
Guardrail
Les droits peuvent diminuer quand le contexte devient moins sûr ; ils n'augmentent jamais par accident.
03
Ce que le modèle a le droit de voir
Contexte du modèle
On prépare un contexte limité à la conversation courante : mémoire autorisée, commandes utiles, contexte local ou base, sans exposer les fichiers ou informations internes non autorisés.
Input
Contexte de sécurité, mémoire, contexte local, données métier et règles de non-divulgation.
Output
Le prompt système et le contexte minimal autorisés pour cette session.
Guardrail
Le modèle ne voit jamais tout le workspace ; il voit seulement ce dont il a besoin ici et maintenant.
04
Ce que le modèle a le droit d'utiliser
Outils et skills
On limite les outils, les skills et même certaines lectures de fichiers selon le niveau d'accès. Le modèle n'a pas accès au catalogue complet par défaut.
Input
Catalogue runtime des outils, snapshot des skills et contexte de sécurité déjà calculé.
Output
Une liste bornée de capacités réellement disponibles dans 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.
05
Ce qui a le droit de sortir
Sortie finale
La réponse du modèle est traitée comme non fiable. On détecte les fuites d'architecture, de secrets ou de données sensibles avant l'envoi final.
Input
Réponse générée, contexte de sécurité initial et règles de validation.
Output
Soit une réponse approuvée, soit une réponse bloquée ou remplacée par un message sûr.
Guardrail
Si la sortie ressemble à une fuite, elle ne part pas.
Regles non negociables
Ce site parle de sécurité réelle parce que chaque règle peut être appliquée et vérifiée.
Le but n'est pas de dire “faites confiance au prompt”. Le but est d'avoir des règles simples, observables et testables dans le code.
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
SQLUsers, 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
lockLes 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.
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'on pose quand on veut comprendre sans jargon inutile.
Des réponses courtes et concrètes, puis le contrat complet pour aller plus loin.
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.