Vai al contenuto principale
Hai letto una pagina sui controlli e ti resta una domanda prima di rilasciare. Queste sono le faq sulla sicurezza degli agent ai — le domande trasversali che attraversano l’intera sezione Zero-Trust, risposte in un unico posto, ciascuna che rimanda al riferimento per l’approfondimento. Se sei nuovissimo alla sezione, parti da Proteggere gli agent AI e il control stack; questa pagina assume che tu sappia che ci sono due piani di applicazione — Guardrails (testo di prompt/risposta) e il Firewall (azioni dell’agent) — e necessiti solo di inchiodare i dettagli.

​
1. faq sulla sicurezza degli agent ai — parti da qui

Una mappa di 30 secondi su quale controllo risponde a quale domanda:
Stai chiedendo di…Il pianoLeggi
Testo nei prompt o nelle risposte (PII, segreti, jailbreak)GuardrailsGuardrails
Chiamate a tool, MCP, egress, skillFirewallFirewall
Quale dei due è scattato su un 400EntrambiPerché è stato bloccato?
Ogni block di sicurezza sul gateway hosted è HTTP 400 con un code machine-readable. Leggi prima il codice — ti smista al feed giusto. La tabella completa vive in Codici di errore.

​
2. Guardrails — filtraggio dei contenuti

Niente. La risoluzione è: guardrail_id esplicito sulla chiave (se esiste ed è abilitato) → altrimenti il guardrail is_default del workspace → altrimenti nessuna applicazione. Un collegamento esplicito disabilitato è l’interruttore di spegnimento — non ricade sul default. Con nulla risolto, la richiesta è byte-identica a un workspace che non ha mai abilitato la feature.
No. Un’azione block restituisce 400 guardrail_blocked e non costa quota — un block in fase di input scatta prima del metering; un block in fase di output rimborsa la quota pre-consumata. È anche marcato skip-retry: ri-eseguire il prompt identico si limita a bloccarlo di nuovo.
Tipi di regola: keyword, regex, pii, max_chars, external, llm_judge, grounding. Azioni: block (rifiuta), mask (redige e inoltra), flag (solo log, nessuna modifica al traffico). Fasi: input, output, both. Vedi Guardrails per ciascuno.
Le entità integrate includono email, phone, credit_card, ssn, ip, iban, mac_address, jwt, aws_access_key, api_key_openai, bitcoin_address, più tipi regionali (jp_mynumber, kr_rrn, cn_resident_id). Un’azione mask rende un tag tipizzato — jane@acme.com → [EMAIL], un SSN → [SSN]. Puoi stratificare fino a 25 entità regex personalizzate per regola (con un checksum Luhn opzionale) e fare override dell’azione per entità tramite entity_actions.
Il block in output è applicato in entrambi i modi — le risposte non-streaming sono filtrate prima di tornare, e uno scanner di streaming taglia lo stream a metà. Il mask in output è attualmente solo non-streaming; su una risposta streaming il chunk passa non mascherato (la riscrittura in banda dello stream è nella roadmap). Il mascheramento in fase di input — sanificare la richiesta prima che il modello la veda — è attivo a prescindere. Il preset PII Shield maschera in fase di input oggi.
Le regole keyword / regex / pii / max_chars non fanno alcuna chiamata al modello e non fatturano nulla. Una regola llm_judge esegue un controllo semantico attraverso un modello del workspace (limitato da judge_timeout_ms, fail-open di default) ed è fatturata come una sotto-voce judge separata. Una regola grounding valuta la fedeltà della risposta rispetto alle fonti recuperate della richiesta (soglia default 0.7) allo stesso modo.
Apri il feed Matches (GET /api/guardrail/match, Member). Ogni riga registra il tipo di regola, l’azione, la fase e una stringa di dettaglio — e la sottostringa corrispondente solo se “Log raw content” è attivo per quel guardrail (disattivato di default, la postura conservativa sulla privacy). Block sbagliato? Marcalo come falso positivo (POST /api/guardrail/match/:id/mark-fp, Admin).
Un guardrail può decorare un prompt con un advisory di code-security (es. una nota CVE/SBOM su un package referenziato) senza bloccare o mascherare il testo. È un layer di annotazione che arricchisce la richiesta anziché rifiutarla — distinto dalle azioni block / mask / flag che crei direttamente. Connetti uno scanner sotto Integrations per pilotarlo.

​
3. Firewall — azioni dell’agent

Una differenza chiave: una policy del firewall collegata e disabilitata ricade sul default del workspace, mentre un guardrail collegato e disabilitato si risolve in nessuno. Per il resto entrambi si collegano tramite la chiave (firewall_policy_id / guardrail_id) e condividono il fallback sul default del workspace. Vedi Guardrails vs Firewall.
Verdetti: allow, audit, deny, sanitize, pending_approval, cap_cost. default_verdict è allow / audit / deny (audit di default). Superfici: inbound (tool pubblicizzati), response (tool_calls emessi dal modello), mcp (un tools/call), egress (host/IP/CIDR in uscita). Il glossario dei verdetti decodifica ciascuno.
No — e questo è il malinteso comune. Un verdetto sanitize redige le sottostringhe corrispondenti solo dagli argomenti della chiamata a tool, mai il contenuto che un tool restituisce. Sulla superficie inbound (nessun argomento ancora al momento della chiamata) sanitize escala a un deny.
Un unico interruttore imposta tutta la tua postura, scrivendo vere righe autonomy_* modificabili:
• balanced (inizio consigliato) — default audit, deny shell distruttiva, PII Shield in solo-audit (segnala i PII).
• tight — default-deny, deny shell distruttiva, deny dei tool di fetch in forma di SSRF, PII Shield + Secrets Blocker applicati.
• permissive — solo observe.
L’undo a un clic ripristina lo stato precedente dallo snapshot di audit che l’apply ha scritto. È un singolo step — l’undo non è disponibile una volta che un apply successivo (o una modifica manuale alla policy) ha soppiantato quello snapshot. Vedi Modalità di applicazione.
Non per preset. Il preset SSRF dell’autonomia tight nega i comuni nomi di tool in forma di fetch (http_fetch, web_search, fetch_url, request). Per negare per destinazione — range RFC-1918, IP di cloud-metadata, CIDR specifici — crea la tua regola di deny host/CIDR sulla superficie egress. Nessun preset fornisce regole CIDR per te. Vedi Egress ed esfiltrazione di dati.
Attiva la shadow mode (per-policy): la policy valuta e logga ma declassa ogni verdetto applicativo ad audit, prefissando la motivazione [shadow] would …. Osserva le viste Events e Runs, poi disattiva la shadow per applicare. La observe mode a livello di workspace (firewall_observe_mode) è il quadrante di scoperta complementare — logga le chiamate non coperte come gap in Discovered Tools.
Un verdetto pending_approval restituisce 400 firewall_approval_pending con un id di approvazione. Un revisore la risolve dalla console (Developer+) o tramite un callback webhook HMAC (POST /api/v1/firewall/approvals/:id/callback). L’agent fa polling su GET /api/v1/firewall/approvals/:id e ri-invia la chiamata originale con un header monouso X-OrcaRouter-Firewall-Approval. Vedi Chiamate a tool pericolose.
Picchi di rate/costo valutati rispetto a una baseline ora-della-settimana appresa (14 giorni), più retry_loop e novel_path (una transizione da tool a tool mai vista prima). Il feed è leggibile dai Member; metti in snooze un’anomalia per un massimo di 7 giorni. Vedi Eccessiva agency.

​
4. MCP, chiavi e accesso al gateway

Registra un server (name, endpoint, auth_mode di none/bearer/oauth/basic, credenziali cifrate) e il gateway MCP valuta ogni tools/call sulla superficie mcp prima del dispatch. La salute è tracciata (ok/degraded/down); fai il probe con POST /api/workspace/firewall/mcp_servers/:id/probe. Un probe fa anche da baseline allo schema dei tool pubblicizzato dal server — un drift successivo fa passare il suo schema status da verified a changed (il segnale “rug-pull”), e o ri-stabilisci la baseline (approvi) o metti in quarantine il server. Quindi la governance è valutazione per-chiamata più tracciamento dell’integrità dello schema e risk-band delle skill. Vedi Firewall MCP e Avvelenamento dei tool MCP.
Ogni skill viene scansionata in una risk band con una modalità di applicazione di allow / quarantine / block. Una skill in quarantena è messa in attesa di approvazione; le skill auto-rilevate restano in quarantena finché un umano non le revisiona. La modalità sta al di sopra del verdetto della regola.
model_limits (+ model_limits_enabled), allow_ips, credit_limit_usd (0 = illimitato), expired_time (-1 = mai), environment, guardrail_id, firewall_policy_id, e is_firewall_gateway. Combinali per la minima agency — vedi Scope, chiavi e policy. Le chiavi sono mascherate in visualizzazione.
Quelle rotte del gateway (POST /evaluate, POST /evaluate_plan, ANY /mcp) richiedono una chiave con is_firewall_gateway=true — un token dedicato con scope firewall-gateway, non la tua chiave di relay sk-orca-…. Coniarne uno e leggere il suo plaintext è Admin+.
La configurazione gira nella console — guardrail, policy del firewall, MCP server e compliance sono gestiti sotto il tuo session/access token (UserAuth), e ogni scrittura è role-gated (Developer+ per le scritture di policy e guardrail). Solo il tuo traffico di relay /v1/* usa una chiave sk-orca-…; solo gli hook del gateway /api/v1/firewall/* usano il token con scope firewall-gateway.

​
5. Compliance, residency e dati

Il catalogo include SOC 2, HIPAA, GDPR, UK GDPR, l’EU AI Act, ISO 27001, ISO 42001, il NIST AI RMF, PCI DSS, CCPA, GLBA, l’OWASP Top 10 for LLM Applications (come mappatura di controlli), più profili regionali (PIPL, APPI, PIPA, LGPD, PIPEDA, DPDP, gli APP australiani, il PDPA di Singapore, DORA e diverse leggi dei singoli stati USA). Sfoglia il catalogo, i pack e la readiness — tutto Member, gratuito — su /api/compliance/*.
Lo sfoglio è gratuito; installare un pack, generare un report, andare live e impostare la residency richiedono Admin del workspace e un piano a pagamento (gated lato server). Installare un pack (POST /api/compliance/packs/:key/install) materializza veri guardrail + policy del firewall che puoi poi modificare.
Sì. Un report è firmato Ed25519 + SHA-256 e verificabile pubblicamente: recupera la chiave pubblica (GET /api/public/compliance/pubkey), verifica un report (POST /api/public/compliance/verify), o consegna a un auditor un link di condivisione (GET /api/public/compliance/share/:token). Gli export sono CSV / JSON / PDF.
È la regione dell’artefatto del report di compliance (us, eu, uk, ap, cn, global), impostabile tramite PUT /api/compliance/residency (Admin); una lettura cross-region viene trattenuta. Non è il geo-pinning dei tuoi dati di inferenza. Vedi Responsabilità condivisa.
La retention dei log delle richieste è di default 30 giorni ed è clampata lato server a un massimo rigido di 180 giorni. Una cancellazione dell’account è trattenuta per una finestra di grazia (default 30 giorni) prima che giri uno scrub irreversibile dei PII; quello scrub elimina in cascata i payload Mongo dei log delle richieste, i match dei guardrail e gli eventi del firewall attribuiti a te. Archiviare un workspace elimina in cascata le stesse tre collection per quel workspace. Vedi Esposizione di PII.
Un 400 da un controllo di sicurezza non è un bug nel tuo prompt. È una policy che fa il suo lavoro. Non fare retry — questi codici sono skip-retry. Traccia la regola, poi decidi se correggere la chiamata o allentare la policy: Perché è stato bloccato?.

​
6. Ancora bloccato?

Codici di errore

Ogni block, hold e rifiuto che il gateway può restituire.

Perché è stato bloccato?

Leggi il codice, apri il feed giusto, trova la regola esatta.

API Guardrail

Rotte, ruoli e payload per le policy di contenuto.

API Firewall

Rotte di console e gateway per la governance delle azioni.

API Compliance

Endpoint di catalogo, install, report e residency.

Glossario

Ogni termine usato in tutti i docs Zero-Trust.
Per le minacce che questi controlli fermano, parti dal modello di threat. Per una baseline pulita, segui Baseline Secure Agents.