Ausgeliefert
Was wir ausgeliefert haben.
Ein ehrliches Log dessen, was live ging, wann und warum es relevant ist. Kein Marketing-Glanz — nur die Änderungen, die Posture, die sie freischalten, und die Belege.
AGENTS.md-Abdeckung auf sechs öffentliche Repos aktualisiert.
Verpflichtung Nr. 9 (jedes öffentliche Mnemom-Repo enthält eine AGENTS.md) umfasst jetzt sechs kanonische öffentliche Repos: aap, aip, aip-otel-exporter, mnemom-types, reputation-check und docs. mnemom-platform wurde im Juni 2026 bewusst privat gestellt; es enthält weiterhin eine AGENTS.md, aber nur öffentliche Repos sind extern überprüfbar. Manifest-Version 1.13.0.
- Der nächtliche Watchdog prüft AGENTS.md jetzt in den sechs kanonischen öffentlichen Repos; private Repos (einschließlich mnemom-platform) behalten AGENTS.md für interne Team-Agenten, liegen aber außerhalb der externen Verifikation.
Verbinden Sie sich mit Mnemom über das Model Context Protocol.
Zwei öffentliche MCP-Server sind jetzt live. Die Steuerungsebene unter api.mnemom.ai/mcp stellt die Vertrauensebenen-API als Tool-Satz bereit, der die mnemom-CLI abbildet — rufen Sie zuerst get_started auf (ohne Authentifizierung, ohne Argumente) für die Übersicht; ein schreibgeschützter Dokumentations-Suchserver unter docs.mnemom.ai/mcp beantwortet Fragen anhand der Dokumentation und der OpenAPI-Spezifikation. Richten Sie einen beliebigen MCP-Client auf einen der beiden Endpunkte — kein Scraping erforderlich.
- <code>api.mnemom.ai/mcp</code> — MCP-Server der Steuerungsebene (streamable-HTTP) mit Tools für Trust Ratings, Alignment- & Protection-Cards, Governance, Postures, Teams, Webhooks und API-Schlüssel. <code>tools/list</code> ist öffentlich; die Tool-Ausführung authentifiziert sich genau wie die REST-API (Bearer-JWT oder <code>X-Mnemom-Api-Key</code>).
- <code>docs.mnemom.ai/mcp</code> — schreibgeschützte Dokumentationssuche. Die Steuerungsebene veröffentlicht eine auffindbare Karte unter <code>/.well-known/mcp/server-card.json</code>, und kopierfertige Client-Konfigurationen finden sich auf <code>/for-agents</code> und in der Dokumentation.
Agenten können durchgängig herausfinden, wie sie sich registrieren und authentifizieren.
Die Protected-Resource-Metadaten der Mnemom-API verweisen jetzt auf erstanbieterseitige Authorization-Server-Metadaten, die ein agent_auth-Registrierungsprofil enthalten — so kann ein Agent die API finden, erfahren, dass die Token-Ausgabe an Supabase delegiert ist, und dem echten register → claim-Ablauf folgen, ohne Fließtext-Dokumentation zu lesen.
- <code>/.well-known/oauth-protected-resource</code> (RFC 9728) führt jetzt Mnemoms erstanbieterseitige Authorization-Server-Metadaten unter www.mnemom.ai auf, neben dem vorgelagerten Supabase-GoTrue-Issuer.
- <code>/.well-known/oauth-authorization-server</code> (RFC 8414) deklariert <code>issuer: https://www.mnemom.ai</code>, delegiert die Token-Ausgabe an Supabase und ergänzt ein <code>agent_auth</code>-Profil, das <code>register_uri</code> / <code>claim_uri</code> / <code>rekey_uri</code> auf die echten <code>/v1/agents</code>-Endpunkte abbildet — wir geben nach wie vor keine eigenen OAuth-Token aus.
Standardflächen zur Agenten-Erkennung sind veröffentlicht und auflösbar.
Ein Agent ohne Vorwissen kann jetzt die Mnemom-API finden, erfahren, wie er sich authentifiziert, und sehen, welche Skills er aufrufen kann — vollständig anhand von Standarddateien unter www.mnemom.ai. Jede URL löst auf etwas Echtes auf; nichts ist bloß angestrebt.
- <code>/.well-known/api-catalog</code> (RFC 9727) verweist auf die live betriebene OpenAPI-3.1-Spezifikation; <code>/.well-known/oauth-protected-resource</code> (RFC 9728) benennt die Mnemom-API als geschützte Ressource, und <code>/.well-known/oauth-authorization-server</code> (RFC 8414) delegiert die Token-Ausgabe an unseren vorgelagerten IdP (Supabase GoTrue), während es ein <code>agent_auth</code>-Profil für die Registrierung von Mnemom-Agenten mitführt. Wir geben keine eigenen OAuth-Zugriffstoken aus — klar dargelegt in <code>/auth.md</code>.
- <code>/.well-known/agent-skills/*</code> listet aufrufbare Skills, die ausschließlich auf echten öffentlichen Endpunkten beruhen, und <code>/.well-known/agent-card.json</code> liefert eine Dienstkarte im A2A-Stil; Content-Signal-Direktiven in robots.txt deklarieren unsere Such- und KI-Haltung.
- Die Zusage <code>api-auth-discovery</code> wurde dem Agent-Readiness-Manifest hinzugefügt und wird nächtlich gegen die Produktion verifiziert.
AEGIS L5: öffentliche Advisories und STIX-2.1-IoC-Feed sind live.
Die Transparenzfläche des Protection Network ist offen. /trust/advisories enthält signierte Post-Incident-Berichte; /v1/trust/iocs liefert ein STIX-2.1-Indikatorbündel. Bei GA leer, so gewollt — das System sagt die Wahrheit.
- <code>/trust/advisories</code> ist live mit seinem ersten synthetischen Post-mortem, gemäß dem calm-at-GA contract klar als synthetisch gekennzeichnet.
- /v1/trust/iocs gibt ein STIX-2.1-Bündel zurück, authentifiziert und ratenbegrenzt, bereit für Threat-Intel-Pipelines (curl + JSON-LD).
- Die neuen Webhook-Events <code>advisory.published</code> und <code>ioc.added</code> kommen zum Katalog hinzu, sodass Threat-Intel-Pipelines reagieren können, sobald das Protection Network etwas veröffentlicht.
Das Threat thermometer liest jetzt live den achsenweisen Zustand des Protection Network.
Kunden sehen jetzt das tenant-übergreifende Bedrohungsbild unter <code>/dashboard/threats</code>: achsenweiser Zustand über Substrat, Vertikale, Muster und Quelle, alle 30 Sekunden aktualisiert. Calm at GA, by design.
- <code>GET /v1/network/threat-state</code> gibt eine achsenweise Aggregation des live betriebenen Protection-Network-Bilds zurück, bereit zum Abfragen aus Ihren Dashboards.
- Eine Dashboard-Seite unter <code>/dashboard/threats</code> wird mit vier achsenweisen Karten und einer Gesamtkarte ausgeliefert.
- Ein neues Event <code>network.threat_level.changed</code> erlaubt es Ihnen, Übergänge der Bedrohungsstufe direkt mit Ihrer eigenen Alarmierung zu verdrahten.
L1-Cross-Tenant-Aggregator: fortlaufende Kampagnenzustands-Statistiken über Kunden hinweg.
Fortlaufende achsenweise Statistiken korrelieren jetzt Signale über Arena-, Sideband- und Integrity-Checkpoint-Traffic hinweg — die Cross-Tenant-Korrelations-Engine, die Kampagnen sieht, die kein einzelner Kunde sehen könnte.
- Die Korrelations-Engine verknüpft achsenweise Fingerprints über Integrity-, Arena- und Sideband-Signale, um einen Kampagnenzustand aufzubauen, den kein einzelner Tenant sehen kann.
- Zustandsmaschine pro Bucket mit 6-h-Fenster-Hysterese beim Verlassen; Zustände über vier konkrete campaign_state-Cells an cells.ts angebunden (safe-house-hardening#246).
- Die Engine aktualisiert sich kontinuierlich und hält das Cross-Tenant-Bild über das gesamte Protection Network aktuell.
Safe House Webhooks pro Auswertung (sh.*) sind durchgängig verdrahtet.
Fünf Safe House Front-door-Events kommen zum AEGIS-Katalog hinzu, mit Steuerung des Zustellmodus pro Organisation — Grundvoraussetzung für die SOC/SIEM-Integration. Bringt den AEGIS-GA-Webhook-Katalog von 10 auf 15 vollständig verdrahtete Events.
- Neue Webhook-Events <code>sh.evaluation.warn</code> / <code>quarantine</code> / <code>block</code> feuern an jedem Verdict-Punkt, dazu <code>sh.canary.triggered</code>, wenn ein Canary auslöst, und <code>sh.session.escalated</code>, wenn eine Sitzung eine Risikostufe überschreitet.
- Zustellmodi pro Organisation (vollständig, 10 % gesampelt oder nur Zusammenfassung) halten Organisationen mit hohem Traffic unter Kontrolle, mit HMAC-signierter Zustellung bei jedem Event.
- 13 sh_emission-Cells im Harness pinnen jeden Auslösepfad Checkpoint × Modus fest (safe-house-hardening#247).
Kontinuierliche adversariale Arena: 15 kanonische Personas, Mutation-Phase-Modell.
Die adversariale Arena deckt jetzt jeden kanonischen Bedrohungstyp über alle vier Safe House Checkpoints ab. Funde, die durchrutschen, fließen direkt in die Managed-Rules-Pipeline.
- Alle 15 Personas decken jetzt jeden kanonischen Bedrohungstyp über die vier Safe House Checkpoints ab, einschließlich eines Supply-Chain-Archetyps bei inside.integrity.
- Liefert ein Mutation-Phase-Gating-Modell pro Bucket (Hysterese 0,90↔0,95), das die Angriffsevolution nach Erkennungsrate steuern wird.
- Angriffe, die die Erkennung überwinden, werden automatisch als Managed-Rules-Kandidaten über einen isolierten, attributionsgestempelten Pfad erfasst — kein Mensch in der Schleife, der einen Fund verlieren könnte.
Kunden-Falsch-negativ- und Falsch-positiv-Meldungen speisen die Managed-Rules-Pipeline.
Kundensignal ist jetzt eine erstklassige Quelle. Meldungen fließen über einen authentifizierten Endpunkt, einen CLI-Befehl und eine Bestätigungs-E-Mail-Pipeline, die in fünf Sprachen ausgeliefert wird — und speisen dieselbe Kandidaten-Prüf-Queue wie die Arena und der Cross-Tenant-Aggregator.
- Der Melde-Endpunkt ist live, mit einer <code>recipe.candidate.created</code>-Webhook-Verteilung an Ihr Konto, sobald eine Meldung zu einem Regelkandidaten wird.
- Die Befehle <code>mnemom recipes report-fn</code> und <code>report-fp</code> sind in der @mnemom/mnemom-CLI verfügbar.
- Kunden-FN-Bestätigungs-E-Mail gerendert in en/fr/de/it/es über die Track-D-Template-Pipeline.
Drei Prüfer-Modi — mit einer strukturellen Dual-Control-Invariante auf Tier 1-2.
Plattform-Administratoren können den Prüfer-Modus zwischen manuell, Auto-Freigabe vertrauenswürdiger Quellen und Auto-Freigabe hoher Konfidenz umschalten. Die schützende Invariante ist strukturell, nicht prozedural: Tier-1- und Tier-2-Regeln können niemals ohne menschliche Dual-Control automatisch befördert werden, unabhängig vom Modus.
- Prüfer-Modus und Schwellenwert bleiben plattformweit bestehen und werden über <code>/v1/admin/settings/reviewer-mode</code> gelesen und geschrieben, wobei jede Änderung in die Audit-Spur geschrieben wird.
- Das Administrator-Steuerelement für den Prüfer-Modus wird mit einem Bestätigungsschritt und vollständiger Audit-Zuordnung bei jeder Änderung ausgeliefert.
- Drei konkrete reviewer_mode-Cells verankern die Invariante: trusted-sources befördert Tier-3, high-confidence fügt EINE Freigabe auf Tier-1 ein, befördert aber NICHT, manual blockiert jede Auto-Freigabe (safe-house-hardening#245).
Administrator-Prüf-Queue mit Append-only-Audit-Kette.
Plattform-Administratoren triagieren jetzt Managed-Rules-Kandidaten aus einer dedizierten Queue: genehmigen, ablehnen, Änderungen erforderlich oder befördern. Jede Aktion landet als reiner Service-Rollen-INSERT auf einer Append-only-Kette — die Audit-Fläche, auf die sich CISOs und Regulierungsbehörden verlassen können.
- Jede Prüfaktion landet auf einer Append-only-Kette, verwurzelt bei der Kandidatenerstellung und laufend bis zur Beförderung oder Außerdienststellung — die Audit-Fläche, auf die sich CISOs und Regulierungsbehörden verlassen können.
- Eine Administrator-Prüf-Queue-Oberfläche wird mit vollständigen Regeldetails und Telemetrie ausgeliefert.
- Jeder Zustandsübergang sendet ein Governance-Signal, und keine Regel kann ohne Dual-Control-Freigabe aktiv werden — eine Zwei-Personen-Genehmigung, die von der Plattform durchgesetzt wird, nicht von der Richtlinie.
Ed25519-signierte Managed Rules mit KV+R2-Doppelschreibung und 24-h-Observe-Soak.
Eine Recipe zu einer Managed Rule zu befördern ist jetzt ein kryptografisch signiertes Ereignis. Jede Regel ist Ed25519-signiert, wird fail-closed ausgeliefert und durch einen 24-stündigen Observe-Soak geleitet, bevor sie durchgesetzt wird.
- Die Beförderung signiert jede Regel kryptografisch; Gateways verifizieren die Signatur und liefern über einen mehrstufigen, fail-closed Lesepfad mit einem Propagationsziel von unter 30 s P95.
- Das FP-Rate-Monitoring zieht Recipes zurück, die den Schwellenwert überschreiten — im aktuellen Release-Zyklus durch einen Operator bestätigt, in CLPI Phase 2 automatisch.
- Unterstützt einen nächtlichen Sweep, um Regeln ohne jeglichen Treffer nach 90 Tagen zurückzuziehen, sodass der aktive Regelsatz schlank bleibt.
Substrate Fingerprinting: jede Auswertung trägt jetzt die L0-Axis-Identity.
Substrate Fingerprinting ist live. Jeder Integrity Checkpoint, jeder Arena-Versuch und jede Sideband-Analyse wird jetzt mit Substrat-, Vertikal-, Muster- und Quellen-Fingerprints gestempelt — der Cross-Tenant-Korrelationsschlüssel, der Verhaltensabweichungen bei jedem Kunden auf demselben Substrat erkennt.
- Jede Auswertung wird jetzt zum Schreibzeitpunkt mit ihrem vierachsigen Substrate Fingerprint gestempelt — in Produktion ausgerollt.
- Das zugrunde liegende Datenmodell des Protection Network steht, mit Zeilenebenen-Isolation, die ab dem ersten Schreibvorgang durchgesetzt wird.
- Regeln setzen sich zusammen wie Cards — Platform → Org → Team → Agent, die strengste gewinnt.
Safe-House-Detektoren über Prompt-Injection- und PII-Leak-Klassen hinweg nachgezogen.
Die front-door- und back-door-Detektoren haben einen Kalibrierungslauf erhalten. Weniger False Positives bei harmlosen Tool-Calls, schärfere Block-Rate bei neuartigen Injection-Mustern — ohne dass wir mehr Daten erheben.
- Prompt-Injection-Detektoren wurden auf einem frischen adversarialen Korpus neu trainiert; 12 % weniger False Positives.
- Das back-door-Screening erkennt jetzt PII-Leaks mit aufgeteilten Tokens (z. B. SSN oder Kartennummern, die über gestreamte Chunks hinweg zerrissen sind).
- Das signierte Verdict-Format enthält jetzt die Detektor-Version, sodass Auditoren den exakt eingesetzten Classifier reproduzieren können.
Passkey- und Hardware-Key-Agent-Identität sind live.
Agenten können ab dem ersten Tag an einen Passkey oder einen hardwaregestützten Key gebunden werden. Ed25519-Signatur bleibt Standard; WebAuthn-gestützte Agent-Identität steht Teams zur Verfügung, die ein unfälschbares Agent-Onboarding wollen.
- WebAuthn-Attestation für Agent-Enrollment unterstützt.
- Rotation der Agent-Identität bricht keine historischen Proof-Chains; alte Keys bleiben verifizierbar.
- Funktioniert für self-hosted Gateway und Managed-Tenants.
Gateway skaliert jetzt automatisch bis zum M0-Headroom — ohne Operator-Änderungen.
Zuverlässigkeitsarbeit unter der Haube. Das Managed Gateway provisioniert elastisch für Lastspitzen bis zur M0-Tier-Decke, ganz ohne Tenant-Config. Self-hosted-Deployments bekommen dieselben Autoscaler-Defaults im Helm-Chart.
- Auto-Scale von 2 auf 10 Replicas bei anhaltender CPU > 70 %.
- Cold-Start-Pfad für das Self-Hosted-Image um 40 % verkürzt.
- Keine Preisänderung — das Scale-up bleibt innerhalb Ihrer Tier-Decke.
Sehen Sie, was die Plattform tatsächlich beweist.
Jede ausgelieferte Änderung stützt eine von zwei Aussagen: was wir beweisen, oder wie wir Ihre Agenten absichern.
