
Sicurezza runtime per agenti AI: scopri gli agenti, mappa i loro permessi e applica ciò che possono fare.
<img src="https://raw.githubusercontent.com/kontext-security/kontext-cli/main/assets/kontext-computer-wordmark.gif" alt="Kontext animated wordmark" width="100%" />
<div align="center">
<p>
<a href="https://kontext.security">Website</a>
|
<a href="https://docs.kontext.security/getting-started/welcome">Documentazione</a>
|
<a href="https://app.kontext.security">Dashboard</a>
|
<a href="https://discord.gg/gw9UpFUhyY">Discord</a>
</p>
<p>
<a href="https://github.com/kontext-security/kontext-cli/blob/main/LICENSE"><img alt="License: MIT" src="https://img.shields.io/badge/license-MIT-152822?labelColor=0d1714"></a>
<a href="https://github.com/kontext-security/kontext/releases"><img alt="Latest release" src="https://img.shields.io/github/v/release/kontext-security/kontext?color=152822&labelColor=0d1714"></a>
<img alt="Built with Go" src="https://img.shields.io/badge/Go-1.25-152822?labelColor=0d1714">
</p>
</div>
# Blocca le azioni rischiose degli agenti AI prima che vengano eseguite
Gli agenti AI non si limitano a suggerire codice. Eseguono comandi shell, leggono file, chiamano servizi, modificano infrastrutture e interagiscono con sistemi di produzione.
**Kontext inserisce una policy locale tra gli agenti AI e gli strumenti che chiamano.** Osserva le azioni supportate, valuta la policy prima che vengano eseguite azioni consequenziali e registra la decisione e l'esito in un registro delle autorizzazioni.
Inizia in modalità osservazione. Guarda cosa bloccherebbe la policy. Passa i confini supportati all'applicazione quando sei pronto.
Gli errori di valutazione della policy consentono la chiamata allo strumento, anche in modalità enforce, e rimangono visibili come errori nel registro delle attività. I dinieghi completati dalla policy e le approvazioni richieste non disponibili continuano comunque a bloccare. Questo fallback in caso di errore non cambia il comportamento quando il daemon non è disponibile o l'applicazione non ha una policy utilizzabile.
- **Decisioni locali:** la valutazione della policy avviene accanto all'agente.
- **Applicazione pre-azione:** le azioni corrispondenti possono essere negate negli hook sincroni supportati.
- **Nessun comando wrapper:** installa Kontext una volta e continua a usare i tuoi agenti normalmente.
- **Evidenza attribuibile:** conserva l'agente, la sessione, l'azione, la decisione della policy e l'esito.
- **Distribuzione gestita:** distribuisci la policy e rivedi i record redatti in tutta l'organizzazione.
Kontext attualmente supporta **Claude Code, Claude Cowork e Codex**. La copertura esatta degli eventi e dell'applicazione varia a seconda dell'agente—vedi la
[matrice di supporto degli agenti](https://github.com/kontext-security/kontext-cli/blob/main/docs/coverage.md).
Gli hook gestiti di Claude riconoscono le sessioni Cowork con nomi di directory di sessione completi o abbreviati, preservando la loro identità Cowork nei record delle attività.
---
## Avvio rapido
### Installa Kontext
```bash
brew install kontext-security/tap/kontext
```
### Connetti questo Mac
Crea un token di installazione nella
[dashboard Kontext](https://app.kontext.security), poi esegui:
```bash
kontext setup
```
Il modello di rischio locale opzionale richiede llama.cpp: esegui `brew install llama.cpp`, poi `kontext setup --with-local-llm`.
Setup:
- memorizza il token di installazione nel portachiavi di login di macOS;
- installa gli hook per gli agenti supportati;
- avvia il daemon Kontext locale;
- connette l'installazione alla tua organizzazione Kontext.
Verifica l'installazione:
```bash
kontext doctor
```
Poi continua a usare Claude Code o Codex normalmente. Non è necessario avviare l'agente tramite un wrapper separato.
> Il setup self-serve attualmente supporta macOS. Gli ambienti gestiti e cloud possono eseguire lo stesso runtime locale quando forniscono un contratto di hook supportato, storage e ciclo di vita del daemon.
---
## Cosa cambia dopo il setup?
Senza una policy pre-azione, un'azione dell'agente viene eseguita prima che un team di sicurezza possa rivederne i log:
```text
agent requests an action
|
v
action executes
|
v
activity appears in a log
```
Con Kontext:
```text
agent requests an action
|
v
Kontext receives it through a supported hook
|
v
local policy evaluates the action
|
+---- allow ----------> action continues
|
+---- would deny -----> action continues and evidence is recorded
| (observe mode)
|
+---- deny -----------> action is stopped before execution
(enforce mode)
|
v
decision and outcome enter the authorization ledger
```
Questo crea un punto decisionale prima dell'azione, non solo un record dopo di essa.
---
## Osserva prima. Applica quando sei pronto.
Bloccare ogni azione sconosciuta il primo giorno crea rumore e interrompe gli sviluppatori. Consentire ogni azione a tempo indefinito lascia la policy come monitoraggio passivo.
Kontext separa la distribuzione in due modalità:
### Modalità osservazione
La modalità osservazione registra la decisione della policy senza interrompere l'agente.
Usala per rispondere a:
- Quali strumenti stanno chiamando gli agenti?
- Quali azioni negherebbe la policy attuale?
- Quali repository, file e sistemi sono coinvolti?
- Dove interromperebbe l'applicazione il lavoro legittimo?
- Quali superfici di eventi possono effettivamente fermare l'azione?
### Modalità enforce
La modalità enforce restituisce un diniego reale quando una policy deterministica corrisponde a un hook pre-azione sincrono supportato.
Le policy possono definire confini attorno ad azioni come:
- comandi distruttivi;
- accesso a file sensibili;
- operazioni su sistemi di produzione;
- accesso a credenziali;
- esportazioni di dati.
L'applicazione è intenzionalmente limitata alle superfici di eventi in cui l'agente attende Kontext prima di continuare. Kontext non afferma che ricevere un evento significhi poter fermare ogni azione da quell'agente.
---
## Sappi cosa è successo—e perché
Ogni evento supportato che raggiunge Kontext può contribuire con evidenza al registro delle autorizzazioni locale.
Un record può includere:
- l'agente e la sessione;
- l'evento del ciclo di vita o dello strumento;
- il nome dello strumento e l'input disponibile;
- la decisione della policy locale;
- la policy responsabile di quella decisione;
- l'esito dell'azione disponibile;
- l'evidenza redatta per una revisione successiva.
Kontext registra l'attività degli strumenti e l'evidenza delle decisioni. Non cattura il ragionamento del modello né ricostruisce la cronologia completa della conversazione.
Le distribuzioni gestite possono esportare i record redatti nella dashboard Kontext per revisione, conservazione e indagine a livello organizzativo.
Le esportazioni del registro e gli heartbeat di inattività riportano la release CLI del daemon in esecuzione come
`device.cli_version`, separatamente dal marcatore del pacchetto in
`device.deployment_version` (o il suo fallback self-serve). Un aggiornamento del marcatore del pacchetto non cambia la release CLI riportata finché un daemon che esegue il nuovo binario non invia la telemetria.
---
## Policy dove viene eseguito l'agente
Il percorso decisionale rimane locale:
```text
Claude Code / Cowork / Codex
|
v
supported hook
|
v
local Kontext runtime
|
+-----+------+
| |
v v
policy decision local ledger
|
v
allow / would deny / deny
```
Un servizio ospitato non deve rispondere a ogni chiamata di strumento.
Le distribuzioni gestite aggiungono configurazione organizzativa, distribuzione della policy, esportazione dei record, identità e conservazione. Non spostano il percorso decisionale sincrono fuori dall'ambiente dell'agente.
---
## Agenti supportati
"Supportato" significa più che accettare un evento. Kontext documenta quali eventi riceve, quali eventi possono bloccare e come viene installata ogni integrazione.
| Agente | Cosa registra Kontext | Blocco pre-azione | Installazione |
| --- | --- | --- | --- |
| **Claude Code** | Ciclo di vita della sessione, pre-tool-use, post-tool-use riuscito e fallito | Pre-tool-use | Installato da `kontext setup` |
| **Codex** | Avvio sessione, pre-tool-use, post-tool-use, invio prompt, stop | Pre-tool-use | Installato da `kontext setup`; gli hook devono essere considerati attendibili in Codex |
| **Claude Cowork** | Eventi di sessione e strumenti compatibili con Claude Code | Pre-tool-use | Configura l'hook all'interno dell'ambiente Cowork |
Vedi la [matrice di supporto degli agenti](https://github.com/kontext-security/kontext-cli/blob/main/docs/coverage.md) per il comportamento esatto, l'ambito di distribuzione e le lacune note. È la fonte autorevole per la copertura dell'applicazione.
---
## Kontext e le sandbox risolvono problemi diversi
Una sandbox di processo chiede:
> A quali file, destinazioni di rete, credenziali e risorse del sistema operativo può accedere questo processo?
Kontext chiede:
> Quale agente sta tentando quale azione, quale policy si applica, l'azione dovrebbe procedere e quale evidenza prova la decisione?
Le sandbox del kernel sono forti confini di contenimento. Kontext fornisce policy semantica e attribuzione negli hook supportati di agenti e strumenti.
Sono complementari:
```text
Kontext
decides whether the action is authorized
|
v
sandbox
constrains what the process can physically access
```
Kontext non rivendica l'isolamento a livello di kernel. Usa una sandbox appropriata quando il modello di minaccia richiede il contenimento di processo, filesystem o rete.
---
## Perché non limitarsi a raccogliere i log degli agenti?
I log ti dicono cosa ha riportato un agente dopo un evento.
Kontext crea una decisione di autorizzazione prima che vengano eseguite le azioni consequenziali supportate, poi collega quella decisione all'esito disponibile.
Questa distinzione è importante durante:
- la distribuzione della policy;
- l'indagine sugli incidenti;
- la revisione dell'accesso alla produzione;
- la gestione delle eccezioni degli sviluppatori;
- la revisione di conformità e audit.
Il risultato non è solo "l'agente ha chiamato uno strumento". È l'evidenza di cosa è stato richiesto, quale policy si è applicata, se è stato consentito e cosa è successo dopo.
---
## Esegui Kontext in tutta la tua organizzazione
Le distribuzioni gestite aggiungono:
- policy deterministica gestita centralmente;
- identità aziendale e controlli organizzativi;
- distribuzione da osservazione ad applicazione;
- supporto per la distribuzione gestita di agenti e cloud;
- esportazione di evidenza redatta;
- conservazione per audit;
- monitoraggio dello stato di salute e del backlog della distribuzione;
- onboarding per i team di sicurezza e piattaforma.
Per la pianificazione della distribuzione e l'onboarding dell'organizzazione, contatta
[[email protected]](mailto:[email protected]) o
[prenota una conversazione](https://calendar.superhuman.com/book/11W5Y8b5JsB8dOzQbd/YECs9).
---
## Diagnostica un'installazione
```bash
kontext doctor
```
`doctor` controlla:
- gli hook degli agenti installati;
- lo stato di salute e la versione del daemon;
- lo stato di salute dell'esportazione gestita;
- il backlog di esportazione in sospeso.
Esce con codice diverso da zero quando un'installazione configurata non è in salute.
La validazione degli hook di Claude accetta quoting shell equivalenti pur richiedendo comunque l'eseguibile, gli argomenti e le impostazioni degli eventi previsti. La diagnostica degli hook di Codex controlla sia i file di sistema che quelli utente: un file assente o vuoto è valido quando l'altro contiene un'installazione completa. I file non vuoti malformati o incompleti e le installazioni in conflitto continuano a segnalare un setup non in salute.
Quando un drop-in Claude di proprietà manca solo degli eventi richiesti dalla versione corrente, doctor indica gli eventi mancanti e il comando `hooks install` specifico per lo scope. Le riparazioni self-serve richiedono sudo solo per aggiornare il file di sistema di Claude; le riparazioni dell'organizzazione richiedono `sudo` con `--scope system`. `doctor --fix` non reinstalla gli hook.
Quando un daemon self-serve è obsoleto:
```bash
kontext doctor --fix
```
Ruota il token di installazione eseguendo di nuovo il setup:
```bash
kontext setup
```
Rimuovi l'installazione self-serve:
```bash
kontext setup --uninstall
```
---
## Gestione dei dati
- Le decisioni della policy avvengono localmente.
- L'attività degli strumenti e l'evidenza delle decisioni sono archiviate localmente.
- I valori sensibili vengono redatti prima dell'archiviazione locale e dell'esportazione gestita.
- Kontext non memorizza il ragionamento del modello né la cronologia completa della conversazione.
- Le distribuzioni gestite possono esportare i record redatti nella dashboard dell'organizzazione.
Vedi la [documentazione di Guard](https://github.com/kontext-security/kontext-cli/blob/main/docs/guard.md) per il runtime e il confine dei dati.
---
## Sviluppo
```bash
go build -o bin/kontext ./cmd/kontext
go test ./...
go test -race ./...
go vet ./...
```
## Community
- Leggi [SUPPORT.md](https://github.com/kontext-security/kontext-cli/blob/main/SUPPORT.md) per i canali di supporto.
- Leggi [CONTRIBUTING.md](https://github.com/kontext-security/kontext-cli/blob/main/CONTRIBUTING.md) prima di aprire un contributo.
- Segnala le vulnerabilità tramite la nostra [Security Policy](https://github.com/kontext-security/kontext-cli/blob/main/SECURITY.md).
- Kontext è rilasciato sotto [MIT License](https://github.com/kontext-security/kontext-cli/blob/main/LICENSE).
### Report delle autorità
`kontext report` mostra gli agenti e le autorità scoperti esattamente come ultimamente accettati dal cloud. Usa `kontext report --json` per il payload grezzo. Prima del primo invio riuscito, non riporta dati.
Imposta `KONTEXT_AUTHORITY_SCAN=off` nell'ambiente del daemon per disabilitare la raccolta e la trasmissione delle autorità su questo Mac.