Moduli del prodotto

Policy Builder

Crea, simula, rivedi, pubblica e annulla le policy che governano le azioni di Agent e Process.

2 min di lettura519 parole

Policy Builder è lo spazio di lavoro per il ciclo di vita delle policy in /policy-studio. La route principale e il builder conversazionale richiedono policy:read. Le operazioni dirette in /policy-studio/operations richiedono policy:publish.

Cosa gestisce

  • Catalogo delle policy, ambito, versioni, regole e reason code.
  • Creazione guidata e avanzata delle regole.
  • Simulation rispetto al contesto di Decision Request fornito.
  • Invio alla revisione, approvazione, pubblicazione, integrità del pack compilato e rollback.
  • Binding tra policy e Agent e tra policy e ambiente.
  • Esportazione dell'evidenza per una versione esatta della policy tramite l'Evidence Factory condivisa. Il manifest restituito viene controllato rispetto a quello snapshot della policy prima del download.

Le schede del dettaglio della policy sono Overview, Scope, Rules, Diff, Simulate, Signature e Versions.

Ciclo di vita della sessione del builder

L'apertura di /policy-studio/builder è in sola lettura. Policy Builder crea una sessione quando un autore invia il primo messaggio o seleziona Start draft. Le prime azioni concorrenti riutilizzano la stessa sessione vuota aperta per quel tenant e autore. Le sessioni vuote non contengono messaggi, stato della policy, profilo selezionato, risultato del controllo della policy, utilizzo di token o turni completati. L'elenco delle sessioni rimuove le sessioni vuote dopo 24 ore. L'elenco esegue questa pulizia, quindi eseguirla più volte è sicuro.

I policy pack pubblicati sono versionati e firmati. Le decisioni runtime portano identificatore e versione della policy in Decision Desk, Lineage Explorer, Audit Trail ed Evidence Room.

Handoff agli amministratori

Policy Builder prepara un handoff per un amministratore di piattaforma quando una sessione conversazionale assegna a un amministratore del tenant attività di connessione, autorizzazione, configurazione o convalida runtime. La sessione di origine registra l'handoff consegnato e crea un link alla relativa route di dettaglio in /policy-studio/admin-handoffs/[sessionId]/[handoffId]. La inbox in /policy-studio/admin-handoffs elenca gli handoff consegnati per il tenant.

La vista di dettaglio presenta mappature dei passaggi di business, operazioni, autorizzazioni richieste e nomi dei campi delle credenziali, campi di configurazione, passaggi di convalida, decisioni irrisolte e fonti. Un amministratore del tenant autorizzato può proseguire il lavoro di connessione in Tool Catalog nella scheda Connections con la revisione del bundle di origine, sessione, handoff, connettore e contesto dei requisiti.

I dati della inbox richiedono tenant_admin o super_admin e policy_builder_session:read. I dati del dettaglio richiedono policy_builder_session:read e sono disponibili al proprietario della sessione di origine, a tenant_admin o a super_admin. Il perimetro tenant si applica a entrambe le API dati e gli errori di autorizzazione non rivelano dati dell'handoff.

Ciclo di vita della policy

flowchart LR
  D["Bozza"] --> S["Simulation"]
  S --> R["Revisione"]
  R --> P["Pubblica pack firmato"]
  P --> E["Valutazione runtime"]
  E --> O["allow / warn / require approval / block"]
  P --> B["Rollback"]

Le bozze bloccate restano nel catalogo delle policy e sono raggiungibili tramite un filtro che mostra ogni blocco di remediation. I link salvati alla route dismessa di remediation delle policy reindirizzano in modo permanente al catalogo nella scheda delle regole con quel filtro applicato. Un link con identificatore e versione della policy apre quella bozza.

La convalida e l'autorizzazione lato server restano autorevoli per revisione, pubblicazione e rollback.

Policy Builder | Developer Docs | KLA Control Plane