Integration von Pillar Security mit TrueFoundry

‍Wir freuen uns, unsere Partnerschaft mit Pillar Security bekannt zu geben, die adaptive Laufzeitleitplanken direkt in den Pfad des KI-Agenten- und LLM-Verkehrs integriert.

Das Routing-Modell der Teams und der Agentenverkehr über das AI Gateway von TrueFoundry können Pillar Security nun als erstklassigen Anbieter von Leitplanken verbinden, um Aufforderungen und Antworten sowie Tool-Calls und MCP-Interaktionen in der Produktion in Echtzeit zu scannen und Richtlinien durchzusetzen. Die Integration läuft an den vier Leitplanken, die durch das Gateway zugänglich sind, und erfordert keine Änderungen am Agenten- oder Anwendungscode.

Dieser Beitrag behandelt die Architektur der Integration. Es wird erklärt, wie das TrueFoundry AI Gateway zur Laufzeit Guardrails ausführt und wie sich die Scanner-Pipeline von Pillar in dieses Ausführungsmodell einfügt und wie Teams Regeln konfigurieren, die auf bestimmte Modelle, MCP-Server und Benutzerpopulationen abzielen.

Warum unternehmensagentische KI zwei Ebenen benötigt

Wahre Gießerei bietet die Steuerungsebene für KI-Systeme in der Produktion. Über das AI Gateway zentralisieren Teams das Modellrouting und die Schlüsselverwaltung sowie die Zugriffskontrolle, Beobachtbarkeit und Steuerung für LLMs, Tools und MCP-verbundene Workflows. Jede Anfrage durchläuft eine einzige Proxy-Ebene, auf der die Identität verifiziert, Ratenbeschränkungen durchgesetzt und Traces erfasst werden.

Pillar Security stellt die Runtime-Sicherheitsebene bereit. Die Erkennungsmodelle scannen Eingabeaufforderungen und Antworten auf Jailbreak-Versuche und Prompt-Injection sowie PII- und PCI-Daten und -Geheimnisse sowie auf Angriffe mit toxischer Sprache und unsichtbaren Zeichen. Die adaptiven Leitplanken von Pillar basieren auf roten Teaming-Übungen, die gegen dieselbe Anwendung ausgeführt werden, und passen sich an den vom Agenten definierten Geschäftszweck an, um Fehlalarme zu reduzieren.

Zusammen bieten die beiden Lösungen den Teams eine saubere Produktionsarchitektur. TrueFoundry kümmert sich um die Bereitstellung und das Routing sowie die Betriebskontrolle. Pillar kümmert sich um die Laufzeitinspektion und Bedrohungserkennung sowie um die Durchsetzung von Richtlinien. Pillar Security wird als erstklassiger Guardrail-Anbieter innerhalb des TrueFoundry-Gateways mit Hooks unter unterstützt llm_input_guardrails und llm_output_guardrails und mcp_tool_pre_invoke_guardrails und mcp_tool_post_invoke_guardrails.

Die Lücke bei der Bereitstellung von Produktionsagenten

Die meisten Teams, die KI-Agenten aufbauen, konzentrieren sich darauf, den richtigen Einsatz und die Zuverlässigkeit zu gewährleisten. Der Agent muss die richtigen Tools aufrufen und den Kontext für lange Konversationen verwalten sowie Wiederholungsversuche und benutzerübergreifende Skalierung durchführen. Diese Arbeit ist notwendig, beantwortet aber nicht die Frage zur Runtime-Sicherheit.

Die Sicherheit vieler agentischer KI-Bereitstellungen endet am Perimeter. Plattformzugriffskontrollen und Zulassungslisten für MCP-Server sowie Berechtigungen auf Toolebene und bereichsspezifische Anmeldeinformationen für nachgelagerte Systeme sind vorhanden. Diese Kontrollen sind wichtig, aber sie lassen den Laufzeitpfad unkontrolliert.

Zu den Fragen, die der Perimeter nicht beantworten kann, gehört, was der Agent tatsächlich tut, sobald er mit der Ausführung beginnt, und welche Tools er in welcher Reihenfolge und mit welchen Daten aufruft. Wenn eine Eingabeaufforderung über einen abgerufenen Kontext, eine MCP-Serverantwort oder ein externes API-Ergebnis eingeht, hat der Perimeter keinen Einblick, ob der Agent im Begriff ist, darauf zu reagieren.

Laufzeitleitplanken auf dem Gateway-Pfad

Die architektonische Idee hinter dieser Integration ist direkt. Wenn der gesamte Modell-, Tool- und MCP-Verkehr bereits durch das Gateway fließt, ist das Gateway der richtige Ort, um Runtime-Sicherheit anzuwenden. Wenn Pillar mit dem TrueFoundry AI Gateway verbunden ist, können Teams Sicherheitsvorkehrungen auf demselben Pfad durchsetzen, auf dem der Agentenverkehr bereits weitergeleitet und gesteuert wird. Die Auswertung erfolgt anhand des Live-Traffics und nicht anhand der Traces, die nach der Ausführung überprüft werden.

Pillar Argus läuft als adaptiver Runtime-Layer. Pillar verwendet seine Scanner auf jede Interaktion in der Produktion, sodass Plattform- und Sicherheitsteams das Verhalten der Agenten überwachen, evaluieren und durchsetzen können, während es stattfindet. Die Scanner-Ausgaben enthalten eine Sitzungs-ID und einen markierten booleschen Wert sowie die Trigger pro Kategorie und ein Beweisarray mit dem fehlerhaften Text und seiner Position in der Eingabe.

Pillar macht zur Laufzeit die folgenden Erkennungskategorien verfügbar. Jailbreak-Erkennung identifiziert Versuche, das Sicherheitstraining des Modells zu umgehen. Sofortige Injektion Die Erkennung umfasst sowohl die direkte als auch die indirekte Injektion durch den abgerufenen Kontext oder die Werkzeugausgabe. PII- und PCI-Erkennung deckt über vierzig Kategorien von persönlichen Daten und Zahlungskartendaten ab und unterstützt die Maskierung, bevor die Daten das Modell erreichen. Geheime Erkennung identifiziert API-Schlüssel, Token und Anmeldeinformationen entweder in Eingabeaufforderungen oder in der Modellausgabe. Moderation von Inhalten und giftige Sprache Die Erkennung deckt unsichere und gegen Richtlinien verstoßende Inhalte ab. Unsichtbarer Charakter Die Erkennung fängt versteckte Unicode-Nutzdaten ab, die verwendet werden, um Anweisungen zu schmuggeln, die nicht von Menschen überprüft werden.

Für Agentensysteme wertet Pillar nicht nur ein einzelnes Prompt- und Response-Paar aus, sondern auch die Tool-Aufrufe und MCP-Anfragen sowie den mehrstufigen Ausführungskontext. Viele Fehler agentischer KI treten in der gesamten Aktionskette auf und nicht bei einem einzigen Modellaufruf.

Wie das Gateway Leitplanken ausführt

Das TrueFoundry AI Gateway läuft auf dem Hono-Framework und ein einzelner Gateway-Pod verarbeitet mehr als 250 Anfragen pro Sekunde auf 1 vCPU und 1 GB RAM mit ca. 3 ms zusätzlicher Latenz. Gateway-Pods sind zustandslos und CPU-gebunden und können über zusätzliche Pods horizontal auf Zehntausende von RPS skaliert werden. Die Steuerungsebene und die Gateway-Ebene sind aufgeteilt. Die Konfiguration, einschließlich Leitplankenregeln, Modelldefinitionen und Frequenzbegrenzungen, befindet sich in der Steuerungsebene und wird über NATS mit den Gateway-Pods synchronisiert. Der eigentliche Anforderungspfad bleibt im Speicher und es gibt keine externen Aufrufe außerhalb des LLM-Providers.

Guardrails werden an vier einzelnen Hooks im Anforderungslebenszyklus ausgeführt.

llm_input_guardrails fängt eine Eingabeaufforderung ab, bevor sie das Modell erreicht. Das Gateway sendet zuerst die eingegebene Nutzlast an Pillar. Wenn Pillar zurückkehrt markiert: wahr für jeden konfigurierten Scanner wird die Anfrage blockiert und das LLM wird nie aufgerufen. Der Input-Guardrail-Call wird gleichzeitig mit der Model-Anfrage ausgeführt, um die Zeit bis zum ersten Token zu optimieren. Der Model-Call wird bei einem Verstoß sofort storniert, um Anbieterkosten zu vermeiden.

llm_output_guardrails wird ausgelöst, nachdem das LLM geantwortet hat, aber bevor die Antwort an den Anrufer zurückgegeben wird. Die Ausgangsleitplanken sind sequentiell. Das Gateway wartet auf die Ausgabe des Modells und übermittelt es zum Scannen an Pillar, bevor es an den Kunden ausgeliefert wird. Dies ist der Durchsetzungspunkt für das Auffangen von PII, die Offenlegung geheimer Daten und die Entstehung toxischer Substanzen sowie alle unsicheren Inhalte, die das Modell produziert hat.

mcp_tool_pre_invoke_guardrails wird ausgelöst, bevor ein Tool vom Agenten ausgeführt wird. Pillar wertet den Toolnamen und die Argumente sowie den Aufrufkontext aus. Wenn die Argumente vertrauliche Daten enthalten oder auf einen Ressourcenzugriff außerhalb des Gültigkeitsbereichs hinweisen, wird der Aufruf des Tools blockiert, bevor eine reale Aktion ausgeführt wird.

mcp_tool_post_invoke_guardrails wird ausgelöst, nachdem das Tool sein Ergebnis zurückgegeben hat und bevor dieses Ergebnis an die Argumentationsschleife des Agenten zurückgegeben wird. Dies ist der Durchsetzungspunkt zur Erkennung indirekter Eingaben in die Tool-Ausgabe und zum Verlust von Anmeldeinformationen von MCP-Servern sowie von personenbezogenen Daten, die von Upstream-APIs zurückgegeben werden. Wenn Sie es hier unterbinden, wird verhindert, dass der Agent in einem vergifteten Kontext reagiert.

Jeder Hook unterstützt drei Durchsetzungsstrategien. Durchsetzen Sperren bei Verstoß oder bei einem Fehler bei der Leitplankenwartung. Erzwingen, aber bei Fehler ignorieren blockiert bei Verstößen, lässt aber die Anfrage weiterlaufen, wenn der Guardrail-Service selbst nicht erreichbar ist. Prüfung protokolliert das Urteil und sperrt niemals. Jede Leitplanke unterstützt auch zwei Betriebsmodi. Validieren Der Modus erzeugt eine Block- oder Passentscheidung. Mutieren Der Modus ermöglicht es dem Leitplankendienst, Inhalte während des Fluges zu ändern. So ist die Maskierungsfunktion von Pillar aktiviert. Der Maskenmodus wird auf der Pillar-Seite konfiguriert und zeigt redigierte Werte für übereinstimmende PII und Geheimnisse an, bevor die Aufforderung das Modell erreicht.

Die Integrationsfläche

Pillar ist in der TrueFoundry-Steuerebene als Leitplankenintegration mit zwei Eingaben konfiguriert. Der erste ist der API-Schlüssel, der von der Pillar-Konsole ausgegeben wird. Die zweite ist die Scannerkonfiguration, die auswählt, welche Erkennungskategorien für diese Integration verwendet werden sollen.

FeldValueProviderPillar SecurityEndpointhttps://api.pillar.security/api/v1/integrations/truefoundryAuthenticationBearer-Token über PILLAR_API_KEYScannerJailbreak und prompt_injection und pii und Geheimnis und toxische_Sprache und Inhaltsmoderation und unsichtbarer_CharakterBetriebsmodi: Validate- und MutateResponse-Format{session_id, markiert, Scanner, Beweise}

Sobald die Integration registriert ist, stellt das Gateway sie als Selektor zur Verfügung, auf den von jeder Gudrailregel aus verwiesen werden kann. Regeln werden über einen YAML-Regelblock konfiguriert. Jede Regel verwendet einen Wenn-Block mit zwei Bedingungen. Ziel Übereinstimmungen auf Model- oder MCPServern oder MCPTools oder Abfragen von Metadaten. Unterrichtsfächer entspricht der Benutzer- oder Teamidentität mit den Operatoren in und not_in. Die Regel legt dann fest, welche Guardrail-Integrationen auf welchem der vier Hooks ausgeführt werden sollen.

Eine Grundregel, die Pillar auf Eingabe und Ausgabe für ein OpenAI-Modell ausführt, das von allen Teams verwendet wird, sieht so aus.

Name: Leitplankenkontrolle
Typ: gateway-guardrails-config
Regeln:
- ID: Pillar-Baseline
wann:
ziel:
Operator: oder
Bedingungen:
modell:
Werte:
- openai-main/gpt-4o
Zustand: in
Fächer:
Operator: und
Bedingungen:
in:
- Team: jeder
llm_input_guardrails:
- Säulen-/Säulenstandardprofil
llm_output_guardrails:
- Säulen-/Säulenstandardprofil
mcp_tool_pre_invoke_guardrails: []
mcp_tool_post_invoke_guardrails: []


Eine zweite Regel, die Pillar-Scans um einen MCP-Server herum hinzufügt, der von einem Agententeam verwendet wird, würde den MCP-Server ins Visier nehmen und die Integration auf die Hooks vor und nach dem Tool-Aufruf anwenden. Alle passenden Regeln werden zusammen ausgewertet und ihre Leitplanken werden pro Hook vereint. Zwei Regeln, auf die beide abzielen llm_input_guardrails werden beide auf der Eingabe laufen.

Überschreibungen pro Anfrage werden unterstützt durch X-TFY-LEITPLANKEN Kopfzeile. Der Header enthält ein JSON-Objekt, das Guardrail-Selektoren für eine beliebige Kombination der vier Hooks angibt. Auf diese Weise können Anwendungsteams eine strengere oder freizügigere Richtlinie für einen bestimmten Aufruf festlegen, ohne die globale Konfiguration zu ändern.

Jede Guardrail-Entscheidung wird im Request-Trace erfasst. Die Spanne umfasst den ausgelösten Hook und den Integrationsselektor sowie das Urteil sowie die Latenz des Guardrail-Anrufs und die von Pillar zurückgegebenen Beweise. Traces werden asynchron über NATS ausgegeben und über OTEL in das Observability-Backend exportiert, das das Team konfiguriert hat. Das Dashboard von Pillar zeigt dieselben Ereignisse von seiner Seite aus und enthält vollständige Angriffsprotokolle und Aufschlüsselungen der Kategorien zur Überprüfung der Einhaltung der Vorschriften.

Zusammenfassung der Architektur

Der Anforderungsablauf von Ende zu Ende sieht so aus. Ein Client sendet einen Chat-Abschluss oder eine Agentenanfrage an das Gateway. Das Gateway authentifiziert den Anrufer anhand zwischengespeicherter IdP-Schlüssel und löst die Modell-ID durch Virtual Model-Routing auf. Passende Guardrail-Regeln werden im Speicher ausgewertet und die eingegebene Nutzlast wird gleichzeitig mit dem Modellaufruf an Pillar gesendet. Wenn Pillar die Eingabe markiert, wird der Modellaufruf abgebrochen und ein strukturierter Fehler zurückgegeben. Wenn die Eingabe fehlerfrei ist, wird die Antwort des Modells abgewartet und vor der Auslieferung an die Ausgangsscanner von Pillar übermittelt. Für den Agentenverkehr gilt dieselbe Logik für jeden Aufruf des MCP-Tools und für jede Tool-Antwort, bevor sie wieder in den Agentenkontext gelangt. Jeder Schritt wird in einer Trace-Spanne erfasst und mit dem Leitplanken-Urteil versehen.

An der Anwendung muss sich nichts weiter ändern. Es gibt kein SDK, das auf dem Client installiert werden muss, und es gibt kein Sidecar, das zusammen mit dem Agenten installiert werden muss, und keine Sicherheits-Middleware, die pro Dienst gewartet werden muss. Das Gateway befindet sich bereits im Anforderungspfad und Pillar stellt über seine API eine Verbindung zu diesem Pfad her. Der vorhandene OpenAI-kompatible Client-Code funktioniert ohne Änderung weiter.

Das architektonische Prinzip, das dies vereinfacht, ist die Konsolidierung der Durchsetzung von Richtlinien auf der Gateway-Ebene. Wenn der Modelldatenverkehr, der Tool-Traffic und der MCP-Verkehr alle auf einem einzigen Proxy zusammenlaufen, gelten die für diesen Proxy konfigurierten Leitplanken einheitlich für jedes Modell, jedes Team und jeden Agenten, ohne Code pro Anwendung. Die Scanner von Pillar laufen inline an derselben Stelle und das Hook-Modell des Gateways gibt Pillar Zugriff auf die vier Durchsetzungspunkte, an denen es auf Laufzeitentscheidungen tatsächlich ankommt.

Fangen Sie an

Erfahre mehr über die TrueFoundry KI-Gateway und die Pillar Security-Plattform. Verbinden Sie Pillar in der TrueFoundry-Guardrails-Konfiguration und verweisen Sie in jeder Regel, die auf Ihre Modelle oder MCP-Server abzielt, auf den Integrations-Selektor.