Flussi di dati · 15 min di lettura
Intranet Crawler
Come viene indicizzato il contenuto dell'intranet della tua organizzazione e come vengono gestite in modo sicuro le query di ricerca tramite l'interfaccia MCP.
L’Intranet Crawler è un server MCP self-hosted che indicizza l’intranet della tua organizzazione e ne rende il contenuto ricercabile dagli assistenti AI — senza che alcun contenuto dell’intranet lasci la tua infrastruttura.
Il servizio funziona come due processi separati: una scansione in background che recupera e indicizza periodicamente le pagine della tua intranet, e un’interfaccia di interrogazione (server MCP) che Intric AI chiama quando la domanda di un utente richiede di cercare nel contenuto indicizzato.
Come viene indicizzato il contenuto
Sezione intitolata “Come viene indicizzato il contenuto”La scansione viene eseguita interamente all’interno del tuo cluster Kubernetes secondo una pianificazione. Non è coinvolto alcun dato utente né cronologia delle conversazioni. L’unico dato che lascia il pod durante l’indicizzazione sono i chunk di testo semplice inviati all’API di embedding esterna per essere convertiti in vettori di ricerca.
Tutti i dati in transito sono protetti da TLS 1.2 o superiore.
Passaggio 1 — Trigger pianificato della scansione
APScheduler avvia automaticamente una scansione — una scansione completa ogni notte alle 02:00 UTC e un aggiornamento incrementale ogni 30 minuti.
Non è coinvolto alcun dato utente. Lo scheduler viene eseguito all’interno del pod Kubernetes e comunica con il crawler tramite un event loop asyncio interno.
Come vengono gestite le query
Sezione intitolata “Come vengono gestite le query”Quando un utente pone una domanda che richiede una ricerca nell’intranet, Intric AI chiama il server MCP dell’intranet crawler. Intric agisce sempre da intermediario — il modello linguistico non contatta mai direttamente il server MCP.
Tutti i dati in transito sono protetti da TLS 1.2 o superiore.
Passaggio 1 — L’utente interagisce con Intric nel browser
L’utente scrive un messaggio a un assistente che ha configurato il tool MCP dell’intranet crawler.
Dati inviati al server di Intric:
- Il messaggio dell’utente
- La cronologia della chat
- Eventuali file allegati
Condivisione dei dati e privacy
Sezione intitolata “Condivisione dei dati e privacy”L’intranet crawler è progettato in modo che il contenuto dell’intranet della tua organizzazione resti all’interno della tua infrastruttura. Di seguito trovi un riepilogo di cosa viene inviato a servizi esterni e cosa rimane interno.
Scansione — API di embedding
Sezione intitolata “Scansione — API di embedding”L’unico servizio esterno che riceve dati durante l’indicizzazione è l’API di embedding. Vengono inviati solo chunk di testo semplice — nessun URL, titolo di pagina o metadato accompagna i chunk.
| Inviato all’API di embedding | Non inviato all’API di embedding |
|---|---|
|
|
Interrogazione — Server MCP
Sezione intitolata “Interrogazione — Server MCP”Il server MCP è ospitato nel tuo stesso cluster Kubernetes — non è un servizio di terze parti. Da Intric al server MCP vengono inviati solo la query di ricerca e un JWT per l’autenticazione.
| Inviato al server MCP | Non inviato al server MCP |
|---|---|
|
|
Hosting, autenticazione e credenziali
Sezione intitolata “Hosting, autenticazione e credenziali”Hosting
Sezione intitolata “Hosting”I server MCP ospitati da Intric sono ospitati in Svezia tramite il sub-responsabile Glesys AB. I server MCP sviluppati su misura e distribuiti nell’ambiente di un cliente vengono eseguiti nell’ambiente del cliente.
Quando ospitato in un’istanza specifica del cliente, ogni server MCP viene eseguito nel proprio pod Kubernetes con infrastruttura, database e un insieme rigido di regole dedicati che governano cosa può e non può raggiungere. I server MCP sono isolati logicamente l’uno dall’altro — un server non può raggiungerne un altro a meno che non venga stabilita una connessione esplicita tra loro.
Autenticazione e credenziali
Sezione intitolata “Autenticazione e credenziali”Tutti i segreti usati dall’intranet crawler sono archiviati in Kubernetes Secrets e iniettati come variabili d’ambiente all’avvio del pod — non sono mai esposti agli utenti o al browser.
- Server MCP: JWT (HS256) con un segreto condiviso (
MCP_SERVER_JWT_SECRET). Intric AI e il server MCP condividono questo segreto per autenticare ogni chiamata di ricerca. - Login dell’intranet: se l’intranet richiede un login, le credenziali basate su form vengono archiviate su un Persistent Volume cifrato con Fernet (AES-128-CBC). La chiave di cifratura viene montata come volume Kubernetes Secret.
- API di embedding: la chiave API (
EMBEDDING_API_KEY) è archiviata come Kubernetes Secret. - Interfaccia di amministrazione: il pannello di amministrazione basato su web (
/admin/) è protetto con HTTP Basic Auth. Una allowlist di IP (ALLOWED_IPS) limita quali indirizzi possono raggiungere l’endpoint del server MCP.
Conservazione ed eliminazione dei dati
Sezione intitolata “Conservazione ed eliminazione dei dati”La cronologia delle conversazioni in cui è stato usato il tool MCP dell’intranet crawler segue le stesse regole di eliminazione degli altri assistenti.
Il contenuto sottoposto a scansione e l’indice vettoriale sono archiviati sul Persistent Volume all’interno del tuo cluster Kubernetes. Le pagine che non sono cambiate dall’ultima scansione (rilevate tramite header ETag/Last-Modified) vengono saltate. Per svuotare l’indice, la collection ChromaDB può essere reimpostata tramite l’interfaccia di amministrazione o rimuovendo la PVC.
Gli amministratori possono monitorare come viene usato il servizio tramite il log di audit dove abilitato.