Un agente che può installare qualsiasi cosa, chiamare qualsiasi servizio e scrivere ovunque è sicuro solo se le barriere sono reali. In Kortix sono sotto l'agente, nella piattaforma, dove un prompt non può aggirarle con le parole.
Una sessione non è una scheda in un runtime condiviso. È una macchina propria, e il database non permette a due sessioni di averne una uguale. Separare due tue sessioni usa lo stesso meccanismo che separa due clienti diversi.
all'interno di una sessione
non entra mai
Uno strumento ha bisogno di una credenziale reale per svolgere un lavoro reale, quindi la domanda corretta non è se la macchina ne custodisca mai una. È quale macchina custodisca quale chiave, chi lo abbia deciso e cosa non vi entri mai.
01
Cifrato con AES-256-GCM tramite una chiave derivata per progetto.
02
Sia il ruolo della persona sia l'autorizzazione dichiarata dell'agente devono consentirlo.
03
Inserito nella sessione all'avvio, tramite nome, su tmpfs con modalità 0600.
04
Lo strumento lo legge dall'ambiente. Non viene scritto nel prompt.
05
Il file viene cancellato all'arresto e la macchina viene distrutta insieme a esso.
La maggior parte degli strumenti AI dà all'agente tutto ciò a cui può accedere la persona che lo ha avviato. Kortix no. L'identità di un agente ha le proprie policy, valutate autonomamente, quindi non può ereditare l'accesso a qualcosa che non gli hai mai concesso.
entità
tipo di risorsa
Le autorizzazioni si applicano a un principal, per un'azione, su un tipo di risorsa.
Ruoli integrati, per ogni piano
account
project
Enterprise
Available on Enterprise, and on a self-hosted instance with an Enterprise license. The built-in roles above are free on every plan.
Un account di servizio è un'identità macchina di prima classe appartenente all'account, non un token umano travestito. Le policy si applicano direttamente a esso e ogni richiesta viene valutata esclusivamente secondo le sue policy: non eredita mai l'accesso di chi l'ha creato.
Una persona o un gruppo può essere limitato ad agenti e skill nominati all'interno di un progetto: il marketing può usare questo agente e questa skill, e nient'altro. Ciò che lasci senza ambito resta valido per l'intero progetto, quindi la limitazione è una scelta, non qualcosa da annullare.
L'approvazione non è un'impostazione nascosta in un pannello di amministrazione. È un blocco in kortix.yaml, versionato con tutto il resto, che indica quali chiamate agli strumenti vengono eseguite, quali si fermano in attesa di una persona e quali vengono rifiutate senza eccezioni.
# reads run; writes and destructive calls stop for a humanpolicy: default_mode: risk policies: # a name-only rule cannot gate the target — conditions can - match: gmail.send_email action: require_approval conditions: - arg: to match: /@example\.com$/ # anything else through this tool is refused outright - match: gmail.send_email action: block # whole connectors can be gated with one glob - match: stripe.* action: require_approvalTre azioni
always_run, require_approval, block. Una regola corrisponde a un glob sui percorsi completi degli strumenti, quindi una riga può coprire una singola chiamata o un intero connettore.
Controlla la destinazione, non solo lo strumento
«L'agente può inviare email» non è una barriera. Le condizioni confrontano gli argomenti, quindi la regola può essere «solo a questi indirizzi». Un argomento che non può essere valutato viene rifiutato per sicurezza.
Nessun «consenti sempre» generale
Ogni chiamata soggetta a controllo viene approvata singolarmente, con i suoi argomenti davanti a te. Non esiste un'autorizzazione valida per l'intera sessione dietro cui una chiamata successiva con argomenti diversi possa nascondersi: questa scorciatoia è stata rimossa dal punto di applicazione dei controlli, non solo dall'interfaccia.
Imposta il valore predefinito che vuoi
default_mode: risk fa eseguire le letture e invia scritture e chiamate distruttive a una persona. Un progetto senza blocco di policy mantiene il permissivo comportamento legacy, quindi imposta esplicitamente questo valore.
Un agente può scrivere quanto vuole sul proprio ramo. Portare quel lavoro su main è una capacità separata che non possiede, a meno che tu non gliela conceda deliberatamente; e concederla è a sua volta una modifica che qualcuno deve approvare.
Ogni modifica finisce nel ramo creato per quella sessione. Nulla di ciò che fa l'agente è visibile a un'altra sessione o a main.
Quando l'agente vuole conservare qualcosa oltre la durata della macchina, esegue il commit e apre una change request indirizzata a main. È l'unico accesso.
Una change request è un diff. Un agente che riscrive il proprio prompt viene revisionato come una modifica al codice, perché lo è. Una change request il cui manifest non è valido non può essere unita in alcun caso.
L'unione è una capacità autonoma, rifiutata a ogni agente salvo concessione da parte di un amministratore. La concessione vive in kortix.yaml, quindi un agente non può ampliare il proprio accesso senza una change request approvata da qualcun altro.
Ogni azione dell'account e ogni azione dell'agente vengono acquisite su ogni piano. Il piano stabilisce chi può leggere, esportare o trasmettere quel registro, non se esiste.
Lo stesso prodotto è disponibile come cloud gestito, come stack nella tua rete e come deployment isolato. È open source, quindi ciò di cui ti fidi è codice che puoi leggere.
Il servizio gestito. Gestiamo control plane e compute; tu gestisci l'azienda.
Un unico stack Docker Compose sul tuo sistema, dalle stesse immagini usate dal cloud gestito. Database e file restano su dischi sotto il tuo controllo.
A single-tenant deployment inside your own network. Isolated topologies are scoped with us rather than self-served.
La nostra situazione attuale
Non possediamo ISO 27001 né HIPAA e non lasciamo intendere il contrario. Quando arriva un report, questa riga cambia quel giorno, non prima.
Non aprire una issue pubblica per una vulnerabilità. Scrivi al contatto di sicurezza indicando la versione o il commit interessato, la riproduzione e l'impatto.
contatto per la sicurezza
security@kortix.comDiamo credito ai ricercatori che lo desiderano, dopo il rilascio della correzione.