Trust Center

Come Mnemom si guadagna la fiducia che ti chiediamo di accordare.

Ogni affermazione sul sito di marketing mappa su un percorso di codice, una pagina di documentazione e un test. Questa pagina è il punto d'ingresso della superficie di livello audit: architettura, disclosure, attestazioni e SBOM. Tutto live, datato e sostituibile.

Architettura

I quattro checkpoint, in un solo diagramma.

Mnemom è un piano di fiducia attorno alla Sua flotta di agenti. Ogni richiesta attraversa quattro checkpoint — porta d'ingresso, interno·autonomia (AIP), interno·integrità (AAP), porta d'uscita — e ogni verdetto è firmato.

Porta d'ingresso

Filtraggio dei messaggi in ingresso — ogni prompt e risultato di tool che raggiunge il Suo agente è valutato per prompt injection, ingegneria sociale, injection indiretta e coercizione di chiamate a tool. Verdetto firmato Ed25519.

Interno · autonomia · AIP

L'Agent Integrity Protocol valuta il pensiero dell'agente rispetto alla sua Alignment Card a ogni turno. Drift, disallineamento di valori e violazioni di confini emergono nella decision trace firmata.

Interno · integrità · AAP

L'Agent Alignment Protocol registra le AP-Traces a posteriori e verifica la coerenza comportamentale rispetto alla card. La catena di audit collega i checkpoint AIP alle trace AAP tramite `linked_trace_id`.

Porta d'uscita

Filtraggio delle risposte in uscita — ogni risposta dell'agente è valutata contro PII, segreti, violazioni di alignment card e schemi di consigli regolamentati prima che esca dal Suo perimetro. Una fuga non redatta non può produrre un certificato firmato valido.

Conscience Architecture Card (CAC)

Ogni deployment Mnemom è legato a una CAC firmata che dichiara quali checkpoint sono attivi e in quale modalità (off / observe / nudge / enforce / enforce_sync). La CAC è pubblicata per tenant e fa parte della posture di fiducia verificabile.

Policy di versioning

Policy di versioning AAP + AIP e processo RFC del protocollo.

Entrambi i protocolli sono versionati semver. I breaking change passano per un processo RFC pubblico prima di arrivare in una release. Le versioni minor aggiungono campi con valori di default; le versioni major possono cambiare il formato wire con una runway di deprecation.

  • Versione minor (1.X.0): additiva — nuovi campi, nuovi valori di enum, nuove categorie di concern opzionali. Retrocompatibile.
  • Versione patch (1.0.X): bug fix, aggiornamenti di doc. Nessuna modifica di schema.
  • Versione major (X.0.0): modifica del formato wire. Passa per una RFC pubblica su github.com/mnemom/aap/discussions o aip/discussions. Finestra di commenti minima di 90 giorni prima di una RC v2.
  • Deprecation: minimo 180 giorni dall'annuncio alla rimozione. I verdetti emessi sotto una versione deprecata restano verificabili indefinitamente.
Versioni attualmente pubblicate
  • npm: @mnemom/agent-alignment-protocol
  • npm: @mnemom/agent-integrity-protocol
  • npm: @mnemom/aip-verifier
  • PyPI: agent-alignment-protocol
  • PyPI: agent-integrity-proto
Apri una RFC
Threat model

Cosa Mnemom è progettato per prevenire — e cosa no.

Riassunto pubblico del threat model. Il documento completo vive nel repo safe-house-hardening ed è rivisto trimestralmente. T8 pubblicherà qui la versione estesa.

Nell'ambito (prevenuto by design)

  • Violazioni di confini — azioni fuori dall'Alignment Card dichiarata dell'agente.
  • Prompt injection + injection indiretta — contenuti in ingresso avversariali.
  • Fughe di dati in uscita — PII, segreti, violazioni di alignment card.
  • Drift comportamentale — deviazione graduale dalla baseline dell'agente.
  • Fabbricazione di verdetti — il layer di prova rileva verdetti manomessi o fabbricati.
  • Fuga di dati cross-tenant — confini stretti tra tenant su prompt, trace e alignment card.

Fuori ambito (disclosure onesta)

  • ·Correttezza dell'inferenza LLM — proviamo il giudizio dell'auditor, non l'output del modello.
  • ·Reasoning steganografico sofisticato — gli agenti che ragionano in modo invisibile eludono l'analisi dei thinking block.
  • ·Compromissione dell'infrastruttura del provider LLM sottostante.
  • ·Attacchi fisici / supply chain contro il deployment del cliente.
  • ·Denial-of-service contro l'infrastruttura Mnemom (mitigato, non eliminato).
Disclosure responsabile

Segnala una vulnerabilità — SLA di 90 giorni.

La disclosure coordinata protegge tutti. Confermiamo la ricezione velocemente, fixiamo in pubblico e accreditiamo il reporter.

  1. 1
    Conferma di ricezione entro 3 giorni lavorativi.
  2. 2
    Conferma della riproduzione entro 14 giorni.
  3. 3
    Fix o mitigazione entro 90 giorni dalla conferma di ricezione.
  4. 4
    Disclosure pubblica: 90 giorni dalla conferma di ricezione, o prima se il fix è in produzione e i clienti sono protetti.

Chiave PGP disponibile su mnemom.ai/.well-known/pgp-key.txt (alla pubblicazione)

Bug bounty

Programma di disclosure in buona fede (bounty formale in scoping).

Un programma formale di bug bounty è in scoping. Fino al lancio, gestiamo un processo privato di disclosure in buona fede. I report idonei ottengono riconoscimento nella hall of fame e possono ricevere un riconoscimento monetario a nostra discrezione.

Nell'ambito

  • Gateway (gateway.mnemom.ai) — firma delle richieste, filtraggio in ingresso della porta d'ingresso, pipeline di attestazione.
  • Observer + analisi a posteriori (api.mnemom.ai/v1/analyze) — derivazione dei verdetti, filtraggio in uscita della porta d'uscita.
  • Control plane (api.mnemom.ai) — auth, fatturazione, containment, audit log.
  • SDK (@mnemom/agent-alignment-protocol, @mnemom/agent-integrity-protocol) — logica di verifica, verifica delle prove ZK.
  • Contratti on-chain (MnemoReputationRegistry, MnemoMerkleAnchor su Base L2).
  • Superfici di marketing (mnemom.ai, app.mnemom.ai) — autenticazione, gestione delle sessioni, RBAC.

Fuori ambito

  • ·Rate limiting e denial-of-service (mitigato da Cloudflare; non è target di bounty).
  • ·Ingegneria sociale contro i dipendenti.
  • ·Attacchi fisici contro l'infrastruttura.
  • ·Servizi di terze parti da cui dipendiamo (Cloudflare, Supabase, Stripe, Resend, Anthropic, OpenAI). Da segnalare direttamente al fornitore.
  • ·Report che richiedono accesso a email, dispositivo o account social di una vittima.

Hall of fame per ora vuoto; i segnalatori saranno elencati qui con il loro consenso.

Compliance

Attestazioni e posture.

Posture di compliance corrente. Pubblichiamo i cambi di posture man mano che avvengono — readiness non è attestazione.

SOC 2 Type II

Readiness in corso

Audit in scoping. Pubblicheremo l'URL del report al completamento.

EU AI Act

Articolo 50 pronto · Articolo 15 pronto

Articolo 50 (trasparenza, agosto 2026) e Articolo 15 (accuratezza / robustezza / cybersecurity, agosto 2027). I preset SDK sono disponibili oggi; documentazione di mapping su /research/eu-ai-act.

HIPAA

Flussi compatibili HIPAA

Detector DLP per pattern PHI. BAA disponibile in Enterprise. Noi stessi non siamo covered entity.

ISO 42001

Mapping pubblicato

Mapping del sistema di gestione AI in revisione. Percorso di certificazione da definire.

NIST AI RMF 1.0

Aligned

Mapping delle funzioni GOVERN + MAP pubblicato in safe-house-hardening.

Stato del network AEGIS

Sette SLO per il network difensivo cross-tenant.

AEGIS — il network di sicurezza cross-tenant che avvolge la Safe House — porta con sé i propri SLO pubblicati. Le metriche di riferimento sono definite; le prime misurazioni saranno pubblicate 30 giorni dopo la GA. La tabella completa, il codice sorgente e i dati storici si trovano su /trust/slos.

Propagazione delle Managed Rule

P95 ≤ 30s

Promozione firmata fino al caricamento da parte del gateway, tramite due percorsi di consegna firmati e indipendenti.

Misurazione in attesa

Freschezza del rule-set

P99 ≤ 5 min

In condizioni operative normali, su tutta la flotta di gateway.

Misurazione in attesa

Allerta di obsolescenza

P0 a 24h

Reperibilità allertata quando il recipe set di un gateway è obsoleto da 24 ore.

Misurazione in attesa

Disponibilità del failover

99,99%

Il gateway carica con successo un set di regole verificato su più livelli di lettura indipendenti.

Misurazione in attesa

Verifica della firma

≥ 99,99%

Un fallimento della firma scatena un P0 e un fallback R2 con catena di firma indipendente.

Misurazione in attesa

Tasso di falsi positivi per recipe

FP a 7 giorni mobili per recipe

Auto-rollback quando il rapporto FP di una recipe supera la soglia per livello (CLPI Fase 2).

Misurazione in attesa

Gate di mutation-phase

Soglia di rilevamento sostenuto

Tasso di rilevamento arena di ingresso/uscita per bucket. Per (substrate × verticale × pattern × sorgente).

Misurazione in attesa
Misurazione in attesa

La prima finestra di misurazione di 30 giorni sarà pubblicata 30 giorni dopo la GA. Non annunciamo in anticipo numeri che non possiamo difendere. Il codice sorgente degli SLO, le query di misurazione e i dati storici saranno pubblicati su /trust/slos/history una volta chiusa la finestra.

EU AI Act

Articoli 10, 12 e Allegato IV — cosa fornisce AEGIS.

L'applicazione dell'EU AI Act ai sistemi di IA ad alto rischio inizia il 2026-08-02. Tre disposizioni sono portanti per qualsiasi infrastruttura di agenti: governance dei dati (Articolo 10), tenuta dei registri (Articolo 12) e documentazione tecnica (Allegato IV). AEGIS produce le prove verificabili richieste da ciascuna. La conformità è una responsabilità congiunta; la tabella sotto indica cosa forniamo noi.

Articolo 10

Governance dei dati per l'IA ad alto rischio

Catena di eventi di governance append-only — ogni promozione di recipe, ritiro, cambio di modalità e azione del revisore è firmata Ed25519 e concatenata. La stampigliatura dell'identità del writer isola al livello di schema le sorgenti di segnale arena, cliente e operatore.

Articolo 12

Tenuta dei registri e tracciabilità

Catena di audit firmata lungo l'intero ciclo di vita — firma di promozione, firma di envelope KV, firma di envelope R2 su chiavi indipendenti, righe di valutazione per gateway timbrate con substrate fingerprint e identità del writer. I record sono interrogabili, riproducibili e a prova di manomissione.

Allegato IV

Documentazione tecnica

CMS pubblico di advisory su /trust/advisories con resoconti post-incidente firmati, feed di IoC leggibile da macchine su /v1/trust/iocs (STIX 2.1) e SLO pubblicati su /trust/slos. La documentazione tecnica che cercano gli auditor è la stessa che leggono clienti e agenti.

Non è consulenza legale. Questa pagina indica le prove prodotte da AEGIS; gli obblighi ai sensi del regolamento restano in capo al deployer. Riferimenti EU AI Act: Articoli 10, 12 e Allegato IV. L'applicazione degli obblighi ad alto rischio inizia il 2026-08-02.

Affidabilità

Service-level objectives.

Gli obiettivi a cui Mnemom si impegna pubblicamente sono gli stessi che il validation harness verifica in CI. Lo stato live corrente è su status.mnemom.ai; gli impegni e il razionale sono documentati qui.

Supply chain

Pubblicazione SBOM per ogni release.

Ogni release del gateway worker e ogni versione di SDK è consegnata con un SBOM CycloneDX. Gli SBOM per release sono linkati dalla pagina della release su GitHub.

  • SBOM Gateway · github.com/mnemom/mnemom-platform/releases
  • SBOM AAP · github.com/mnemom/aap/releases
  • SBOM AIP · github.com/mnemom/aip/releases

Gli SBOM sono in formato CycloneDX 1.5 JSON. Ci impegniamo a pubblicare per ogni release; non ci impegniamo oggi a embeddare l'SBOM in un'attestazione TUF o in-toto (in valutazione).

Ultimo aggiornamento 2026-05-16. Questa pagina evolve in parallelo alla track safe-house-hardening.

Auditato trimestralmente · prossimo aggiornamento luglio 2026

Inventario delle affermazioni di marketing

Featured on There's An AI For That