Una policy di pagamento porta da uno a due il numero di persone incaricate del controllo. Un agente recupera un riepilogo scritto prima della modifica. Il riepilogo può descrivere con precisione la vecchia policy. Se possa essere usato oggi in una decisione di pagamento dipende da quale policy è autorizzata e in vigore per questo cliente e per questa azione.
La memoria persistente trasforma questa distinzione in un problema di ingegneria. Le informazioni conservate possono servire alla spiegazione storica, alla pianificazione o all’esecuzione, e ciascuna finalità richiede una regola che stabilisca quali record si applicano. Questo articolo esamina ricerche recenti, riporta sette piccole verifiche su un filtro di memoria pubblicato e propone una scheda per l’applicabilità delle policy. Questo articolo fa parte di una serie di ricerca in tre parti sull’autorità degli agenti, pubblicata il 26 ottobre 2026: prove di arresto, policy nella memoria degli agenti e standard di controllo degli agenti.
Le ricerche recenti danno al problema una forma concreta
In Revoked but Still Authoritative, preprint di settembre 2026, Yi Ting Shen, Kentaroh Toyoda e Alex Leung studiano come le informazioni revocate riemergano nei flussi di lavoro basati sulla memoria degli agenti. Il paper copre diversi sistemi di memoria e metodi di inserimento, con esperimenti su write-back, archivi condivisi e uso di strumenti. Leggi il paper.
La configurazione incide sui risultati. Il paper distingue il recupero predefinito di Graphiti da una condizione di mem0 che scavalca il filtro di scadenza fornito con mem0. Altri sistemi si comportano in modo diverso a seconda di come un aggiornamento di policy entra in memoria e del fatto che lo stato di revoca raggiunga o meno il chiamante. Leggete i risultati dello studio tenendo conto di queste condizioni.
Gli autori pubblicano anche un filtro di recupero. Usa i metadati di revoca disponibili e un rilevamento euristico dei conflitti per decidere quali record escludere dalla selezione. Abbiamo esaminato l’implementazione e l’abbiamo eseguita in locale a un commit fissato. Il suo autotest integrato è stato superato. Gli abbiamo poi sottoposto sette piccoli casi sintetici, pensati per mostrare dove la selezione delle policy richiede più contesto. Filtro pubblicato.
Cosa hanno mostrato le sette verifiche
I primi tre casi corrispondono al comportamento documentato del filtro. Ha escluso dalla selezione un record revocato in modo esplicito. Tra due record in conflitto con data e ora ha preferito il più recente. Quando nessuno dei due aveva un timestamp utilizzabile, li ha conservati entrambi e ha segnalato un conflitto non risolto.
Gli altri quattro casi aggiungono contesto di cui una decisione di policy ha bisogno e che questo filtro non risolve:
| Attività sintetica | Selezione osservata | Contesto necessario al chiamante |
|---|---|---|
| Due policy si applicano a clienti diversi | La policy più recente resta in kept | Ambito del cliente, prima di confrontare le sostituzioni |
| Una nota più recente non approvata è in conflitto con una policy approvata | La nota più recente resta in kept | Quale fonte può autorizzare una modifica della policy |
| Un record più recente entra in vigore nel 2099 | La policy futura resta in kept | L’intervallo di efficacia alla data della decisione |
| Una domanda di audit richiede la policy precedente | La policy corrente resta in kept; quella precedente è in withheld | Un recupero storico adatto alla domanda |
Come leggere questi risultati
Si tratta di osservazioni deterministiche di una sola funzione di filtro. I campi cliente, autorità e data di efficacia vanno oltre le sue regole di selezione documentate, e la funzione non accetta alcun parametro per la finalità della query. I casi descrivono responsabilità dell’applicazione che integra il filtro. Non dimostrano una vulnerabilità del filtro o dei sistemi di memoria in generale, e sette casi scelti non dicono nulla sulla frequenza. Non è stato eseguito alcun modello, servizio di memoria o strumento di pagamento.
Il caso storico richiede attenzione. Il filtro mantiene il record escluso dalla selezione nel suo output, quindi un’applicazione può ancora leggerlo. La decisione di integrazione riguarda se una domanda di audit debba usare lo stesso contesto filtrato di una richiesta di eseguire la policy corrente.
Rendete esplicita l’applicabilità
Il modello che proponiamo parte dall’attività. Una domanda sull’approvazione del mese scorso può richiedere una policy sostituita. Una richiesta di esecuzione di un pagamento richiede la policy in vigore ora per quell’azione. Mantenere esplicita la finalità consente a un sistema di conservare uno storico utile e di selezionare comunque il contesto giusto per l’esecuzione.
Il passo successivo è chiarire l’ambito e la fonte dell’autorità. Un record di policy dovrebbe identificare il cliente o il tenant, l’azione governata, l’emittente, lo stato di approvazione, l’intervallo di efficacia e ciò che sostituisce. Un timestamp più recente aiuta a ordinare i record una volta note queste relazioni. Non può fornire un’approvazione che non è mai avvenuta.
Infine, il componente che può causare un’azione con effetti rilevanti dovrebbe valutare l’autorizzazione applicabile. Un riepilogo recuperato può riportare un identificatore di policy e spiegare un’azione proposta. La decisione di esecuzione dovrebbe essere legata a una versione ufficiale della policy e registrata con il suo esito. Si tratta di una raccomandazione di progettazione che non abbiamo sottoposto a benchmark.
- 1. Finalità: spiegazione storica, pianificazione o esecuzione.
- 2. Ambito: cliente o tenant, risorsa e azione governata.
- 3. Autorità e tempo: emittente, registrazione dell’approvazione, inizio e fine dell’efficacia, sostituzione.
- 4. Selezione: la policy applicabile ed eventuali eccezioni approvate.
- 5. Decisione: valutare l’azione proposta rispetto alla versione ufficiale e conservarne il riferimento.
Una scheda per l’applicabilità delle policy
Ricerche correlate trattano problemi vicini. MINJA studia come l’interazione possa contaminare la memoria di un agente, e VersionRAG esamina le domande su versioni di documenti che cambiano nel tempo. MINJA, VersionRAG.
Per il responsabile di una policy, un registro utile risponde a quattro domande: da dove proviene la policy, chi l’ha approvata, quando e dove si applica e quali decisioni vi hanno fatto affidamento. La scheda di applicabilità delle policy (in inglese) trasforma queste domande in campi che un team può verificare.
| Campo della decisione | Cosa registrare |
|---|---|
| Finalità dell’attività | Spiegazione storica, pianificazione o esecuzione; il momento della decisione ed eventuale data storica richiesta |
| Ambito | Cliente o tenant, risorsa e azione governata |
| Policy | Identificatore e versione |
| Autorità | Autorità emittente e registrazione dell’approvazione |
| Efficacia | Inizio e fine dell’efficacia; stato di ritiro o sostituzione; relazione di sostituzione esplicita |
| Eccezioni | Eccezione approvata, relativo ambito e scadenza |
| Fonti | Documenti di origine e riepiloghi derivati che vi fanno riferimento |
| Conflitti | Prove in conflitto e responsabile della policy |
| Esecuzione | Il controllo sulla versione ufficiale della policy e il suo esito registrato |
Dove KLA valuta le policy
In KLA, un’azione governata viene valutata dal KLA Policy Engine al momento dell’esecuzione, con uno di quattro esiti: allow, warn, require_approval o block. Quando la valutazione fallisce, il motore restituisce la sua decisione fail-closed, require_approval per impostazione predefinita, e il lint dei policy pack rifiuta una policy la cui decisione predefinita è fail-open. Il riepilogo di policy che un agente ricorda può contribuire a formulare la sua proposta. La decisione deriva dalla versione pubblicata della policy.
Le verifiche di questo articolo sono state eseguite solo sul filtro pubblicato. Non contengono alcun risultato di KLA.
Domande frequenti
Perché gli agenti AI usano policy superate presenti in memoria?
Un archivio di memoria può contenere un riepilogo scritto prima della modifica di una policy. Il recupero può classificarlo in alto, e un record più recente può riguardare un altro cliente, non essere approvato o non essere ancora in vigore. Se l’applicazione non chiarisce l’ambito, l’autorità e le date di efficacia, l’agente può agire in base a una policy che non si applica più.
Un timestamp più recente indica che un record di policy è quello corrente?
No. Un timestamp ordina i record una volta che si sa che coprono lo stesso ambito e che il più recente è stato approvato ed è in vigore. Nelle nostre verifiche, un filtro pubblicato ha mantenuto una nota più recente non approvata e una policy datata 2099, perché il suo contratto non copre l’approvazione né gli intervalli di efficacia.
Un agente dovrebbe cancellare dalla memoria le policy sostituite?
Conservatele per lo storico e instradatele in base alla finalità. Una domanda di audit può richiedere la policy precedente; una richiesta di esecuzione richiede quella in vigore. Per questo motivo il filtro che abbiamo testato mantiene i record esclusi dalla selezione nel suo output.
Dove dovrebbe avvenire il controllo finale della policy?
Nel componente che può causare l’azione con effetti rilevanti, rispetto a una versione ufficiale della policy, registrando versione ed esito. La memoria può spiegare una proposta. Il controllo di policy decide se l’azione viene eseguita.
Punti chiave
Una policy ricordata è un contesto utile e un’autorità inaffidabile. Stabilite la finalità di ogni recupero, chiarite l’ambito, lo stato di approvazione e le date di efficacia prima di fidarvi della data più recente ed eseguite il controllo di esecuzione sulla versione ufficiale. Usate la scheda di applicabilità delle policy per registrare queste decisioni.
Le fonti sono state verificate il 26 ottobre 2026. Tutti e sette i casi sono sintetici, sono stati eseguiti su una sola funzione pubblicata e non misurano nulla dei sistemi in esercizio.