Runtime Safety

Delega Sicura a Runtime Pesanti

Un agente leggero non dovrebbe diventare sempre un runtime completo. I sistemi migliori fanno escalation in modo deliberato, con limiti chiari su costi, permessi e scope.

I sistemi agentici moderni combinano sempre più spesso un agente leggero con pochi tool e un runtime più pesante che può navigare, usare shell, leggere file o operare in modo più autonomo. La domanda di design non è solo se il sistema può delegare, ma quando la delega e giustificata, come viene delimitata e come può essere revisionata dopo.

Fatti chiave

Livelli permessi: Read-only, bounded action, high-risk, human-approved
Tema escalation: Quando delegare a runtime più pesanti
Controlli operativi: Budget, turn cap, approvazioni, rollback
Failure comune: Overreach silenzioso tramite tool o subprocess
Osservabilita: Trigger, tool, output, failure, alert

Come dovrebbero progettare configurazione base dell'agente e livelli di accesso ai tool?

Inizia separando identità stabile e istruzioni specifiche del task, poi aggancia il tier dei tool. Un pattern come `SOUL.md` più `TASK.md`, seguito da tool espliciti, limiti di turni, limiti di spesa e cronologia conversazionale, rende chiaro per chi il runtime sta agendo, quali regole valgono e quale autorità possiede davvero il run corrente. Da li in poi separa i tool da ispezione read-only ad azione limitata fino alle capacita high-risk come pagamenti, messaging, browser control, shell execution o mutazioni di sistema.

Come si collega questo a MCP e ai runtime più pesanti?

MCP e rilevante perché tool come web search, accesso database o task delegati possono essere esposti come tool, risorse e prompt MCP. Ma la configurazione in se e architettura runtime più ampia: identità, istruzioni del task, limiti di turni, limiti di spesa, caricamento della history, regole di escalation e confini di approvazione stanno sopra MCP. Passa a un runtime più pesante solo quando il task richiede davvero lavoro multi-file, accesso al terminale, browser control o ragionamento iterativo più profondo, e porta con te i limiti di budget, turni e approvazione nell'hand-off.

Trust

Torna ai principi di trust

La sicurezza runtime deve restare ancorata a ispezionabilita, blocker, approvazioni e hand-off espliciti.

Apri principi

Sequenza

Mappa la sicurezza runtime alla sequenza dei piani

I percorsi pubblico e protetto contano perché le capacita più rischiose non dovrebbero uscire prima che esistano proof e governance.

Apri prezzi

Progetta il contenimento del fallimento dentro il runtime

Un runtime agentico in produzione guadagna fiducia rendendo visibili autorità dei tool, percorsi di escalation, fallimenti ed esaurimento del budget prima che l'utente debba indovinare cosa sia successo.

Contratto di configurazione dell'agente

Tieni separata l'identità stabile dalle istruzioni del task e aggancia in modo esplicito tool, limiti e stato di sessione.

File di identità o soul descrivono per chi l'agente sta agendo

I file di task descrivono regole, obiettivo corrente e confini

Aggancia tool, max turni, spend cap e history come controlli runtime di primo livello

Livelli di permessi

Separa l'ispezione read-only dalle azioni limitate, poi separa i tool high-risk da quelli human-approved.

File, search e status possono spesso restare read-only

Browser actions, shell, pagamenti e messaging dovrebbero essere più strettamente tierizzati

Lo scope delle credenziali dovrebbe seguire il livello del tool, non l'intero runtime

Delega a runtime più pesanti

Escala verso runtime di coding o browser più pesanti solo quando la classe di task giustifica costo e rischio.

Aggancia spend cap e turn cap

Rendi ispezionabile il motivo dell'escalation

Fornisci rollback o stop path

Osservabilita e recovery

Persisti cosa ha innescato la run, quale contesto e stato caricato, quali tool sono partiti, quale output e stato prodotto e cosa ha fallito.

Rendi visibili i retry

Conserva audit trail tra queue e worker

Esponi kill switch prima che il fallimento diventi drift silenzioso

Continua nel ramo runtime

Questo ramo è pensato come libreria coerente. Usa le altre guide per completare il modello operativo oltre il singolo topic.

Layer esecutivi

Trigger vs Schedule vs Agenti Interattivi

Uno degli errori più comuni nei sistemi agentici e forzare ogni task dentro un'interfaccia conversazionale. Un approccio più affidabile separa tre layer: trigger per il lavoro guidato da eventi, schedule per il lavoro ricorrente in background e agenti interattivi per task dinamici che richiedono chiarimenti, giudizio o iterazione.

Context Hubs

Caricamento del Contesto a Livelli

Uno dei modi più rapidi per rendere un agente lento, costoso e meno affidabile e dargli troppo contesto troppo presto. Il caricamento a livelli trasforma la scoperta del contesto in un processo guidato, invece di lasciare il runtime davanti a un dump indistinto di file.

I runtime pesanti dovrebbero essere sempre disponibili?

No. Dovrebbero essere disponibili solo quando task, permessi e modello di review li giustificano.

Riguarda solo i coding agent?

No. Lo stesso pattern vale per browser automation, elaborazione file, workflow agent e assistenti operativi multi-tool.

Conta di più il modello o i guardrail runtime?

Per una delega sicura spesso contano di più i guardrail. Un modello forte con controlli runtime deboli resta rischioso.

Continua nel ramo runtime

Questo ramo è pensato come libreria coerente. Usa la landing runtime per ritrovare il quadro generale e continua verso i principi quando devi riallineare il modello operativo alla doctrine.

Torna alla landing Apri principi