# Sécurité

> Identifiants, HTTPS, connexion et exposition réseau d'une installation PentAGI.

## [Modifier les valeurs par défaut](https://pentagi.com/fr/docs/configuration/security/#change-the-defaults)

Une nouvelle installation crée l’administrateur local `admin@pentagi.com` 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 `admin@pentagi.com`.

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 :

| Variable                                             | Objet                                                                                                            |
| ---------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------- |
| `COOKIE_SIGNING_SALT`                                | Signe les cookies de session et les jetons d’API — définissez une valeur aléatoire                               |
| `PENTAGI_POSTGRES_USER`, `PENTAGI_POSTGRES_PASSWORD` | Informations d’identification PostgreSQL                                                                         |
| `NEO4J_PASSWORD`                                     | Mot de passe Neo4j pour le [knowledge graph](https://pentagi.com/fr/docs/glossary/#knowledge-graph) ; `NEO4J_USER` doit rester `neo4j` |
| `PUBLIC_URL`                                         | L’URL ouverte par les utilisateurs, par exemple `https://pentagi.example.com`                                    |

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](https://pentagi.com/fr/docs/configuration/security/#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](https://pentagi.com/fr/docs/configuration/security/#users-and-sign-in)

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 `admin@pentagi.com`, 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 :

```bash
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](https://pentagi.com/fr/docs/configuration/security/#network-exposure)

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

```bash
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](https://pentagi.com/fr/docs/glossary/#sandbox) de chaque [flow](https://pentagi.com/fr/docs/glossary/#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](https://pentagi.com/fr/docs/glossary/#agent) 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](https://pentagi.com/fr/docs/configuration/security/#update-check)

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](https://pentagi.com/fr/docs/glossary/#task), de conteneurs, de prompts, de jetons API et de [tool calls](https://pentagi.com/fr/docs/glossary/#tool-call), 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.

> [!WARNING]
> Le conteneur `pentagi` s’exécute en tant que root car il gère des conteneurs via le socket Docker. Pour une isolation renforcée, exécutez les [tools](https://pentagi.com/fr/docs/glossary/#tool) sur un [worker node](https://pentagi.com/fr/docs/deployment/worker-node/) séparé.