Pillar Security Integratie met TrueFoundry

‍Met trots kondigen we onze samenwerking aan met Pillar Security, die adaptieve runtime-guardrails rechtstreeks toevoegt aan het pad van AI-agent- en LLM-verkeer.

Teams die model- en agentverkeer via TrueFoundry's AI Gateway routeren, kunnen nu Pillar Security verbinden als een volwaardige guardrail-provider. Dit biedt realtime scanning en beleidshandhaving op prompts, responsen, tool calls en MCP-interacties in productie. De integratie draait op de vier guardrail-hooks die de gateway biedt en vereist geen enkele aanpassing in agent- of applicatiecode.

Dit artikel behandelt de architectuur van de integratie. Het legt uit hoe de TrueFoundry AI Gateway guardrails uitvoert tijdens runtime, hoe de scanner-pipeline van Pillar aansluit op dat uitvoeringsmodel en hoe teams regels configureren die gericht zijn op specifieke modellen, MCP-servers en gebruikersgroepen.

Waarom agentic AI in de enterprise twee lagen nodig heeft

TrueFoundry biedt de besturingslaag voor productie-AI-systemen. Via de AI Gateway centraliseren teams modelrouting, sleutelbeheer, toegangscontrole, observability en governance voor LLMs, tools en op MCP aangesloten workflows. Elk verzoek stroomt door één proxy-laag waar de identiteit wordt geverifieerd, rate limits worden gehandhaafd en traces worden vastgelegd.

Pillar Security biedt de runtime-beveiligingslaag. De detectiemodellen scannen prompts en responsen op pogingen tot jailbreaking, prompt injection, PII- en PCI-gegevens, secrets, toxische taal en aanvallen met onzichtbare tekens. De adaptieve guardrails van Pillar worden gevoed door red teaming-oefeningen die op dezelfde applicatie zijn uitgevoerd en stemmen zichzelf af op het gedefinieerde zakelijke doel van de agent om false positives te verminderen.

Samen bieden de twee oplossingen teams een strakke productiearchitectuur. TrueFoundry verzorgt deployment, routing en operationele controle. Pillar verzorgt runtime-inspectie, dreigingsdetectie en beleidshandhaving. Pillar Security wordt ondersteund als een volwaardige guardrail-provider binnen de TrueFoundry-gateway met hooks op llm_input_guardrails, llm_output_guardrails, mcp_tool_pre_invoke_guardrails en mcp_tool_post_invoke_guardrails.

Het gat in agent-deployments in productie

De meeste teams die AI-agents bouwen, richten zich op het goed regelen van deployment en betrouwbaarheid. De agent moet de juiste tools aanroepen, de context beheren over lange gesprekken, retries afhandelen en schalen over gebruikers. Dat werk is noodzakelijk, maar het geeft geen antwoord op het vraagstuk van runtime-beveiliging.

Beveiliging stopt bij veel agentic AI-deployments bij de perimeter. Platform-toegangscontroles, MCP-server-allowlists, permissies op toolniveau en gescopet credentials voor downstream-systemen zijn allemaal aanwezig. Die controles zijn belangrijk, maar ze laten het runtime-pad ongeïnspecteerd.

De vragen waar de perimeter geen antwoord op kan geven, zijn onder meer wat de agent daadwerkelijk doet zodra de uitvoering begint, welke tools hij aanroept, in welke volgorde en met welke data. Als er een prompt injection binnensluipt via opgehaalde context, een MCP-serverrespons of een extern API-resultaat, heeft de perimeter geen zicht op de vraag of de agent hierop zal reageren.

Runtime-guardrails op het gateway-pad

Het architectonische idee achter deze integratie is direct. Als al het model-, tool- en MCP-verkeer al door de gateway stroomt, dan is de gateway de juiste plek om runtime-beveiliging toe te passen. Met Pillar verbonden met de TrueFoundry AI Gateway kunnen teams guardrails handhaven op hetzelfde pad waar agentverkeer al wordt gerouteerd en beheerd. Evaluatie vindt plaats op live verkeer en niet op traces die pas na uitvoering worden beoordeeld.

Pillar's adaptieve runtime-guardrails draaien als de runtime-laag. Pillar past zijn scanners toe op elke interactie in productie, zodat platform- en beveiligingsteams het gedefinieerde beleid voor agentgedrag kunnen monitoren, evalueren en handhaven terwijl het plaatsvindt. De scanner-outputs bevatten een session identifier, een flagged boolean, de triggers per categorie en een evidence-array met de afwijkende tekst en de positie ervan in de invoer.

Pillar biedt de volgende detectiecategorieën tijdens runtime. Jailbreak detection identificeert pogingen om de veiligheidstraining van het model te omzeilen. Prompt injection detection omvat zowel directe als indirecte injectie via opgehaalde context of tool-output. PII and PCI detection omvat meer dan veertig categorieën van persoonlijke en betaalkaartgegevens en ondersteunt maskering voordat de data het model bereikt. Secret detection identificeert API-sleutels, tokens en credentials in prompts of model-output. Content moderation en toxic language detection dekken onveilige en beleidsschendende inhoud af. Invisible character detection detecteert verborgen unicode-payloads die worden gebruikt om instructies langs menselijke beoordeling te smokkelen.

Voor agentic systemen evalueert Pillar niet alleen een enkel prompt- en responspaar, maar ook de toolinvoerings, MCP-verzoeken en de meerstaps uitvoeringscontext. Veel agentic AI-fouten ontstaan over de gehele keten van acties en niet in één enkele modelaanroep.

Hoe de gateway guardrails uitvoert

De TrueFoundry AI Gateway draait op het Hono-framework en een enkele gateway-pod verwerkt meer dan 250 verzoeken per seconde op 1 vCPU en 1 GB RAM met ongeveer 3 ms aan toegevoegde latentie. Gateway-pods zijn stateless en CPU-gebonden en schalen horizontaal naar tientallen duizenden RPS via extra pods. Het control plane en gateway plane zijn gescheiden. Configuratie, inclusief guardrail-regels, modeldefinities en rate limits, bevindt zich in het control plane en synchroniseert naar gateway-pods via NATS. Het daadwerkelijke verzoekpad blijft in het geheugen zonder externe aanroepen buiten de LLM-provider.

Guardrails worden uitgevoerd op vier afzonderlijke hooks in de levenscyclus van een verzoek.

llm_input_guardrails onderschept een prompt voordat deze het model bereikt. De gateway stuurt de invoer-payload eerst naar Pillar. Als Pillar flagged: true retourneert voor een geconfigureerde scanner, wordt het verzoek geblokkeerd en wordt de LLM nooit aangeroepen. De input-guardrail-aanroep draait gelijktijdig met het modelverzoek om de time to first token te optimaliseren, en de modelaanroep wordt bij een schending onmiddellijk geannuleerd om providerkosten te vermijden.

llm_output_guardrails wordt geactiveerd nadat de LLM heeft geantwoord, maar voordat de respons wordt geretourneerd naar de aanroeper. Output-guardrails zijn sequentieel. De gateway wacht op de model-output en stuurt deze naar Pillar voor scanning voordat deze aan de client wordt geleverd. Dit is het handhavingspunt voor het opvangen van PII-lekken, het vrijkomen van secrets, toxische generatie en alle onveilige inhoud die het model heeft geproduceerd.

mcp_tool_pre_invoke_guardrails wordt geactiveerd voordat een tool door de agent wordt uitgevoerd. Pillar evalueert de toolnaam, de argumenten en de aanroepcontext. Als de argumenten gevoelige data bevatten of wijzen op toegang tot bronnen buiten de scope, wordt de toolinvoering geblokkeerd voordat er enige actie in de echte wereld plaatsvindt.

mcp_tool_post_invoke_guardrails wordt geactiveerd nadat de tool zijn resultaat heeft geretourneerd en voordat dat resultaat wordt teruggegeven aan de reasoning loop van de agent. Dit is het handhavingspunt voor het detecteren van indirecte prompt injection in tool-output, het lekken van credentials uit MCP-servers en PII geretourneerd door upstream API's. Door het hier te stoppen, wordt voorkomen dat de agent handelt op vervuilde context.

Elke hook ondersteunt drie handhavingsstrategieën. Enforce blokkeert bij een schending of bij een fout in de guardrail-dienst. Enforce But Ignore On Error blokkeert bij een schending, maar laat het verzoek doorgaan als de guardrail-dienst zelf onbereikbaar is. Audit legt het oordeel vast in de logs en blokkeert nooit. Elke guardrail ondersteunt ook twee operationele modi. De modus Validate leidt tot een besluit om te blokkeren of door te laten. Met de modus Mutate kan de guardrail-dienst inhoud in transit wijzigen, wat de manier is waarop Pillar's meermaskeringsfunctionaliteit is gekoppeld. De maskermodus wordt geconfigureerd aan de Pillar-zijde en toont geanonymiseerde waarden voor overeenkomende PII en secrets voordat de prompt het model bereikt.

Het integratie-oppervlak

Pillar wordt in het TrueFoundry control plane geconfigureerd als een guardrail-integratie met twee invoerelementen. Het eerste is de API key die is uitgegeven door de Pillar-console. Het tweede is de scannerconfiguratie die selecteert welke detectiecategorieën voor deze integratie moeten draaien.

Zodra de integratie is geregistreerd, biedt de gateway deze aan als een selector waarnaar vanuit elke guardrail-regel kan worden verwezen. Regels worden geconfigureerd via een YAML-regelblok. Elke regel gebruikt een when-blok met twee voorwaarden. target komt overeen met model, mcpServers, mcpTools of request metadata. subjects komt overeen met de identiteit van de gebruiker of het team via de operators in en not_in. De regel verklaart vervolgens welke guardrail-integraties moeten draaien op welk van de vier hooks.

Een basisregel die Pillar uitvoert op invoer en uitvoer voor een OpenAI-model dat door alle teams wordt gebruikt, ziet er zo uit:‍

name: guardrails-control
type: gateway-guardrails-config
rules:
  - id: pillar-baseline
    when:
      target:
        operator: or
        conditions:
          model:
            values:
              - openai-main/gpt-4o
            condition: in
      subjects:
        operator: and
        conditions:
          in:
            - team:everyone
    llm_input_guardrails:
      - pillar/pillar-default-profile
    llm_output_guardrails:
      - pillar/pillar-default-profile
    mcp_tool_pre_invoke_guardrails: []
    mcp_tool_post_invoke_guardrails: []

Een tweede regel die Pillar-scanning toevoegt rond een MCP-server die door een agent-team wordt gebruikt, zou gericht zijn op de MCP-server en de integratie toepassen op de pre- en post-tool invocation-hooks. Alle overeenkomende regels worden samen geëvalueerd en hun guardrail-sets worden per hook samengevoegd. Twee regels die beide gericht zijn op llm_input_guardrails zullen beide op de invoer worden uitgevoerd.

Overrides per verzoek worden ondersteund via de X-TFY-GUARDRAILS header. De header bevat een JSON-object dat guardrail-selectors specificeert voor elke combinatie van de vier hooks. Hiermee kunnen applicatieteams een strenger of versoepeld beleid instellen voor een specifieke aanroep zonder de globale configuratie te wijzigen.

Elk guardrail-besluit wordt vastgelegd in de request trace. De span bevat de hook die is geactiveerd, de integratieselector, het oordeel, de latentie van de guardrail-aanroep en de door Pillar geretourneerde evidence ter ondersteuning van threat hunting en beveiligingsonderzoeken. Traces worden asynchroon uitgezonden via NATS en geëxporteerd via OTEL naar de observability-backend die het team heeft geconfigureerd. Het dashboard van Pillar toont dezelfde gebeurtenissen vanaf zijn kant met volledige attack-transcripts en categorie-analyses voor compliance-beoordeling.

Overzicht van de architectuur

Van begin tot eind ziet de verzoekstroom er als volgt uit. Een client stuurt een chat completion of agent-verzoek naar de gateway. De gateway authenticeert de aanroeper op basis van gecachte IdP-sleutels en herleidt de model-identifier via Virtual Model routing. Overeenkomende guardrail-regels worden in het geheugen geëvalueerd en de invoer-payload wordt gelijktijdig met de modelaanroep naar Pillar verzonden. Als Pillar de invoer markeert, wordt de modelaanroep geannuleerd en wordt er een gestructureerde fout geretourneerd. Als de invoer schoon is, wordt gewacht op de modelrespons en wordt deze ingediend bij de output-scanners van Pillar voordat deze wordt afgeleverd. Voor agentverkeer geldt dezelfde logica bij elke MCP-toolinvoering en op elke toolrespons voordat deze opnieuw de agent-context binnenkomt. Elke stap wordt vastgelegd in een trace-span waaraan het guardrail-oordeel is gekoppeld.

Er hoeft verder niets te veranderen in de applicatie. Er is geen SDK die op de client moet worden geïnstalleerd, geen sidecar die naast de agent moet worden ingezet en geen beveiligings-middleware per dienst om te onderhouden. De gateway bevindt zich al in het verzoekpad en Pillar sluit via zijn API aan op dat pad. Bestaande clientcode die compatibel is met OpenAI blijft werken zonder aanpassingen.

Het architectonische principe dat dit overzichtelijk maakt, is de consolidatie van beleidshandhaving op de gateway-laag. Wanneer modelverkeer, toolverkeer en MCP-verkeer allemaal samenkomen op één enkele proxy, zijn de op die proxy geconfigureerde guardrails uniform van toepassing op elk model, elk team en elke agent, zonder code per applicatie. De scanners van Pillar draaien inline op hetzelfde punt en het hook-model van de gateway geeft Pillar toegang tot de vier handhavingspunten waar runtime-beslissingen er daadwerkelijk toe doen.

Aan de slag

Lees meer over de TrueFoundry AI Gateway en het Pillar Security-platform. Verbind Pillar in de guardrail-configuratie van TrueFoundry en verwijs naar de integratieselector vanuit elke regel die gericht is op uw modellen of MCP-servers.