Vai al contenuto principale
Se il tuo team di sicurezza chiede “come regge questo rispetto all’OWASP LLM Top 10?”, vuoi una risposta che punti a controlli in esecuzione, non una slide. OrcaRouter offre l’OWASP Top 10 for LLM Applications come un pack di compliance realmente installabile (owasp_llm) — non solo una vista checklist. Installarlo materializza le regole di guardrail e la policy di firewall su cui ogni rischio mappa, sullo stesso percorso che ogni richiesta a api.orcarouter.ai già attraversa, e snapshotta cosa è stato intercettato in un report firmato che puoi consegnare a un auditor. Questa pagina mappa ogni rischio OWASP LLM coperto sul controllo OrcaRouter che lo applica, mostra come installare il pack, e rimanda al riferimento approfondito per ciascun controllo. Per l’arco install-and-go-live attraverso tutti i framework, parti dalla Panoramica sulla compliance.

​
1. owasp llm top 10 mappata sui controlli OrcaRouter

Il pack owasp_llm è un mapping di controlli che si installa come policy reale — ogni voce qui sotto è un controllo che il gateway applica, non una descrizione di intenti. I rischi ad alto segnale mappano su guardrail live e una policy di firewall; un rischio (LLM05) è un controllo organizzativo senza superficie di applicazione nel gateway.
Un Guardrail sull’input della richiesta. Il pack combina il preset di sicurezza Prompt-Injection Basics (flagging a keyword) con una regola regex per il jailbreak (modalità DAN/STAN/AIM più smuggling di testo nascosto con tag-byte Unicode) per intercettare i tentativi di injection diretti e offuscati. Abbinalo a una regola llm_judge per l’intento di injection semantico. Vedi Prompt injection e Jailbreak.
Un Guardrail in fase di output che blocca le risposte del modello contenenti classici payload di SQL-injection (UNION SELECT, OR 1=1, DROP TABLE) prima che raggiungano un sistema a valle che potrebbe auto-eseguirli. Passa in rassegna i match nel feed di match dei Guardrails.
Un controllo organizzativo — l’assurance della supply chain per i tuoi modelli, dati e dipendenze è un processo che possiedi, non un controllo del gateway al momento della richiesta. Il pack lo porta come evidenza nel report così il tuo auditor lo vede contabilizzato. Per il lato runtime dei tool di terze parti, vedi Proteggere gli agent AI.
Due Guardrail: il Secrets & API-Key Blocker (rifiuta le richieste che portano credenziali AWS / OpenAI / GitHub) e un PII Blocker stretto (rifiuta le richieste che portano email, numeri di telefono, SSN, carte di credito o IP). Entrambi rifiutano in modo netto sulla richiesta prima che raggiunga il provider. Vedi le sezioni PII e segreti di Guardrails.
Un Guardrail in fase di output che blocca le risposte del modello che riecheggiano i token di controllo del chat-template (<|system|>, <|im_start|>) — chiara evidenza che il system prompt sta trapelando all’indietro. Regola la regola e passa in rassegna i suoi hit nel feed di match.
Una regola di policy del Firewall che nega le chiamate a tool pericolose di classe shell / exec — il controllo del piano delle azioni. È qui che il firewall, non un guardrail di contenuto, fa il lavoro: valuta le chiamate a tool che il tuo modello emette. Vedi Chiamate a tool pericolose e Eccessiva agency.
Il pack copre il sottoinsieme ad alto segnale dell’elenco OWASP che ha una superficie di applicazione concreta nel gateway — LLM01, LLM02, LLM06, LLM07, LLM08 come controlli applicati, più LLM05 come evidenza organizzativa. I rischi che vivono interamente nel codice della tua applicazione (furto del modello, poisoning dei dati di training) sono al di fuori del percorso del gateway e restano tuoi da affrontare — vedi Responsabilità condivisa.

​
2. Perché guardrail e firewall, non un unico controllo

L’elenco OWASP LLM abbraccia due piani diversi, e OrcaRouter divide i suoi controlli lungo la stessa linea:
PianoCopreControllo
ContenutiLLM01, LLM02, LLM06, LLM07Guardrails
AzioneLLM08Firewall
I guardrail filtrano il testo di prompt e risposta; il firewall valuta le chiamate a tool e le azioni in uscita. L’eccessiva agency (LLM08) è un problema di azione, quindi mappa su una regola di firewall — non un filtro di contenuto. Lo split è tutto il punto: leggi Guardrails vs Firewall per il perché un singolo controllo non può coprire entrambi.

​
3. Installa il pack

Sfogliare il catalogo e la readiness è gratis per qualsiasi Member del workspace. Installare il pack materializza i guardrail e la policy di firewall, ed è un’azione da Admin del workspace riservata a un piano a pagamento. Fallo dalla console — Compliance → Catalog → OWASP LLM Top-10 → Install.
Installa prima su un workspace non di produzione, o collega la policy di firewall materializzata in shadow_mode così i verdetti applicativi loggano come [shadow] would … anziché negare. Osserva gli eventi del firewall e il feed di match dei guardrail per una settimana, poi promuovi all’applicazione una volta che i match sembrano giusti.
L’installazione crea regole di guardrail reali e modificabili e una policy di firewall nel tuo workspace. Sono tue da regolare dopo — aggiusta l’elenco delle entità PII, scambia il deny di LLM08 con un verdetto audit mentre apprendi il comportamento dei tuoi agent, o aggiungi una regola di injection llm_judge sopra la base keyword/regex di LLM01. Collega il guardrail a una chiave tramite guardrail_id e la policy di firewall tramite firewall_policy_id, o imposta l’uno o l’altra come default del workspace.

​
4. Dimostralo con un report firmato

Una copertura che non puoi mostrare non è copertura. Dopo che il pack gira, genera un report di compliance — è firmato Ed25519 e marcato SHA256, esportabile come CSV / JSON / PDF, e verificabile pubblicamente senza un account OrcaRouter.

Genera un report firmato

Cosa snapshotta il report e come è firmato.

Verifica un report

Consegna a un auditor l’endpoint pubblico di verifica — nessun account necessario.
Il report elenca ogni controllo OWASP LLM, la regola che lo supporta, e i match che ha intercettato nella finestra di rendicontazione — così la risposta a “come regge questo rispetto alla owasp llm top 10?” è un artefatto firmato, non un’assicurazione verbale.

​
5. Dove andare dopo

Panoramica sulla compliance

L’intero arco install → enforce → report → go-live.

Cosa c'è in un pack

Come i controlli di un pack diventano guardrail e policy di firewall.

Tutti i framework

Gli altri pack AI, di sicurezza e di privacy nel catalogo.

Proteggere gli agent AI

Il baseline che irrigidisce gli agent contro questi rischi end to end.
La copertura OWASP LLM su OrcaRouter è policy in esecuzione, non una checklist: una sola installazione cabla i guardrail e le regole di firewall su cui ogni rischio mappa, e un solo report dimostra che si sono attivati.