Sécurité

Modifier les valeurs par défaut

Une nouvelle installation crée l’administrateur local [email protected] avec le mot de passe admin, qui doit être modifié dès la première connexion. Si le mot de passe est perdu, le menu de maintenance de l’installateur le réinitialise tant que le compte utilise toujours l’adresse [email protected].

Définissez ces valeurs dans .env avant le premier démarrage ; l’installateur génère le sel et les mots de passe pour vous. PostgreSQL et Neo4j ne prennent en compte leurs identifiants qu’à la création de leurs volumes de données, donc les modifier ultérieurement rompt la connexion :

Sur une installation en cours d’exécution, modifiez d’abord un mot de passe de base de données dans PostgreSQL ou Neo4j, puis dans .env.

HTTPS

PentAGI sert HTTPS sur le port 8443 avec un certificat auto-signé. Pour utiliser votre propre certificat, définissez SERVER_SSL_CRT et SERVER_SSL_KEY et montez les fichiers dans docker-compose.yml.

Utilisateurs et connexion

Il n’y a pas de formulaire d’inscription. Les administrateurs gèrent les utilisateurs locaux via l’API Users (/api/v1/users/) depuis une session de navigateur connectée — un jeton API y renvoie une erreur 403 — et les rôles limitent ce que chaque utilisateur peut voir et modifier. Les utilisateurs locaux modifient leur propre adresse e-mail et leur mot de passe sous Settings → Account.

Lorsque la connexion via GitHub ou Google est configurée, une connexion dont l’adresse e-mail vérifiée par le fournisseur correspond à un compte existant, y compris les comptes locaux, permet de se connecter à ce compte avec son rôle ; toute autre connexion crée un nouveau compte avec le rôle utilisateur par défaut. Chaque installation démarre avec l’administrateur [email protected], donc déplacez-le vers une adresse que vous contrôlez sous Settings → Account avant d’activer la connexion, et n’activez celle-ci que si la création de nouveaux comptes est acceptable, par exemple avec une application Google Workspace limitée à votre domaine.

La connexion via GitHub et Google est disponible via OAuth. Enregistrez une application avec l’URL de rappel ${PUBLIC_URL}/api/v1/auth/login-callback et ajoutez ses informations d’identification :

PUBLIC_URL=https://pentagi.example.com
OAUTH_GITHUB_CLIENT_ID=your_github_client_id
OAUTH_GITHUB_CLIENT_SECRET=your_github_client_secret

Exposition réseau

Par défaut, l’interface web de PentAGI écoute uniquement sur 127.0.0.1. Pour y accéder depuis d’autres machines :

PENTAGI_LISTEN_IP=0.0.0.0
PENTAGI_LISTEN_PORT=8443
PUBLIC_URL=https://192.168.1.100:8443
CORS_ORIGINS=https://localhost:8443,https://192.168.1.100:8443

Utilisez l’adresse réelle dans PUBLIC_URL et CORS_ORIGINS, jamais 0.0.0.0. Recréez les conteneurs avec docker compose up -d --force-recreate et ouvrez le port 8443 dans le pare-feu.

Derrière un proxy inverse, définissez TRUSTED_PROXIES sur l’adresse ou le CIDR du proxy, séparés par des virgules. Sinon, chaque requête semble provenir du proxy, et la limite de connexions par adresse — 30 tentatives échouées en cinq minutes, puis un verrouillage de 15 minutes — est partagée par tous les utilisateurs.

Le conteneur sandbox de chaque flow expose également deux ports pour les rappels hors bande, tels que les reverse shells. Ils proviennent des 2000 ports qui commencent à DOCKER_PORTS_BASE (par défaut 28000) et sont liés à DOCKER_PUBLIC_IP, l’adresse que les agents indiquent également aux cibles pour le rappel.

Par défaut, DOCKER_PUBLIC_IP est 0.0.0.0 : les ports écoutent sur toutes les interfaces de l’hôte Docker, et les agents déterminent eux-mêmes leur adresse publique. Définissez une adresse spécifique uniquement si l’hôte possède cette adresse et que les cibles peuvent l’atteindre ; derrière un NAT, conservez la valeur par défaut. Les ports publiés par Docker contournent les règles ufw et firewalld sur l’hôte, donc restreignez la plage avec un pare-feu placé devant l’hôte, tel qu’un groupe de sécurité cloud, ou avec des règles dans la chaîne DOCKER-USER de Docker.

PROXY_URL achemine les appels du backend vers les providers de modèles, le provider d’embeddings, les API de recherche et la vérification des mises à jour via un proxy, ce qui permet d’isoler l’installation des réseaux externes. Les points de terminaison auto-hébergés tels qu’Ollama, vLLM ou SearXNG passent également par lui, car il n’existe aucune exception NO_PROXY, donc le proxy doit pouvoir les atteindre. Les conteneurs sandbox des flows, où les agents exécutent leurs commandes, le scraper, qui ouvre les pages web pour l’outil browser, et le service Graphiti ne l’utilisent pas ; limitez donc leur trafic sortant au niveau réseau. La connexion avec GitHub ou Google et les appels vers un point de terminaison Langfuse ou OpenTelemetry en dehors des stacks inclus ne l’utilisent pas non plus, et le daemon Docker récupère les images avec ses propres paramètres de proxy.

Vérification des mises à jour

Deux minutes après le démarrage, puis toutes les trois heures, le serveur demande à update.pentagi.com si une version plus récente est disponible. La requête contient l’ID d’installation, la clé de licence si elle est définie, la version et la plateforme, ainsi qu’un résumé de l’installation : le provider configuré et les types de connexion, quelques commutateurs de fonctionnalités, le nombre d’utilisateurs, de flows, de tasks, de conteneurs, de prompts, de jetons API et de tool calls, et les totaux de jetons et de coûts par type de provider — aucun nom, adresse, prompt ou contenu de flow. UPDATE_CHECK_INTERVAL=0 permet de désactiver cette fonctionnalité. À chaque démarrage de l’installateur et après chaque action qu’il exécute, telle que Apply Changes, Update, Start ou Stop, il envoie les images installées et l’état de chaque stack, ainsi que le même résumé tant que PentAGI est en cours d’exécution ; UPDATE_CHECK_INTERVAL ne l’affecte pas.