Criteri di accesso agli strumenti in Azure agente SRE

I criteri di accesso agli strumenti consentono di controllare quali strumenti possono essere usati dall'agente. Si impostano regole come "nega tutti i comandi di eliminazione", "consenti il monitoraggio delle query senza approvazione" o "chiedi prima delle distribuzioni". Queste regole si applicano indipendentemente dalla modalità di aggiunta dello strumento all'agente.

Le policy operano insieme ad altri controlli, come le modalità di esecuzione, gli hook e la governance dei connettori. Se non si configurano criteri, l'agente usa le modalità di esecuzione e le impostazioni del connettore come impostazioni predefinite.

Tre ambiti per i criteri di accesso agli strumenti

Impostare i criteri a tre livelli.

Solo l'ambito globale può negare l'accesso agli strumenti. Gli ambiti dell'agente personalizzato e dei thread possono aggiungere solo regole di autorizzazione. Ampliano l'accesso all'interno dei confini globali, ma non possono mai indebolire una negazione globale.

Come vengono valutate le regole dei criteri di accesso agli strumenti

Quando l'agente chiama uno strumento, controlla le regole in questo ordine:

1. Negare (solo globale): se corrisponde, lo strumento viene bloccato.
2. Consentire (qualsiasi ambito): se corrisponde, lo strumento viene eseguito immediatamente, anche in modalità revisione.
3. Ask (solo globale): se corrisponde, l'agente sospende l'approvazione in modalità di revisione o approva automaticamente in modalità autonoma.
4. Nessuna corrispondenza: nessun criterio si applica, il comportamento predefinito diventa effettivo.

Le regole si basano su schemi glob per i nomi degli strumenti. I modelli supportano * come carattere jolly. Per gli strumenti che eseguono comandi (interfaccia della riga di comando di Azure, kubectl, bash, Python), usare la sintassi toolGlob(argGlob) per far corrispondere gli argomenti:

Il nome dello strumento nel modello deve corrispondere al nome dello strumento di runtime. Gli alias bash, shell e execute_bash si espandono per corrispondere a tutti gli strumenti da riga di comando (interfaccia della riga di comando di Azure, kubectl, comandi della shell), ma non agli strumenti Python o PDF. Usare ExecutePythonCode direttamente per i modelli di Python.

Nomi degli strumenti di runtime che supportano i modelli di argomento:

Funzionamento dei criteri con altri controlli

L'agente dispone di diversi controlli che determinano se una chiamata dello strumento procede. Vengono valutati in ordine di priorità:

Cosa accade in ogni scenario

Nessuna policy = nessun hook configurato oppure gli hook non si sono espressi su questo strumento. Nessuna corrispondenza = nessuna regola dei criteri di accesso corrispondente a questo strumento. Non esistono regole o i modelli non lo coprono.

Scegliere il controllo corretto per lo scenario

Configurare i criteri di accesso agli strumenti

Criteri globali

Impostato tramite Impostazioni > Autorizzazioni > nel portale o tramite l'API:

curl -X PUT "https://<agent>/api/v2/agent/settings/global" \
  -H "Content-Type: application/json" \
  -d '{
    "permissions": {
      "allow": ["RunAzCliReadCommands", "RunKubectlReadCommand(kubectl get *)"],
      "ask": ["RunKubectlWriteCommand(kubectl apply *)"],
      "deny": ["bash(az * delete *)", "RunKubectlWriteCommand(kubectl delete *)"]
    }
  }'

Criteri personalizzati a livello di agente (solo autorizzazione)

curl -X PUT "https://<agent>/api/v2/extendedAgent/my-k8s-agent/permissions" \
  -H "Content-Type: application/json" \
  -d '{ "allow": ["RunKubectlWriteCommand(kubectl apply *)", "RunKubectlWriteCommand(kubectl rollout *)"] }'

Criteri a livello di thread (consenti solo)

curl -X PUT "https://<agent>/api/v2/threads/<thread-id>/permissions" \
  -H "Content-Type: application/json" \
  -d '{ "allow": ["RunKubectlWriteCommand(kubectl apply -f deploy.yaml)"] }'

Limits