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 piu spesso un agente leggero con pochi tool e un runtime piu pesante che puo navigare, usare shell, leggere file o operare in modo piu autonomo. La domanda di design non e solo se il sistema puo delegare, ma quando la delega e giustificata, come viene delimitata e come puo essere revisionata dopo.

Fatti chiave

Livelli permessi: Read-only, bounded action, high-risk, human-approved
Tema escalation: Quando delegare a runtime piu 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 identita stabile e istruzioni specifiche del task, poi aggancia il tier dei tool. Un pattern come `SOUL.md` piu `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 autorita 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 piu pesanti?

MCP e rilevante perche 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 piu ampia: identita, 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 piu pesante solo quando il task richiede davvero lavoro multi-file, accesso al terminale, browser control o ragionamento iterativo piu 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 perche le capacita piu 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 autorita 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'identita stabile dalle istruzioni del task e aggancia in modo esplicito tool, limiti e stato di sessione.

File di identita 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 piu strettamente tierizzati

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

Delegazione a runtime piu pesanti

Escala verso runtime di coding o browser piu 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 e 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 piu comuni nei sistemi agentici e forzare ogni task dentro un'interfaccia conversazionale. Un approccio piu 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 piu 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 piu il modello o i guardrail runtime?

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

Continua nel ramo runtime

Questo ramo e 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 dottrina.

Torna alla landing Apri principi