Sicurezza
Come è protetto Mnemom.
AEGIS controlla le chiamate al modello dei suoi agenti mentre sono in esecuzione. Più sotto, i controlli che proteggono la piattaforma stessa. Questionari di sicurezza ed evidenze dei controlli sono disponibili sotto NDA.
Controllo a runtime AEGIS
Ogni chiamata al modello è controllata in quattro punti.
Le chiamate al modello che passano dal gateway Mnemom sono controllate in ingresso, nell'uso degli strumenti, nel ragionamento dell'agente e in uscita. Per ogni agente lei sceglie se un controllo registra soltanto, avvisa o interviene.
- 1
front door
L'ultimo messaggio dell'utente e gli eventuali risultati degli strumenti, prima che raggiungano il modello.
- 2
inside.autonomy
Gli strumenti offerti al modello e le chiamate agli strumenti che effettua.
- 3
inside.integrity
Il ragionamento dell'agente, esaminato dal nostro controllo di integrità (AIP).
- 4
back door
La risposta, prima che torni alla sua applicazione.
Cosa controlliamo
| Minaccia | Controllato a | Come |
|---|---|---|
| Prompt injectionfront door | Regole di pattern, poi un giudice basato su un modello. Il testo viene prima normalizzato, così i caratteri simili o nascosti non passano. | |
| Istruzioni nascoste nei risultati degli strumentifront door | Gli stessi controlli sui risultati degli strumenti, come una pagina o un documento recuperato. In modalità enforce un risultato segnalato viene sostituito prima che il modello lo veda. | |
| Strumenti vietati e operazioni protetteinside.autonomy | Gli strumenti sono confrontati con l'Alignment Card dell'agente. Le chiamate agli strumenti sono confrontate con gli asset e le operazioni che la sua organizzazione segna come protetti, come l'eliminazione di una tabella. | |
| Dati sensibili nelle risposteback door | Numeri di carta, numeri di previdenza sociale statunitensi, chiavi API, chiavi private, token di accesso, stringhe di connessione, email, numeri di telefono e indirizzi IP. Oscurati nelle risposte senza streaming, registrati in quelle in streaming. | |
| Frode nei pagamenti e impersonificazionefront door | Segnala un cambio di beneficiario o di conto bancario unito a urgenza, segretezza o pressione per saltare un'approvazione. | |
| False rivendicazioni di autoritàfront door | Segnala i messaggi che dichiarano di provenire da un sistema, da un amministratore o da Mnemom. | |
| Ragionamento non sicuroinside.integrity | Un modello esamina il ragionamento dell'agente per individuare prompt injection, disallineamento di valori, violazioni di autonomia, ragionamento ingannevole e intenzioni non dichiarate. |
Tre impostazioni per agente
- Safe House copre front door, chiamate agli strumenti e back door. Ognuna può essere attivata o disattivata.
- Autonomia copre l'uso degli strumenti rispetto all'Alignment Card.
- Integrità copre il ragionamento dell'agente.
Le impostazioni valgono a livello di piattaforma, organizzazione, team e agente, e prevale la più restrittiva. Un livello inferiore può aggiungere protezione ma non può rimuovere o indebolire quella impostata sopra. Gli amministratori dell'organizzazione impostano i livelli di organizzazione, team e agente.
Quattro modalità per impostazione
| Modalità | Cosa succede |
|---|---|
| off | Il controllo non viene eseguito. |
| observe | Il controllo viene eseguito e il risultato registrato. Richiesta e risposta restano invariate. |
| nudge | La richiesta passa con un avviso visibile al modello e alla sua applicazione. I dati sensibili nelle risposte in uscita vengono oscurati. |
| enforce | Il contenuto segnalato non passa. Un messaggio non sicuro viene sostituito da un avviso di quarantena, un turno con uno strumento vietato o un controllo di integrità fallito viene sostituito da un rifiuto, e i dati sensibili vengono oscurati. |
Il risultato è in ogni risposta
Ogni risposta del gateway riporta l'esito di ogni punto di controllo in un header. Ogni checkpoint di integrità è inoltre firmato e concatenato, come descritto più sotto in Registro firmato.
x-mnemom-verdict: front=pass; autonomy=pass; integrity=pass; back=passCome le regole restano aggiornate
- Le regole di rilevamento arrivano a ogni gateway come set di regole firmato con Ed25519. Ogni gateway verifica la firma prima di usare le regole e recepisce le modifiche entro pochi minuti.
- Testiamo il controllo in modo continuo con un attaccante automatizzato e adattivo che agisce contro agenti di prova in un ambiente isolato, mai contro agenti dei clienti.
- Le nuove regole vengono riviste prima di arrivare in produzione.
OWASP Top 10 per le applicazioni agentiche
Dove copriamo i rischi agentici e dove no.
| Rischio | Copertura | Cosa fa Mnemom |
|---|---|---|
| ASI01 Agent goal hijackParziale | I messaggi in ingresso e i risultati degli strumenti sono controllati per injection diretta e indiretta, e il rischio è seguito lungo i turni di una sessione. | |
| ASI02 Tool misuseParziale | Gli strumenti vietati dalla card possono essere rifiutati, e le chiamate verso asset o operazioni protetti possono essere trattenute. Non tutte le chiamate non sicure vengono rilevate. | |
| ASI03 Identity and privilege abuseParziale | I permessi sugli strumenti derivano dalla card dell'agente, e le rivendicazioni in ingresso di autorità di sistema o di amministratore vengono segnalate. | |
| ASI04 Supply chainNon coperto | Registriamo provider, modello e versione dell'SDK dietro ogni richiesta controllata, più un hash del lockfile opzionale. Non rileviamo dipendenze compromesse. | |
| ASI05 Unexpected code executionNon coperto | Esegua il codice generato in una sandbox nella sua applicazione. | |
| ASI06 Memory and context poisoningLimitato | Il contenuto avvelenato che ritorna come risultato di uno strumento viene controllato. Non ci integriamo con archivi di memoria. | |
| ASI07 Insecure inter-agent communicationParziale | I messaggi di altri agenti sono controllati come qualsiasi altro input, e le false rivendicazioni di autorità vengono segnalate. I messaggi tra agenti non sono autenticati. | |
| ASI08 Cascading failuresNon coperto | Da gestire nell'architettura della sua applicazione. | |
| ASI09 Human-agent trust exploitationCoperto | La pressione basata su urgenza, autorità, segretezza o cambio dei dati di pagamento nei messaggi in ingresso viene segnalata. | |
| ASI10 Rogue agentsParziale | Il comportamento è confrontato con l'Alignment Card dell'agente. Gli amministratori possono mettere in pausa o fermare un agente, e la pausa automatica dopo violazioni ripetute può essere attivata. |
Fonte: OWASP GenAI Security Project, genai.owasp.org.
NIST AI Risk Management Framework
Controlli e registrazioni per ogni funzione.
L'AI RMF è un framework volontario che la sua organizzazione applica. Non è una certificazione. Mnemom fornisce controlli a runtime e registrazioni che ogni funzione può usare.
| Funzione | Cosa fornisce Mnemom |
|---|---|
| Govern | Una policy leggibile da macchina per ogni agente (l'Alignment Card), impostazioni a livello di organizzazione, team e agente, e un registro di chi ha modificato cosa. |
| Map | Lo scopo dichiarato e i limiti di ogni agente, e la mappatura OWASP qui sopra. |
| Measure | Un risultato a ogni punto di controllo a ogni turno, e checkpoint di integrità firmati che può verificare. |
| Manage | Le modalità observe, nudge ed enforce, e comandi di pausa e arresto per ogni agente. |
Piattaforma
Come proteggiamo la piattaforma.
Registro firmato
- Ogni checkpoint di integrità è firmato con Ed25519 e collegato in una catena di hash SHA-256 all'interno della sua sessione di agente, così un checkpoint rimosso o riordinato è rilevabile.
- Ogni certificato di checkpoint include una prova di inclusione Merkle. Chiunque può verificare un certificato tramite il nostro endpoint pubblico di verifica, o verificarne la firma con qualsiasi libreria Ed25519 standard.
- La nostra chiave pubblica di firma è pubblicata su api.mnemom.ai/v1/keys.
- Le attestazioni delle agent card sono registrate in un log pubblico append-only modellato su Certificate Transparency (RFC 6962). La sua radice firmata e le prove di consistenza sono pubbliche.
- I webhook sono firmati con HMAC-SHA256 su un timestamp e sul corpo.
- Le chiavi di firma sono custodite in Azure Key Vault e caricate nei nostri servizi tramite identità gestita.
Infrastruttura
- Ogni ambiente gira come una cella autonoma con propria rete, database, cache, key vault, storage e servizio di identità. Le celle non condividono reti.
- Database, cache, key vault e storage non hanno accesso pubblico a internet e sono raggiungibili solo tramite endpoint privati.
- Tutto il traffico pubblico ci raggiunge tramite Cloudflare. Le origini di produzione accettano connessioni solo da Cloudflare.
- I servizi interni non hanno endpoint pubblici.
- Il database di produzione mantiene uno standby in una seconda zona di disponibilità. I backup sono conservati per 30 giorni e copiati in una seconda regione.
Crittografia
- Gli endpoint pubblici accettano solo TLS 1.2 e TLS 1.3. Database, cache e storage accettano solo connessioni cifrate.
- Tutti i dati dei clienti sono cifrati a riposo.
- La nostra applicazione cifra inoltre con AES-256-GCM i segreti di firma dei webhook e le chiavi dei fornitori di modelli memorizzate.
Accesso
- Le organizzazioni hanno cinque ruoli: owner, admin, member, viewer e auditor. L'API verifica appartenenza e ruolo del chiamante a ogni richiesta dell'organizzazione.
- Le modifiche fatte tramite l'API sono registrate con il loro autore. Owner, admin e auditor possono leggere il registro della propria organizzazione.
Accesso all'account
- Accede sempre da una pagina Mnemom. Il servizio di identità gira all'interno di ogni cella e le sue pagine di login e amministrazione non sono raggiungibili da internet.
- Passkey (memorizziamo solo la chiave pubblica) e MFA con app di autenticazione. Disattivare la MFA, rimuovere una passkey o disconnettere altre sessioni richiede una nuova verifica del secondo fattore.
- Le sessioni del browser usano un cookie cifrato, HttpOnly e Secure che scade dopo 7 giorni di inattività e al massimo dopo 30 giorni. La avvisiamo via email quando il Suo account accede da un nuovo dispositivo.
- Le chiavi API vengono mostrate una sola volta e memorizzate solo come hash SHA-256. Hanno scope e può revocarle o ruotarle in qualsiasi momento.
- L'accesso della CLI e degli agenti usa OAuth con PKCE o il flusso device code.
Come rilasciamo
- Le modifiche in produzione passano da un'unica pipeline di deploy. Un rilascio arriva in produzione solo dopo l'approvazione di un ingegnere nominativamente identificato o, per le modifiche classificate a basso rischio, dopo il superamento di un canary automatico.
- I branch principali richiedono controlli automatici, tra cui la scansione dei segreti.
- La nostra organizzazione GitHub richiede l'autenticazione a due fattori. L'accesso alle risorse cloud di produzione è limitato a poche persone identificate e a identità di automazione con permessi circoscritti. Gli strumenti interni sono dietro Cloudflare Access.
Conformità
Pronti per la conformità a SOC 2 Tipo II, GDPR e HIPAA. Audit indipendente in corso. Questionari di sicurezza ed evidenze dei controlli sono disponibili sotto NDA.
EU AI Act: articoli 10 e 12 e allegato IV mappati sul registro firmato. Una mappatura tecnica, non una certificazione.
Vada alla pagina TrustSegnala una vulnerabilità
Scriva a [email protected]. La nostra policy di divulgazione è nel nostro security.txt e nella pagina Trust.
[email protected]Muoviti veloce. Resta in piedi.
Sappi cosa stanno davvero facendo i tuoi agenti, prima che lo chieda il board.
Due comandi per installare. Un registro firmato dalla prima decisione in avanti.
