Intranet-Crawler

Der Intranet-Crawler ist ein selbst gehosteter MCP-Server, der das Intranet deiner Organisation indiziert und seinen Inhalt für KI-Assistenten durchsuchbar macht – ohne dass Intranet-Inhalte deine eigene Infrastruktur verlassen.

Der Dienst läuft als zwei separate Prozesse: ein Hintergrund-Crawl, der in regelmäßigen Abständen Seiten aus deinem Intranet abruft und indiziert, sowie eine Abfrageschnittstelle (MCP-Server), die Intric KI aufruft, wenn die Frage eines Nutzers eine Suche im indizierten Inhalt erfordert.

Wie Inhalte indiziert werden

Der Crawl läuft vollständig in deinem eigenen Kubernetes-Cluster nach einem Zeitplan. Es sind keine Nutzerdaten oder Konversationsverläufe involviert. Die einzigen Daten, die den Pod während der Indizierung verlassen, sind reine Textabschnitte, die an die externe Embedding-API gesendet werden, um in Suchvektoren umgewandelt zu werden.

Alle Daten während der Übertragung sind durch TLS 1.2 oder höher geschützt.

Schritt 1 — Geplanter Crawl-Auslöser

APScheduler löst einen Crawl automatisch aus — einen vollständigen Crawl jede Nacht um 02:00 UTC und ein inkrementelles Update alle 30 Minuten.

Es sind keine Nutzerdaten involviert. Der Scheduler läuft innerhalb des Kubernetes-Pods und kommuniziert mit dem Crawler über eine interne asyncio-Ereignisschleife.

1 / 5

Wie Abfragen verarbeitet werden

Wenn ein Nutzer eine Frage stellt, die eine Suche im Intranet erfordert, ruft Intric KI den MCP-Server des Intranet-Crawlers auf. Intric fungiert immer als Vermittler — das Sprachmodell kontaktiert den MCP-Server nie direkt.

Alle Daten während der Übertragung sind durch TLS 1.2 oder höher geschützt.

Schritt 1 — Nutzer interagiert mit Intric im Browser

Der Nutzer schreibt eine Nachricht an einen Assistenten, der das Intranet-Crawler-MCP-Tool konfiguriert hat.

An Intrics Server gesendete Daten:

Die Nachricht des Nutzers
Konversationsverlauf
Angehängte Dateien

Schritt 2 — Intric ruft den MCP-Server auf

Intric KI stellt fest, dass eine Suche im Intranet erforderlich ist, und ruft das search_intranet-Tool des MCP-Servers auf. Der Aufruf wird mit einem JWT Bearer-Token (HS256) authentifiziert.

Von Intrics Server an den MCP-Server gesendete Daten:

Die Suchanfrage (eine vom Sprachmodell generierte natürlichsprachige Zeichenkette)
JWT Bearer-Token (im Authorization-Header)

Die Identität des Nutzers — Name, E-Mail, IP-Adresse — ist nicht im Suchaufruf enthalten. Der MCP-Server verifiziert das JWT mit einem gemeinsamen Geheimnis, das in einem Kubernetes Secret gespeichert ist.

Was innerhalb des MCP-Servers passiert:

Die Anfrage wird mit derselben Embedding-API, die bei der Indizierung verwendet wurde, in einen Einbettungsvektor umgewandelt
ChromaDB führt eine Cosinus-Ähnlichkeitssuche durch und gibt die relevantesten Textabschnitte zurück
Vom Nutzer eingereichte Korrekturen für diese Anfrage werden in den Ergebnissen priorisiert

1 / 4

Datenweitergabe und Datenschutz

Der Intranet-Crawler ist so konzipiert, dass die Intranet-Inhalte deiner Organisation innerhalb deiner eigenen Infrastruktur verbleiben. Nachfolgend eine Übersicht, was an externe Dienste gesendet wird und was intern bleibt.

Crawl — Embedding-API

Der einzige externe Dienst, der während der Indizierung Daten empfängt, ist die Embedding-API. Es werden nur reine Textabschnitte gesendet — keine URLs, Seitentitel oder sonstige Metadaten begleiten die Abschnitte.

An die Embedding-API gesendet	Nicht an die Embedding-API gesendet
Reine Textabschnitte aus Intranet-Seiten (keine Identitätsmetadaten)	Quell-URLs und Seitentitel Intranet-Anmeldedaten Nutzerdaten oder Konversationsdaten aus Intric Personenbezogene Daten von Nutzern in Intric: Name E-Mail IP-Adresse Organisationszugehörigkeit

Abfrage — MCP-Server

Der MCP-Server wird in deinem eigenen Kubernetes-Cluster gehostet — es handelt sich nicht um einen Drittanbieterdienst. Nur die Suchanfrage und ein JWT zur Authentifizierung werden von Intric an den MCP-Server gesendet.

An den MCP-Server gesendet	Nicht an den MCP-Server gesendet
Die Suchanfrage (vom Sprachmodell generierte natürlichsprachige Zeichenkette) JWT Bearer-Token (zur Authentifizierung — enthält keine personenbezogenen Nutzerdaten)	Der vollständige ursprüngliche Prompt des Nutzers Konversationsverlauf Angehängte Dateien Personenbezogene Daten des Nutzers in Intric, der mit dem Assistenten interagiert, sofern sie nicht in der Nachricht an den Assistenten erscheinen: Name E-Mail IP-Adresse Organisationszugehörigkeit

Hosting, Authentifizierung und Anmeldedaten

Hosting

Von Intric gehostete MCP-Server werden in Schweden mit dem Unterauftragsverarbeiter Glesys AB gehostet. Individuell entwickelte MCP-Server, die in der Umgebung eines Kunden eingesetzt werden, laufen in der Umgebung des Kunden.

Bei einer kundenspezifischen Instanz läuft jeder MCP-Server in seinem eigenen Kubernetes-Pod mit dedizierter Infrastruktur, eigenen Datenbanken und strengen Regeln, die festlegen, worauf er zugreifen darf und worauf nicht. MCP-Server sind logisch voneinander isoliert — ein Server kann keinen anderen erreichen, sofern keine explizite Verbindung zwischen ihnen hergestellt wird.

Authentifizierung und Anmeldedaten

Alle Geheimnisse, die vom Intranet-Crawler verwendet werden, sind in Kubernetes Secrets gespeichert und werden beim Pod-Start als Umgebungsvariablen eingefügt — sie werden nie Nutzern oder dem Browser zugänglich gemacht.

MCP-Server: JWT (HS256) mit einem gemeinsamen Geheimnis (MCP_SERVER_JWT_SECRET). Intric KI und der MCP-Server teilen dieses Geheimnis, um jeden Suchaufruf zu authentifizieren.
Intranet-Anmeldung: Wenn das Intranet eine Anmeldung erfordert, werden formularbasierte Anmeldedaten auf einem mit Fernet (AES-128-CBC) verschlüsselten Persistent Volume gespeichert. Der Verschlüsselungsschlüssel wird als Kubernetes Secret Volume eingebunden.
Embedding-API: Der API-Schlüssel (EMBEDDING_API_KEY) wird als Kubernetes Secret gespeichert.
Admin-Oberfläche: Das webbasierte Admin-Panel (/admin/) ist mit HTTP Basic Auth geschützt. Eine IP-Zulassungsliste (ALLOWED_IPS) schränkt ein, welche Adressen den MCP-Server-Endpunkt erreichen können.

Datenspeicherung und Löschung

Konversationsverläufe, in denen das Intranet-Crawler-MCP-Tool verwendet wurde, folgen denselben Löschregeln wie bei anderen Assistenten.

Data Retention

Die gecrawlten Inhalte und der Vektorindex werden auf dem Persistent Volume innerhalb deines Kubernetes-Clusters gespeichert. Seiten, die sich seit dem letzten Crawl nicht geändert haben (erkannt über ETag/Last-Modified-Header), werden übersprungen. Um den Index zu löschen, kann die ChromaDB-Sammlung über die Admin-Oberfläche zurückgesetzt oder der PVC entfernt werden.

Administratoren können die Nutzung des Dienstes über das Audit-Log überwachen, sofern aktiviert.

Audit Log