Inventaire
Vue d’ensemble des publications avec statut, accès, échéance, verdict de scan et attestation lorsqu’elle existe.
Gouvernance des agents IA
Rendre les publications visibles avant de chercher à les interdire
Un agent peut produire un rapport ou un prototype en quelques secondes. Le risque apparaît quand l’organisation ignore où il est publié, sous quelle identité, avec quel accès et jusqu’à quelle date.
Le problème n’est pas le fichier statique
Une page HTML peut contenir une synthèse interne, des données de client, un secret copié depuis un environnement ou une dépendance qui contacte un service tiers. Lorsqu’elle est déposée sur un hébergement personnel ou non déclaré, l’équipe sécurité perd la capacité de répondre à des questions simples : qui l’a créée, qui peut l’ouvrir, quand doit-elle disparaître et quelle preuve restera après suppression ?
Bloquer tous les outils ne répond pas au besoin de livraison. Une voie gouvernée doit rendre le geste court tout en appliquant des règles impossibles à contourner depuis le client de publication.
Le modèle actuel
Policy côté serveur
Mode DLP minimal, durée maximale et modes d’accès autorisés appliqués aux nouvelles publications.
Identité
Compte membre authentifié pour le publieur ; le nom d’agent reste une métadonnée déclarative fournie par le client.
Audit
Événements append-only consultables et registre exportable en CSV, avec neutralisation des cellules susceptibles d’être interprétées comme formules.
Fin de vie
Expiration, désactivation, suppression et preuve associée restent des événements distincts dans le registre.
Contrat
DPA versionné, hash du texte et liste des sous-traitants enregistrés lors de la signature du DPA.
Une policy appliquée au point de création
L’administrateur du workspace peut fixer pii_mode, max_expiry et allowed_access_modes. Lorsqu’un membre ou un agent demande une publication plus permissive, l’API la refuse ou renforce le mode DLP selon la règle. Le tableau de bord, l’API, le skill et le MCP convergent vers ce même contrôle serveur.
Le réglage de cette policy est actuellement exposé par l’API, sans écran d’administration dédié dans le tableau de bord. Une équipe doit donc prévoir son appel dans son processus d’initialisation ou d’exploitation.
La policy n’est pas rétroactive. Modifier une durée maximale ou interdire le mode public ne réécrit pas les sites déjà en ligne. Le registre conserve les paramètres autorisés au moment de chaque création ; l’équipe doit traiter séparément le parc antérieur.
Identité humaine et provenance d’agent
Le compte authentifié identifie le membre qui agit. Un en-tête peut ajouter le nom de l’agent ou du pipeline pour faciliter l’analyse du registre. Ce libellé est déclaratif : il ne prouve pas qu’un binaire précis, une version signée ou un poste géré a exécuté la requête.
Cette distinction évite de transformer une colonne d’inventaire en preuve d’identité machine. Une organisation qui exige une attestation de workload doit compléter EZOU.EU avec son IAM, ses identités CI et ses journaux de poste.
Registre et audit exportable
Le registre réunit les publications actives, expirées et supprimées. Elle conserve accès, échéance, verdict DLP, acteur, provenance déclarée et attestation disponible. L’export CSV permet une conservation dans les outils du client ; les valeurs commençant comme une formule de tableur sont neutralisées.
Le registre trace ce que le service connaît. Il ne découvre pas automatiquement une publication faite sur un autre hébergeur, depuis un compte personnel ou sous un domaine extérieur. La couverture organisationnelle dépend donc aussi des règles internes et de l’adoption du canal.
Clôture et preuve
La durée maximale réduit le nombre de liens oubliés, mais un worker et des contrôles d’exploitation restent nécessaires. La suppression produit une attestation signée sur la purge du stockage principal déclaré. Elle ne couvre pas une copie téléchargée, une sauvegarde non documentée ou un autre service utilisé hors d’EZOU.EU.
Limites actuelles à intégrer dans l’achat
- pas de rôles administratifs fins ou de RBAC public documenté ;
- pas de SSO d’entreprise décrit comme contrôle actif ;
- pas de découverte automatique des hébergements extérieurs ;
- pas de SLA, RPO ou RTO public à ce jour ;
- preuves d’exploitation, restauration et pentest encore distinctes des contrôles de code.
Décision d’achat
Le questionnaire prérempli, les mesures techniques et le DPA indiquent ce qui est implémenté, documenté ou encore à valider.
Questions fréquentes
Qu’appelle-t-on shadow hosting dans ce contexte ?
La publication d’un artefact sur un service ou sous une identité que l’organisation ne peut pas inventorier, encadrer ou clôturer selon ses propres règles.
La policy modifie-t-elle les sites déjà en ligne ?
Non. Elle s’applique aux publications futures. Les sites existants gardent les paramètres autorisés au moment de leur création et le registre conserve ce contexte.
Le champ agent prouve-t-il quel logiciel a réellement publié ?
Non. L’utilisateur du compte est authentifié, mais le libellé d’agent est fourni par le client. Il aide à l’inventaire sans constituer une attestation cryptographique du logiciel.
EZOU.EU remplace-t-il un SIEM, un CASB ou un système IAM complet ?
Non. Il fournit un registre spécialisé, des règles de publication et un export. Il ne revendique ni corrélation SIEM, ni découverte réseau globale, ni rôles administratifs fins.
Évaluation de l’offre
Commencer par la policy et le registre attendus
Définissez les accès autorisés, la durée maximale et la preuve que vos équipes devront conserver.