Il percorso di produzione applica una guardia deterministica subito prima di invocare un executor. La guardia blocca classi chiuse di accessi e comandi pericolosi. Il modulo espone anche un giudice graduato, ma questa seconda fase non fa parte del percorso ordinario del motore corrente: documentare le due cose come se fossero entrambe sempre attive sarebbe inesatto.
Il Vaglio controlla una singola azione già scelta dal motore. Non seleziona l'executor, non interpreta da solo la richiesta, non concede permessi e non sostituisce la policy, il consenso umano, la sandbox o i controlli dell'executor.
La separazione principale è fra:
La funzione judge(intent, executor_name, args, context) restituisce
un Verdict con questi campi:
| Campo | Significato |
|---|---|
approved | Indica se l'azione supera l'intera chiamata. |
reason | Motivo leggibile prodotto dalla guardia o dal giudice. |
ts | Istante Unix della decisione. |
judge_kind | rule-based-v1,
llm-v1 oppure safe-verb-shortcut. |
score | Punteggio fra 0 e 1; vale 0 per un blocco della guardia. |
blocked_by | guard, judge o
nessun valore quando la chiamata approva. |
Questo contratto descrive l'API completa del modulo. Non implica che ogni call site usi entrambe le fasi.
guard_check(executor_name, args, context) esamina ricorsivamente gli
argomenti che possono rappresentare un bersaglio d'accesso. Le stringhe poste in
campi di contenuto, come corpo, testo, commento o messaggio, non vengono trattate
come percorsi: citare un percorso protetto in un documento non equivale ad
accedervi.
La guardia applica tre famiglie di controlli:
~/.ssh, credenziali cloud, /etc/passwd,
/etc/shadow, /root, /boot e dispositivi a
blocchi.La prima violazione restituisce (False, motivo). In assenza di
corrispondenze la guardia restituisce (True, None); non certifica per
questo che l'azione sia innocua in ogni suo possibile effetto.
Se un chiamante usa judge(), la guardia viene eseguita per prima.
Dopo il suo esito positivo, i verbi presenti nel vocabolario
SAFE_VERBS seguono uno short circuit e ricevono un verdetto approvato
con judge_kind=safe-verb-shortcut.
Per gli altri verbi, il backend predefinito rule-based-v1 parte da
un punteggio base, aggiunge segnali di corrispondenza fra intento ed executor e
riduce il valore per indicatori come path traversal o nomi di argomento anomali.
Il confronto finale usa METNOS_JUDGE_THRESHOLD, il cui valore
predefinito è 0.30.
Questo punteggio è un'euristica locale. Non dimostra l'allineamento ai fini dell'utente e non deve essere descritto come una verifica semantica generale.
Impostando METNOS_JUDGE_KIND=llm-v1, un chiamante di
judge() usa il ruolo LLM middle. Il prompt segue la lingua
del turno e riceve l'intento, il nome dell'executor, le sole chiavi degli argomenti
e alcuni campi di contesto; i valori degli argomenti non vengono inviati.
Se router, chiamata o parsing falliscono, il modulo restituisce un punteggio di
ripiego pari a 0.5. Con la soglia predefinita questo degrado tende ad
approvare. È quindi un comportamento di disponibilità esplicito, non un fail
closed e non una garanzia di sicurezza.
judge() scrive record JSONL mensili nella directory utente
vaglio/. Il record include verdetto, intento, executor, nomi delle
chiavi degli argomenti e nomi delle chiavi di contesto; non include i valori degli
argomenti. Un errore di scrittura del log non modifica il verdetto.
Il log rende ispezionabile una decisione prodotta dall'API. Non ricostruisce da solo l'intero turno e non trasforma il motivo di un modello in una prova.
Il motore condiviso riceve guard_check come
vaglio_guard. La invoca immediatamente prima dell'executor e anche nel
preflight delle ondate parallele. Un blocco produce un risultato con classe
vaglio_guard e interrompe il piano prima dell'effetto.
Il motore dispone di un hook separato per un giudice, ma il dispatcher corrente
non gli passa judge(). Pertanto, nel percorso ordinario:
| Componente | Stato nel percorso di produzione |
|---|---|
| Guardia deterministica pre-esecuzione | Collegata e attiva. |
| Giudice graduato rule-based o LLM | Disponibile come API, non collegato al dispatcher ordinario. |
| Policy e approvazione umana | Flussi separati, applicati dove previsto dal contratto della capability. |
| Controllo cross-user del modulo | Helper disponibile; non è la prova che ogni invio lo richiami. |
Chiedi a Metnos con una richiesta come quella di questo esempio:
«Leggi /etc/hosts e mostrami le righe non commentate.»
La lettura di un file di configurazione non viene confusa con una modifica
dell'albero di sistema. Se invece chiedi «Sostituisci
/etc/hosts con questo contenuto», la guardia riconosce il verbo
mutante e il percorso protetto e ferma il passo prima dell'invocazione.
La risposta visibile deve descrivere l'operazione bloccata e il motivo utile all'utente nella lingua del turno. Il testo interno della guardia resta un dato tecnico e non autorizza il renderer a inventare eccezioni.
| Impostazione | Valore predefinito | Effetto |
|---|---|---|
METNOS_JUDGE_KIND | rule-based-v1 | Backend usato dai chiamanti di judge(). |
METNOS_JUDGE_THRESHOLD | 0.30 | Soglia del giudice graduato. |
runtime/vaglio.py: guardia, giudici, verdetto e log.runtime/platform_policy.py: alberi protetti per piattaforma.runtime/engine/executor.py: guardia pre-invocazione.runtime/agent_runtime.py: collegamento del dispatcher corrente.