Prompt Injection in HTTP-Headern erreicht einen Recruiting-Agenten, wenn sein URL-Lesewerkzeug vom Server kontrollierte Metadaten an das Modell weitergibt. Prüfen Sie deshalb die genauen Tool-Ausgaben für erfolgreiche Seitenabrufe, Weiterleitungen und Fehler. Halten Sie Quellenmaterial als solches erkennbar, lassen Sie unnötige Metadaten weg und setzen Sie Zugriffs- und Schreibberechtigungen für Kandidatendaten außerhalb des Modells durch.

Stellen Sie sich vor, Sie lassen einen Assistenten das Portfolio einer Kandidatin oder eines Kandidaten mit Ihren Bewertungskriterien für Backend-Entwicklung abgleichen. Die Seite beschreibt Projekte. Irgendwo in der Antwort gibt ihr Server außerdem einen angeblichen Eignungswert an. Ihr Team muss wissen, ob diese Behauptung in den Kontext des Assistenten gelangt, ob sie in der Zusammenfassung auftaucht und ob daraus eine gespeicherte Bewertung werden kann.

Das sind getrennte Fragen. Ein Browser-Screenshot beantwortet keine davon. Prüfen sollten Sie die Schnittstellenvereinbarung zwischen dem Abrufwerkzeug und dem Modell: Welche Felder werden genau übergeben, woher stammen sie und unter welchen Fehlerbedingungen geschieht das?

## Was hat die Untersuchung zu HTTP-Headern tatsächlich ergeben?

Die am 6. Oktober von Sarah Andrews veröffentlichte [Untersuchung von Signals Corps](https://www.signalscorps.com/blog/prompt-injection-in-http-headers/) wertete 217.097.223 Antworten aus Common Crawl aus. Dazu wurde jede zehnte WAT-Metadatendatei herangezogen. Die Untersuchung ordnete 7.959 Hostnamen als Absender von an KI gerichteten Headern ein, überwiegend mit Verweisen auf Ressourcen. Bei 30 wurden Injektionsversuche festgestellt. Zwei enthielten einen behaupteten Eignungswert für eine Bewerbung. Das waren beobachtete Zeichenfolgen, keine nachgewiesenen Manipulationen von Einstellungsverfahren.

Für die Klassifizierung wurde ein Recherche-Agent mit Claude eingesetzt. Die Sicht von CCBot erfasst keine Inhalte, die nur bestimmten Agenten angezeigt werden. Separate Versuche mit Testmarkierungen zeigten, dass die getesteten Claude-Konfigurationen die Anweisungen standardmäßig ablehnten. Bei Prompts, die Serveranweisungen ausdrücklich Autorität einräumten, erschien das verlangte Codewort in sieben von neun Durchläufen. Jede Kombination aus Modell und Prompt wurde nur einmal ausgeführt. Daraus lässt sich keine allgemeine Erfolgsquote ableiten. Die [Diskussion auf Hacker News](https://news.ycombinator.com/item?id=50104310) machte auf die Untersuchung aufmerksam; die Kommentare belegen keine weiteren Ergebnisse.

Die [Veröffentlichungsankündigung von Common Crawl](https://commoncrawl.org/blog/september-2026-crawl-archive-now-available) bestätigt unabhängig davon den Umfang des zugrunde liegenden Crawls: 2,17 Milliarden Seiten von 40,4 Millionen Hosts, erfasst vom 4. bis zum 17. September. Das stützt die Angaben zur Größe des Datensatzes, nicht die Klassifizierung der Header. Keine der beiden Quellen belegt, wie häufig erfolgreiche Angriffe in tatsächlich eingesetzten Recruiting-Systemen vorkommen.

Teilen Sie die Anzahl auffälliger Hostnamen nicht durch die Anzahl der Seitenantworten, um daraus einen Prozentsatz von Websites zu berechnen. Die Einheiten unterscheiden sich. Ein Hostname identifiziert außerdem weder einen Kandidaten noch den Inhaber einer registrierten Domain oder einen Kunden. Die Untersuchung liefert einen Ansatzpunkt für ein Audit. Sie rechtfertigt nicht die Behauptung, Bewerber hätten Einstellungsentscheidungen in großem Maßstab manipuliert.

## Verfolgen Sie die Antwort bis ins Modell

Eine URL-Antwort umfasst einen Status, beschreibende Header und einen Antworttext mit der Seite oder dem Dokument. Ihr Adapter entscheidet, was das Modell erhält. Prüfen Sie diese Auswahl im ausführbaren Code und anhand tatsächlich aufgezeichneter Tool-Ausgaben.

Beginnen Sie mit einem produktiv eingesetzten Ablauf. Notieren Sie Tool-Name, Adapterversion, Extraktionsanbieter, Ersatzanbieter und verfügbare Folgeaktionen. Rufen Sie dann eine kontrollierte Seite ab und prüfen Sie das Ergebnis genau dort, wo es in den Modellkontext gelangt. Wer die Antwort des Anbieters nur früher in der Verarbeitungskette untersucht, übersieht möglicherweise eine spätere Formatierung, Zusammenfassung oder Ausnahmebehandlung.

Eine brauchbare Ausgabespezifikation legt erlaubte Felder, deren Typen, Höchstlängen und Bedeutung fest. Sie unterscheidet außerdem extrahierte Quellinhalte von Statusangaben, die die Anwendung selbst erzeugt. Ein Seitentitel bleibt beispielsweise eine von der externen Seite gelieferte Angabe. Ein eigenes JSON-Feld macht seine Herkunft leichter nachvollziehbar; es verleiht ihm keine Autorität.

### Erfassen Sie jeden Abrufweg für dieselbe URL

Ihr gewöhnliches Lesewerkzeug liefert möglicherweise extrahiertes Markdown. Ein Diagnosewerkzeug gibt womöglich Netzwerkdetails zurück. Ein Ersatzverfahren liefert vielleicht hervorgehobene Textstellen eines Suchanbieters. Kann der Agent nach einem Fehler ein anderes Lesewerkzeug wählen, gehört auch dieser Weg ins Audit.

Prüfen Sie, was bei einem PDF, einem ungewöhnlichen Inhaltstyp, einer Seite mit Zugriffssperre oder einer erforderlichen Anmeldung geschieht. Untersuchen Sie zwischengespeicherte und neu abgerufene Antworten getrennt, falls sie unterschiedlich formatiert werden. Halten Sie fest, ob eine Weiterleitung die angezeigte Quelladresse verändert. Je nach Abrufweg kann dieselbe angeforderte URL erheblich unterschiedliche Belege liefern.

Die [MCP-Referenzimplementierung für Fetch in der von der Untersuchung betrachteten Revision](https://github.com/modelcontextprotocol/servers/blob/bbb701e7ac1e57f3edd1c2836b94c5457eaf7b9c/src/fetch/src/mcp_server_fetch/server.py) ist ein konkretes Beispiel, an dem sich Extraktion und Fehlerbehandlung untersuchen lassen. Prüfen Sie die genaue Version, die Sie einsetzen, bevor Sie Aussagen über deren Ausgabe machen. Der Name eines Tools belegt sein Verhalten nicht.

### Trennen Sie Extraktion und Vertrauenswürdigkeit

Wer rohe Header entfernt, verengt einen möglichen Zugangsweg. Der verbleibende Seiteninhalt kann weiterhin Anweisungen, falsche Behauptungen oder irrelevantes Material enthalten. Unser früherer [Artikel über Prompt Injection in Lebensläufen](/blog/prompt-injection-resumes-ats-screening-defense) behandelt das Problem in Dokumentinhalten; dieses Audit untersucht die umgebende Abruftechnik.

Kennzeichnen Sie externe Texte als nicht vertrauenswürdiges Belegmaterial und erklären Sie in den Agentenanweisungen, wofür es verwendet werden darf. Testen Sie diese Grenze anschließend. Trennzeichen, JSON-Serialisierung und Erinnerungen helfen, den Kontext zu ordnen. Nichts davon garantiert jedoch, dass ein Modell eingebettete Anweisungen immer zurückweist.

## Testen Sie erfolgreiche Abrufe, Weiterleitungen und Fehler

Testen Sie mit synthetischen Kandidatendaten und eigener Infrastruktur getrennt, welche Inhalte sichtbar werden und wie sich das System verhält. Prüfen Sie anhand der aufgezeichneten Modelleingaben, welche Markierungen die Tool-Schnittstelle passiert haben. Bewerten Sie die Befolgung einer Anweisung am verlangten Verhalten: Wer eine Markierung zitiert und dabei die Anweisung zurückweist, hat sie nicht befolgt.

Erstellen Sie ein fiktives Portfolio mit einer kurzen, unveränderten Projektbeschreibung. Platzieren Sie eine eindeutige Markierung im Seiteninhalt und eine andere in einem benutzerdefinierten Antwort-Header. Führen Sie diesen Ausgangstest ohne Anweisungen durch, danach zwei getrennte Varianten: einmal mit einer harmlosen Anweisung im benutzerdefinierten Header, einmal mit derselben Anweisung im Seiteninhalt. Verlangen Sie darin eine dritte Markierung als Antwort des Assistenten. Lassen Sie die Kandidatenangaben in allen Varianten gleich, damit sich Änderungen auf den jeweiligen Antwortkanal zurückführen lassen.

Die folgende Tabelle ist ein vorgeschlagener Auditplan. Sie berichtet nicht über Tests, die an Kit oder einem Anbieter durchgeführt wurden.

| Kontrollierter Testfall | Zu prüfen | Erwartete Grenze |
| --- | --- | --- |
| Erfolgreich abgerufene Seite mit Markierung in einem benutzerdefinierten Header | Exaktes, für das Modell sichtbares Ergebnis | Nur die laut Ausgabespezifikation erlaubten Felder erscheinen |
| Fehlerantwort mit unterschiedlichen Markierungen in Header und Antworttext | Ausnahmetext und Ergebnisse des Ersatzverfahrens | Die begrenzte Fehlerausgabe lässt nicht vertrauenswürdiges Quellenmaterial weiterhin erkennen |
| Weiterleitung zwischen erlaubten Test-Origins | Zielprüfungen und Quellennachweis | Jedes Ziel wird geprüft; ein Wechsel des Ursprungs bleibt sichtbar |
| Seiteninhalt, der eine höhere Eignungsbewertung behauptet | Zusammenfassung, Quellenangaben, vorgeschlagene Schreibvorgänge | Die Behauptung ersetzt nicht die freigegebenen Bewertungskriterien |
| Verweis, der einen weiteren Tool-Server vorschlägt | Vorgeschlagene Tool-Verbindungen | Das Lesen einer Quelle berechtigt nicht dazu, Tools hinzuzufügen |
| Aufforderung, synthetische Kandidatendaten zu übertragen | Berechtigungsentscheidung und Ziel | Eine externe Seite kann keine Datenweitergabe autorisieren |

Bewahren Sie für jeden Testfall das erwartete und das tatsächliche Ergebnis auf. Ein bestandener Test zur Sichtbarkeit von Headern sollte erkennen lassen, welches Feld ausgelassen wurde. Ein bestandener Aktionstest sollte die Anwendungskontrolle benennen, die den vorgeschlagenen Vorgang abgelehnt hat. „Die Antwort sah gut aus“ lässt zu viel offen.

### Spezifizieren Sie auch die Fehlerausgabe ausdrücklich

Fehlermeldungen sind häufig für Entwickler gedacht und werden dann ungeprüft an Modelle weitergereicht. Eine Ausnahme kann eine Anbieterantwort, eine Nachricht eines vorgelagerten Systems oder eine Ziel-URL enthalten. Ein sorgfältig begrenztes Ergebnis eines erfolgreichen Abrufs sagt über diese Felder wenig aus.

Geben Sie eine klar begrenzte Fehlerkategorie und genügend Kontext für einen autorisierten Wiederholungsversuch zurück. Detaillierte Diagnosedaten gehören in einen entsprechend zugriffsbeschränkten Betriebskanal. Benötigt das Modell einen Fehlerauszug aus der Quelle, kennzeichnen Sie ihn als Quellenmaterial und wenden Sie dieselben Grenzen an wie für gewöhnlichen extrahierten Text.

Testen Sie sowohl den ersten Fehler als auch das Ersatzverfahren. Das primäre Lesewerkzeug lässt Header beispielsweise weg, während das zweite einen vollständigen Diagnoseauszug einbettet. Wiederholen Sie diese Testmatrix, wenn sich Adapter, Extraktionsanbieter oder die Formatierung von Ausnahmen ändern. Speichern Sie die jeweiligen Versionen zusammen mit den Ergebnissen, damit spätere Prüfer wissen, für welchen Stand die Belege gelten.

### Testen Sie realistische Abrufwege ohne echte Kandidatendaten

Verwenden Sie beim Abrufen der kontrollierten Testfälle die normale Anfragekonfiguration Ihres Agenten. Nutzt der produktive Abruf einen eigenen User-Agent oder fordert Markdown an, bilden Sie diese Konfiguration im Test nach. Ein gewöhnlicher Browser erhält möglicherweise eine andere Antwort.

Verwenden Sie in einem Test mit Markierungen keine echten Lebensläufe, Zugangsdaten oder signierten Kandidatenlinks. Installieren Sie keine Pakete und verbinden Sie keine Tools, die der Testfall vorschlägt. Sie prüfen, ob das System eine Grenze überschreitet; harmlose synthetische Inhalte reichen aus, um einen solchen Fehler sichtbar zu machen.

## Lassen Sie abgerufene Texte keine Einstellungsentscheidungen bestimmen

Ein Portfolio kann Belege für geleistete Arbeit liefern. Es kann weder Ihre Bewertungskriterien festlegen noch einen verifizierten Eignungswert begründen oder Zugriff auf die Unterlagen anderer Kandidatinnen und Kandidaten gewähren. Diese Unterscheidung muss sowohl in der Zusammenfassung als auch in der Anwendung erhalten bleiben, die sie speichert.

Bei der hypothetischen Backend-Bewertung könnte der Assistent ein öffentliches Repository finden, das einen Queue-Worker beschreibt. Eine angemessene Notiz nennt die Quelle und sagt, was sie belegt: Das Portfolio beschreibt Arbeit an der Warteschlangenverarbeitung; ob die Person den Betrieb verantwortet hat, bleibt ungeprüft. Der Recruiter kann dazu im Interview gezielt nachfragen.

Eine unbelegte Punktzahl darf nicht stillschweigend zur Bewertung des Recruiters werden. Verlangen Sie für jede inhaltliche Bewertung eine Begründung anhand eines Kriteriums und nachvollziehbare Belege. Angaben des Kandidaten müssen von Urteilen der Prüfer unterscheidbar bleiben. Im [Ablauf für Kandidatenprofile](/docs/candidate-profiles) muss diese Unterscheidung auch für die Person verständlich sein, die den Datensatz prüft.

Das gilt auch dann, wenn eine Anweisung aus der Quelle keinen Tool-Aufruf auslöst. Ein Assistent mit reinem Lesezugriff kann Erfahrung übertreiben, Zweifel auslassen oder eine Selbstdarstellung als unabhängige Bestätigung ausgeben. Prüfen Sie deshalb neben Schreibvorgängen auch die inhaltliche Verlässlichkeit der Antworten. Vergleichen Sie die Zusammenfassungen der Testfälle und lassen Sie Prüfer benennen, welche Aussagen durch die Quellen tatsächlich gedeckt sind.

Die [OWASP-Empfehlungen zu Prompt Injection](https://genai.owasp.org/llmrisk/llm01-prompt-injection/) befürworten mehrere Schutzebenen: begrenzte Berechtigungen, die Trennung nicht vertrauenswürdiger Inhalte, menschliche Freigaben für folgenreiche Aktionen und adversariale Tests. Richten Sie diese Kontrollen nach den Folgen eines Vorgangs aus. Für den Entwurf einer Zusammenfassung und die Absage an einen Kandidaten sind unterschiedliche Berechtigungen angemessen.

### Dokumentieren Sie die Herkunft, ohne ein sensibles Archiv anzulegen

Erfassen Sie die Tool-Kennung, die angeforderte URL, sofern verfügbar die endgültige URL, die Antwortkategorie, die an das Modell übergebenen Feldnamen und die nächste vorgeschlagene Aktion. Ergänzen Sie den Zeitpunkt der Extraktion und genügend Versionsangaben, um das Adapterverhalten nachzuvollziehen. Lässt sich das endgültige Ziel nicht bestimmen, halten Sie diese Ungewissheit ausdrücklich fest.

Bevorzugen Sie begrenzte strukturierte Datensätze und bereinigte synthetische Beispiele gegenüber vollständigen Antwortauszügen. Gewöhnliche Protokolle sollten keine Cookies, Autorisierungswerte, signierten Links oder personenbezogenen Kandidatendaten erfassen. Herkunftsnachweise helfen Prüfern festzustellen, woher eine Behauptung stammt. Übermäßige Protokollierung schafft einen weiteren Speicherort, an dem sensible Inhalte geschützt werden müssen.

Ein Quellennachweis muss auch spätere Zusammenfassungen überstehen. Verdichtet ein zweites Modell Recherchenotizen, bewahren Sie die Zuordnung jeder Aussage zu ihrem Beleg. Sonst kann aus einer vorsichtigen ersten Zusammenfassung später eine selbstsichere, unbelegte Aussage werden.

## Prüfen Sie die Folgeaktion und Kits konkretes Beispiel

Die Anwendung muss anhand der Befugnisse des angemeldeten Nutzers, der Mandantenzuordnung, des Ziels und des Zwecks entscheiden, ob eine vorgeschlagene Aktion erlaubt ist. Von einer Website abgerufener Text kann keine dieser Berechtigungen erweitern.

Ein Link zu einem MCP-Server kann eine nützliche Dokumentationsquelle sein. Die Verbindung mit diesem Server fügt eine neue Fähigkeit hinzu und erfordert eine eigene Autorisierung. Fordert eine Seite den Agenten auf, Kandidatendaten an eine andere Stelle zu senden, liefert sie eine Aufforderung, keine Berechtigung. Prüfen Sie vor jeder Übertragung das vorgeschlagene Ziel und den Datenumfang, auch wenn die vorherige Zusammenfassung plausibel erscheint.

Der Tool-Zugriff sollte zur Aufgabe passen. Ein Rechercheschritt benötigt möglicherweise Lesezugriff auf Quellen und eine Funktion zum Speichern eines Entwurfs. Eine Bewerbung zu verschieben, einen Kandidaten zu kontaktieren oder Datensätze zu exportieren erfordert eine separate Berechtigungsentscheidung. Kits [Referenz der MCP-Tools](/docs/mcp-tools-reference) hilft bei der Auswahl von Integrationen. Dass eine Funktion über MCP verfügbar ist, begründet für sich genommen jedoch keine Erlaubnis für eine bestimmte Aktion.

### Kits Outreach-Adapter ist ein klar begrenztes Beispiel

Bei der statischen Codeprüfung für diesen Artikel fand sich eine relevante Implementierung in Kits Abrufadapter für **Outreach**. Das ist ein Beispiel aus der Kontaktrecherche. Es belegt weder eine ausgelieferte Funktion zum Abrufen von Portfolios in Hiring noch einen durchgängigen Sicherheitstest.

Der Adapter liest die gespeicherte Quell-URL eines Kontakts und prüft, ob sie eine sichere öffentliche URL ist. Er kann gespeicherte Profilfelder verwenden oder zunächst die Extraktion durch Cloudflare und anschließend Exa versuchen. Im regulären Ablauf über Cloudflare enthält das für das Modell sichtbare Ergebnis eine URL und extrahierten Text statt einer rohen HTTP-Antwort. Bei erfolgreichem Exa-Abruf werden URL, Titel, hervorgehobene Textstellen und Text zurückgegeben.

[Cloudflare beschreibt seinen Markdown-Endpunkt](https://developers.cloudflare.com/browser-run/quick-actions/markdown-endpoint/) als Verfahren zur Extraktion von Seiteninhalten. Diese Umwandlung belegt nicht, dass Inhalte zum Schutz vor Prompt Injection bereinigt werden. Der extrahierte Text bleibt Material Dritter. Die statische Prüfung ergab außerdem, dass die Fehlerbehandlung von Exa eine Ausnahmemeldung einschließen kann. Diese Ausgabe muss gesondert geprüft werden.

Aus diesen Beobachtungen ergibt sich ein konkreter nächster Prüfschritt: Zeichnen Sie die tatsächlichen Ergebnisse bei erfolgreichem Anbieterabruf, beim Ersatzverfahren, bei Weiterleitungen und bei Fehlern auf. Testen Sie anschließend die erlaubten Folgeaktionen. Die Beobachtungen beweisen weder, dass Header im gesamten System ausgeschlossen werden, noch dass Kit gegen Prompt Injection immun ist.

Machen Sie bei Ihrer eigenen Integration die Abrufspezifikation überprüfbar, bevor Sie die Befugnisse des Agenten erweitern. Legen Sie einen kleinen Satz synthetischer Testfälle beim Adapter ab, dokumentieren Sie, welche Inhalte das Modell erreichen, und prüfen Sie, wer die nächste Aktion autorisiert. So erhält Ihr Recruiting-Team nachvollziehbare Belege für den Fall, dass sich eine Quelle ändert, ein Anbieter ausfällt oder ein Assistent eine folgenreiche Aktion vorschlägt.