Sicherheit
So ist Mnemom abgesichert.
AEGIS prüft die Modellaufrufe Ihrer Agenten, während sie laufen. Darunter stehen die Kontrollen, die die Plattform selbst schützen. Sicherheitsfragebögen und Kontrollnachweise stellen wir unter NDA bereit.
AEGIS Laufzeitprüfung
Jeder Modellaufruf wird an vier Stellen geprüft.
Modellaufrufe über das Mnemom-Gateway werden beim Eingang, bei der Tool-Nutzung, im Denken des Agenten und beim Ausgang geprüft. Pro Agent legen Sie fest, ob eine Prüfung nur protokolliert, warnt oder eingreift.
- 1
front door
Die neueste Nutzernachricht und alle Tool-Ergebnisse, bevor sie das Modell erreichen.
- 2
inside.autonomy
Die dem Modell angebotenen Tools und die Tool-Aufrufe, die es ausführt.
- 3
inside.integrity
Das Denken des Agenten, geprüft von unserem Integritätscheck (AIP).
- 4
back door
Die Antwort, bevor sie an Ihre Anwendung zurückgeht.
Worauf wir prüfen
| Bedrohung | Geprüft bei | Wie |
|---|---|---|
| Prompt Injectionfront door | Musterregeln, dann ein modellbasierter Prüfer. Der Text wird zuvor normalisiert, damit ähnlich aussehende und versteckte Zeichen nicht durchrutschen. | |
| Versteckte Anweisungen in Tool-Ergebnissenfront door | Dieselben Prüfungen für Tool-Ergebnisse, etwa eine abgerufene Seite oder ein Dokument. Im Modus enforce wird ein markiertes Ergebnis ersetzt, bevor das Modell es sieht. | |
| Verbotene Tools und geschützte Operationeninside.autonomy | Tools werden gegen die Alignment Card des Agenten geprüft. Tool-Aufrufe werden gegen die Assets und Operationen geprüft, die Ihre Organisation als geschützt markiert, etwa das Löschen einer Tabelle. | |
| Sensible Daten in Antwortenback door | Kartennummern, US-Sozialversicherungsnummern, API-Schlüssel, private Schlüssel, Zugriffstoken, Verbindungszeichenfolgen, E-Mail-Adressen, Telefonnummern und IP-Adressen. Bei Antworten ohne Streaming geschwärzt, bei gestreamten Antworten protokolliert. | |
| Zahlungsbetrug und Identitätstäuschungfront door | Markiert einen geänderten Zahlungsempfänger oder ein geändertes Bankkonto in Verbindung mit Dringlichkeit, Geheimhaltung oder Druck, eine Freigabe zu umgehen. | |
| Falsche Autoritätsbehauptungenfront door | Markiert Nachrichten, die vorgeben, von einem System, einem Administrator oder von Mnemom zu stammen. | |
| Unsicheres Denkeninside.integrity | Ein Modell prüft das Denken des Agenten auf Prompt Injection, Werteabweichung, Autonomieverstöße, täuschendes Denken und nicht erklärte Absichten. |
Drei Einstellungen pro Agent
- Safe House umfasst front door, Tool-Aufrufe und back door. Jeder dieser Bereiche lässt sich ein- oder ausschalten.
- Autonomie umfasst die Tool-Nutzung gemessen an der Alignment Card.
- Integrität umfasst das Denken des Agenten.
Einstellungen gelten auf Plattform-, Organisations-, Team- und Agentenebene, und die strengste gewinnt. Eine tiefere Ebene kann Schutz hinzufügen, aber einen weiter oben gesetzten nicht entfernen oder abschwächen. Organisationsadmins legen die Organisations-, Team- und Agentenebene fest.
Vier Modi pro Einstellung
| Modus | Was passiert |
|---|---|
| off | Die Prüfung läuft nicht. |
| observe | Die Prüfung läuft und das Ergebnis wird protokolliert. Anfrage und Antwort bleiben unverändert. |
| nudge | Die Anfrage geht mit einer Warnung durch, die das Modell und Ihre Anwendung sehen. Sensible Daten in ausgehenden Antworten werden geschwärzt. |
| enforce | Markierte Inhalte gehen nicht durch. Eine unsichere Nachricht wird durch einen Quarantänehinweis ersetzt, ein verbotener Tool-Schritt oder ein fehlgeschlagener Integritätscheck durch eine Ablehnung, und sensible Daten werden geschwärzt. |
Das Ergebnis steht in jeder Antwort
Jede Gateway-Antwort trägt das Ergebnis jedes Prüfpunkts in einem Header. Jeder Integritäts-Checkpoint ist zudem signiert und verkettet, wie unten unter Signierte Aufzeichnung beschrieben.
x-mnemom-verdict: front=pass; autonomy=pass; integrity=pass; back=passWie die Regeln aktuell bleiben
- Erkennungsregeln erreichen jedes Gateway als mit Ed25519 signierter Regelsatz. Jedes Gateway prüft die Signatur, bevor es die Regeln verwendet, und übernimmt Änderungen innerhalb weniger Minuten.
- Wir testen die Prüfung laufend mit einem automatisierten, adaptiven Angreifer, der in einer isolierten Umgebung gegen Sandbox-Agenten läuft, niemals gegen Agenten von Kunden.
- Neue Regeln werden geprüft, bevor sie in die Produktion gelangen.
OWASP Top 10 für agentische Anwendungen
Wo wir die agentischen Risiken abdecken und wo nicht.
| Risiko | Abdeckung | Was Mnemom tut |
|---|---|---|
| ASI01 Agent goal hijackTeilweise | Eingehende Nachrichten und Tool-Ergebnisse werden auf direkte und indirekte Injection geprüft, und das Risiko wird über die Runden einer Sitzung verfolgt. | |
| ASI02 Tool misuseTeilweise | Tools, die die Card verbietet, können abgelehnt und Aufrufe auf geschützte Assets oder Operationen zurückgehalten werden. Nicht jeder unsichere Tool-Aufruf wird erkannt. | |
| ASI03 Identity and privilege abuseTeilweise | Tool-Berechtigungen kommen aus der Card des Agenten, und eingehende Behauptungen von System- oder Admin-Autorität werden markiert. | |
| ASI04 Supply chainNicht abgedeckt | Wir protokollieren Anbieter, Modell und SDK-Version hinter jeder geprüften Anfrage sowie optional einen Lockfile-Hash. Kompromittierte Abhängigkeiten erkennen wir nicht. | |
| ASI05 Unexpected code executionNicht abgedeckt | Führen Sie generierten Code in Ihrer Anwendung in einer Sandbox aus. | |
| ASI06 Memory and context poisoningBegrenzt | Vergiftete Inhalte, die als Tool-Ergebnis zurückkommen, werden geprüft. Eine Anbindung an Speicher-Stores gibt es nicht. | |
| ASI07 Insecure inter-agent communicationTeilweise | Nachrichten anderer Agenten werden wie jede andere Eingabe geprüft, und falsche Autoritätsbehauptungen werden markiert. Nachrichten zwischen Agenten werden nicht authentifiziert. | |
| ASI08 Cascading failuresNicht abgedeckt | Lösen Sie dies in der Architektur Ihrer Anwendung. | |
| ASI09 Human-agent trust exploitationAbgedeckt | Druck durch Dringlichkeit, Autorität, Geheimhaltung und geänderte Zahlungsdaten in eingehenden Nachrichten wird markiert. | |
| ASI10 Rogue agentsTeilweise | Das Verhalten wird gegen die Alignment Card des Agenten geprüft. Admins können einen Agenten pausieren oder stoppen, und automatisches Pausieren bei wiederholten Verstößen lässt sich einschalten. |
Quelle: OWASP GenAI Security Project, genai.owasp.org.
NIST AI Risk Management Framework
Kontrollen und Aufzeichnungen für jede Funktion.
Das AI RMF ist ein freiwilliges Framework, das Ihre Organisation umsetzt. Es ist keine Zertifizierung. Mnemom liefert Laufzeitkontrollen und Aufzeichnungen, die jede Funktion nutzen kann.
| Funktion | Was Mnemom liefert |
|---|---|
| Govern | Eine maschinenlesbare Richtlinie pro Agent (die Alignment Card), Einstellungen auf Organisations-, Team- und Agentenebene und ein Protokoll, wer was geändert hat. |
| Map | Der erklärte Zweck und die Grenzen jedes Agenten sowie die OWASP-Zuordnung oben. |
| Measure | Ein Ergebnis an jedem Prüfpunkt in jeder Runde und signierte Integritäts-Checkpoints, die Sie prüfen können. |
| Manage | Die Modi observe, nudge und enforce sowie Pause- und Stopp-Steuerung für jeden Agenten. |
Plattform
So schützen wir die Plattform.
Signierter Nachweis
- Jeder Integritäts-Checkpoint wird mit Ed25519 signiert und innerhalb seiner Agenten-Sitzung in eine SHA-256-Hash-Kette eingebunden. Ein entfernter oder umsortierter Checkpoint ist so erkennbar.
- Jedes Checkpoint-Zertifikat enthält einen Merkle-Inklusionsnachweis. Jeder kann ein Zertifikat über unseren öffentlichen Verify-Endpunkt prüfen oder die Signatur mit einer beliebigen Standard-Ed25519-Bibliothek verifizieren.
- Unser öffentlicher Signaturschlüssel ist unter api.mnemom.ai/v1/keys veröffentlicht.
- Attestierungen von Agent Cards werden in einem öffentlichen, nur anhängbaren Log nach dem Vorbild von Certificate Transparency (RFC 6962) erfasst. Sein signierter Root und die Konsistenznachweise sind öffentlich.
- Webhooks werden mit HMAC-SHA256 über einen Zeitstempel und den Body signiert.
- Signaturschlüssel liegen in Azure Key Vault und werden über Managed Identity in unsere Dienste geladen.
Infrastruktur
- Jede Umgebung läuft als eigenständige Zelle mit eigenem Netzwerk, eigener Datenbank, eigenem Cache, Key Vault, Speicher und Identitätsdienst. Zellen teilen sich keine Netzwerke.
- Datenbanken, Cache, Key Vault und Speicher sind nicht aus dem öffentlichen Internet erreichbar, sondern nur über private Endpunkte.
- Sämtlicher öffentlicher Verkehr erreicht uns über Cloudflare. Produktions-Origins akzeptieren nur Verbindungen von Cloudflare.
- Interne Dienste haben keinen öffentlichen Endpunkt.
- Die Produktionsdatenbank hält einen Standby in einer zweiten Verfügbarkeitszone vor. Backups werden 30 Tage aufbewahrt und in eine zweite Region kopiert.
Verschlüsselung
- Öffentliche Endpunkte akzeptieren nur TLS 1.2 und TLS 1.3. Datenbanken, Cache und Speicher akzeptieren nur verschlüsselte Verbindungen.
- Alle Kundendaten werden im Ruhezustand verschlüsselt.
- Webhook-Signaturgeheimnisse und gespeicherte Schlüssel von Modellanbietern verschlüsselt unsere Anwendung zusätzlich mit AES-256-GCM.
Zugriff
- Organisationen haben fünf Rollen: Owner, Admin, Member, Viewer und Auditor. Die API prüft bei jeder Organisationsanfrage Mitgliedschaft und Rolle des Aufrufers.
- Änderungen über die API werden mit dem Urheber protokolliert. Owner, Admins und Auditoren können das Protokoll ihrer Organisation einsehen.
Anmeldung
- Sie melden sich immer auf einer Mnemom-Seite an. Der Identitätsdienst läuft innerhalb jeder Zelle; seine eigenen Login- und Admin-Seiten sind aus dem Internet nicht erreichbar.
- Passkeys (wir speichern nur den öffentlichen Schlüssel) und MFA per Authenticator-App. MFA abschalten, einen Passkey entfernen oder andere Sitzungen abmelden erfordert eine erneute Prüfung des zweiten Faktors.
- Browser-Sitzungen nutzen ein verschlüsseltes HttpOnly- und Secure-Cookie, das nach 7 Tagen Inaktivität und spätestens nach 30 Tagen abläuft. Wir benachrichtigen Sie per E-Mail, wenn sich Ihr Konto auf einem neuen Gerät anmeldet.
- API-Schlüssel werden einmal angezeigt und nur als SHA-256-Hash gespeichert. Schlüssel haben Scopes und lassen sich jederzeit widerrufen oder rotieren.
- Die Anmeldung von CLI und Agenten nutzt OAuth mit PKCE oder den Device-Code-Flow.
So liefern wir aus
- Produktionsänderungen laufen über eine einzige Deployment-Pipeline. Ein Release erreicht die Produktion erst nach Freigabe durch einen namentlich benannten Engineer oder, bei als risikoarm eingestuften Änderungen, nach einem erfolgreichen automatisierten Canary.
- Hauptbranches erfordern automatisierte Prüfungen, darunter Secret-Scanning.
- Unsere GitHub-Organisation verlangt Zwei-Faktor-Authentifizierung. Zugriff auf Produktions-Cloud-Ressourcen haben nur wenige namentlich benannte Personen und eng berechtigte Automatisierungsidentitäten. Interne Tools liegen hinter Cloudflare Access.
Compliance
Compliance-ready für SOC 2 Typ II, DSGVO und HIPAA. Unabhängiges Audit läuft. Sicherheitsfragebögen und Kontrollnachweise stellen wir unter NDA bereit.
EU AI Act: Artikel 10, 12 und Anhang IV sind dem signierten Nachweis zugeordnet. Ein technisches Mapping, keine Zertifizierung.
Zur Trust-SeiteSchwachstelle melden
Schreiben Sie an [email protected]. Unsere Disclosure-Richtlinie steht in unserer security.txt und auf der Trust-Seite.
[email protected]Schnell vorankommen. Stabil bleiben.
Wissen, was Ihre Agenten wirklich tun, bevor der Vorstand fragt.
Zwei Befehle zur Installation. Ein signiertes Protokoll ab der ersten Entscheidung.
