Onyx runtime-bescherming nu op de TrueFoundry AI Gateway: policy guardrails voor elke LLM-call
.png)
Gebouwd voor snelheid: ~10ms latentie, zelfs onder belasting
De razendsnelle manier om je modellen te bouwen, volgen en implementeren!
- Verwerkt 350+ RPS op slechts 1 vCPU — geen tuning nodig
- Productieklaar met volledige enterprise-ondersteuning
Als uw team LLM-verkeer via een AI gateway leidt, is elke prompt en elke response een punt waar iets mis kan gaan. De TrueFoundry AI Gateway biedt u uniforme toegang tot meer dan 1.000 LLMs achter één enkele OpenAI-compatibele API. Onyx is nu beschikbaar als custom guardrail op die gateway, zodat klanten van TrueFoundry runtime-bescherming kunnen toevoegen zonder applicatiecode te wijzigen.
Runtime-bescherming hoort thuis op het handhavingspunt, niet in elke losse applicatie. Onyx voert dezelfde controles uit op elke prompt en response die die grens overschrijdt. De applicaties van uw organisatie krijgen Onyx's prompt-injection-defensie, jailbreak-detectie, data-exfiltratie-controles en content policies geëvalueerd voordat het model of de gebruiker de output überhaupt ziet.
De instelling bestaat alleen uit configuratie. Er hoeft geen wrapper te worden gedeployed en er hoeft geen applicatiecode te worden gewijzigd.
Vereisten
- Een TrueFoundry AI Gateway waarop ten minste één model provider is gecultureerd die verdict: false bij HTTP 200 honoreert.
- Een Onyx AI Guard-policy en de bijbehorende Guard Token, met ten minste één Block-regel die de Input- en/of Output-richting scant die u wilt handhaven.
- Outbound HTTPS vanaf uw TrueFoundry gateway naar uw Onyx tenant host.
- Machtigingen om guardrail-groepen toe te voegen en te koppelen in het TrueFoundry-dashboard.
Stapsgewijze integratie
Onyx biedt een TrueFoundry-native evaluate-endpoint dat direct spreekt met het custom-guardrail-contract van de gateway. TrueFoundry roept Onyx aan, Onyx retourneert een verdict. Er zit geen wrapper of adapter tussenin.
Stap 1: Haal uw Guard Token op en bouw de URL
De Guard Token in de URL van uw AI Guard-policy identificeert welke policy moet worden geëvalueerd, en dient als auth voor de call. Het is geen API key of MCP Gateway Token. Ga in Onyx naar Policies, vervolgens naar Runtime Policies en dan naar het tabblad AI Guard. Open de AI Guard-URL van de policy en kopieer de Guard Token en uw tenant-hostname.
Bouw de guardrail-URL:
https://<routing-id>.ai-guard.onyx.security/guard/evaluate/v1/<guard-token>/truefoundry
Gebruik uw eigen tenant host. De kale https://ai-guard.onyx.security leidt niet naar een tenant en retourneert een 404.
Stap 2: Registreer de custom guardrail-configuraties
Ga in het TrueFoundry-dashboard naar AI Gateway, vervolgens naar Guardrails en dan naar New Guardrails Group. Kies Custom en noem deze onyx-security. Voeg twee configuraties toe, één per richting, die beide naar dezelfde Onyx-URL wijzen.
Stel voor de input-configuratie de naam in op onyx-input, de operation op Validate en de target op Request. Plak de guardrail-URL die u in Stap 1 hebt gebouwd, laat Auth Data op None staan, stel Config in op {} en kies Enforce But Ignore On Error als enforcing strategy.
Stel voor de output-configuratie de naam in op onyx-output, de operation op Validate en de target op Response. Gebruik dezelfde guardrail-URL, laat Auth Data op None staan, stel Config in op {} en kies Enforce But Ignore On Error als enforcing strategy.
De enige verschillen tussen de twee configuraties zijn de naam en de target. Laat Auth Data leeg. De Guard Token in het URL-pad is de auth, dus er is geen Bearer-token vereist.
Stap 3: Koppel de guardrail aan het verkeer
Koppel de groep aan een model in de guardrail-instellingen van het model, pas deze toe over de gehele gateway via Policies en vervolgens Guardrails, of selecteer deze per request met een header zodat u kunt testen zonder een model te wijzigen:
{
"llm_input_guardrails": ["onyx-security/onyx-input"],
"llm_output_guardrails": ["onyx-security/onyx-output"]
}
Stuur een valide prompt en deze wordt doorgestuurd naar het model. Stuur een prompt die een Onyx-regel activeert en de gateway blokkeert deze, waarbij het bericht van de policy wordt geretourneerd in plaats van een antwoord van het model, als HTTP 400 met error.type: guardrail_checks_failed. Stel voor response-beveiliging "stream": false in; output-rails worden niet uitgevoerd op gestreamde responses.
Wat u hiermee ontgrendelt
Input- en output-validatie. De input-rail controleert prompts voordat het model draait. De output-rail controleert responses voordat ze de gebruiker bereiken, bij niet-gestreamde requests. Onyx evalueert elke request tegen de regels voor de Input-richting en Output-richting van uw policy.
Policy-gestuurde blokkering. Blokkades bevatten het bericht dat u in Onyx hebt geconfigureerd, zodat de aanroeper uw formulering ziet en geen generieke foutmelding. U wijzigt de handhaving door de policy aan te passen in de Onyx-console, zonder wijzigingen aan de TrueFoundry-zijde.
Eén policy voor elke applicatie. Omdat de controle op het niveau van de gateway plaatsvindt, erft elk team en elke app die hier doorheen stuurt dezelfde guardrails. Er is geen integratie per applicatie te onderhouden en er is geen gat in de dekking wanneer een nieuwe dienst wordt gelanceerd.
Observability op dezelfde plek. Guardrail-beslissingen worden getracet samen met de rest van het request. De gateway is OpenTelemetry-compliant, zodat u kunt zien welke requests zijn geblokkeerd en waarom, binnen dezelfde stack die u al gebruikt voor latency en kosten.
FAQ
Wat zijn LLM guardrails op een AI gateway?
Guardrails zijn controles die de gateway uitvoert op prompts en responses voordat ze het model of de gebruiker bereiken. Op de TrueFoundry AI Gateway draaien ze als configureerbare policies, zodat u prompt-injection, jailbreaks of datalekkage centraal kunt blokkeren in plaats van in elke losse applicatie.
Moet ik iets deployen om de Onyx-guardrail toe te voegen?
Nee. TrueFoundry roept het Onyx evaluate-endpoint rechtstreeks aan. U registreert twee guardrail-configuraties die naar uw Onyx-URL wijzen. Er hoeft geen wrapper of adapter te worden gehost.
Draait de Onyx-guardrail op zowel prompts als responses?
Ja. De integratie registreert twee rails, één op de request en één op de response. Of een zin bij output wordt geblokkeerd, hangt af van het feit of uw Onyx-policy een regel voor de Output-richting heeft; Input en Output worden afzonderlijk geconfigureerd in Onyx, en output-beveiliging vereist niet-gestreamde requests.
Moet ik mijn applicatiecode wijzigen om guardrails toe te voegen?
Nee. De guardrail draait op het niveau van de gateway. U koppelt deze aan een model of geeft een header mee met het request, en uw applicatiecode blijft gewoon werken.
Waarom retourneert mijn request een validatiefout?
Het /truefoundry-endpoint vereist context.user.subjectSlug op het request. De gateway levert dit bij normaal verkeer; als u het endpoint rechtstreeks aanroept om te testen, voeg dan subjectSlug toe, anders retourneert Onyx een blokkeerverdict met "could not validate the request."
Kan ik de TrueFoundry AI Gateway in mijn eigen VPC draaien?
Ja. TrueFoundry ondersteunt VPC-deployment, on-prem, air-gapped en multi-cloud setups, waarbij geen gegevens uw domein verlaten.
Integreert het met mijn bestaande observability-stack?
Ja. De gateway is OpenTelemetry-compliant en sluit naadloos aan op Grafana, Datadog of Prometheus, waarbij elk request wordt getracet van prompt tot model, inclusief de guardrail-beslissingen.
Onyx en TrueFoundry hebben samengewerkt aan deze integratie. Neem contact op met uw vertegenwoordiger van TrueFoundry of Onyx om aan de slag te gaan.
TrueFoundry AI Gateway levert een latentie van ~3–4 ms, verwerkt 350+ RPS op 1 vCPU, schaalt moeiteloos horizontaal en is klaar voor productie, terwijl LiteLLM last heeft van hoge latentie, moeite heeft boven een gemiddeld aantal RPS, geen ingebouwde schaling heeft en het meest geschikt is voor lichte workloads of prototypes.















.png)

.webp)



.webp)








.webp)





