# What we prove

```json
{"@context":"https://schema.org","@type":"WebPage","name":"Was wir beweisen \u2014 Mnemom","description":"Alignment Cards sind die Intent-Spezifikation. Die Proof Chain ist die Execution-Bindung. Ed25519-signiert, Hash-verkettet, modellagnostisch \u2014 die zonen-neutrale Antwort auf \u201ewas genau beweisen?\u201c","url":"https://www.mnemom.ai/de/what-we-prove","inLanguage":"de-DE","dateModified":"2026-06-08","publisher":{"@type":"Organization","@id":"https://www.mnemom.ai#organization","name":"Mnemom","url":"https://www.mnemom.ai"}}
```

```json
{"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://www.mnemom.ai/de"},{"@type":"ListItem","position":2,"name":"Was genau beweisen?","item":"https://www.mnemom.ai/de/what-we-prove"}]}
```

Für regulierte Teams

# Was genau beweisen?

Audit-Logs beweisen, dass ein Agent etwas getan hat. Das reicht nicht, wenn ein einziger Fehltritt 10 Mio. $ kostet und eine Regulierungsbehörde Evidenz verlangt. Mnemom bindet das, was der Agent tun durfte, an das, was er tatsächlich getan hat — kryptografisch, über jedes Modell, bei jedem Call.

[Card-Spec lesen](https://docs.mnemom.ai/concepts/alignment-cards)[Was wir screenen](/de/security)

Intent-Spezifikation

### Alignment Cards

Eine Alignment Card ist ein signierter Vertrag: der Scope, in dem ein Agent operieren darf, strukturiert genug, damit eine Maschine ihn durchsetzt, und klar genug, damit ein CISO ihn unterschreibt.

-   Deklarierter Intent
    
    Was dieser Agent tun darf, in Klartext und in signierter strukturierter Form.
    
-   Erlaubte Tools + Scopes
    
    Genaue callable Surface. Nichts außerhalb der Card ist zur Laufzeit erreichbar.
    
-   Datengrenzen
    
    Was der Agent lesen darf, was er nie schreiben darf und welche Zonen tabu sind.
    
-   Eskalations-Vertrag
    
    Wann der Agent an einen Menschen übergeben muss — und welche Evidenz er mitbringen muss.
    
-   Compliance-Pflichten
    
    EU-AI-Act-Artikelbindungen, HIPAA-Rollen, branchenspezifische Retention-Klauseln.
    
-   Drift-Budget
    
    Wie stark der Agent vom Baseline-Verhalten abweichen darf, bevor AIP auslöst.
    

Execution-Bindung

### Die Proof Chain

Jeder Lauf produziert eine signierte Beweis-Kette. Jedes Glied bezeugt einen eigenen Teil der Agent-Execution, ist zurück an den Card-Hash gebunden und mit Merkle-Inclusion-Proofs für Drittvalidierung versehen.

1.  1
    
    Card-Hash
    
    Der deklarierte Intent, als Fingerprint und signiert.
    
2.  2
    
    Input-Attestation
    
    Jede Nachricht, jedes Tool-Ergebnis und jedes abgerufene Dokument, das den Agenten erreicht hat.
    
3.  3
    
    Decision Trace
    
    Reasoning-Checkpoints, Policy-Evaluierungen und Front-door-Verdicts — sequenziert und signiert.
    
4.  4
    
    Tool-Call-Ledger
    
    Jede Tool-Invocation, Argumente und Response — an den erlaubten Scope der Card gebunden.
    
5.  5
    
    Output-Zertifikat
    
    Die finale Agent-Antwort, back-door-gescreent, Ed25519-signiert, an den Merkle-Baum des Laufs gebunden.
    

## Card rein. Beweis raus.

Die Card ist die Frage, die die Regulierungsbehörde stellt. Der Beweis ist die Antwort, die Ihr Agent bereits produziert hat — signiert, mit Zeitstempel, unabhängig verifizierbar.

Schritt 1

Card-Hash

Schritt 2

Input-Attestation

Schritt 3

Decision Trace

Schritt 4

Tool-Call-Ledger

Schritt 5

Output-Zertifikat

Jedes Glied Ed25519-signiert · an den Merkle-Baum mit Inclusion-Proofs gebunden · als Evidenz für Regulierer, Auditoren und Underwriter exportierbar.

## Vier Beweise, nach denen Regulierer wirklich fragen.

„Wir haben es geloggt“ ist kein Beweis. Diese schon.

### Beweisen Sie, dass der Agent getan hat, was die Card deklarierte.

Jede Response ist kryptografisch an den Card-Hash gebunden. Wenn die Execution vom Intent abweicht, lässt sich der Beweis nicht verifizieren.

### Beweisen Sie, dass kein unautorisiertes Tool aufgerufen wurde.

Jeder Tool-Call-Versuch des Agenten wird gegen den deklarierten Scope der Alignment Card aufgezeichnet. Calls außerhalb des Scopes erzeugen eine Boundary-Violation im signierten Trace.

### Beweisen Sie, dass keine regulierten Daten abgeflossen sind.

Back-door-Screening prüft jeden Output gegen PII-/PHI-/Secrets-Muster; das Verdict wird neben dem Output signiert. Ein nicht redigierter Leak kann kein gültiges Zertifikat produzieren.

### Beweisen Sie, dass der Agent nicht durch Prompt Injection zur Compliance bewegt wurde.

Front-door-Verdicts zu jeder eingehenden Nachricht sind Teil des Decision Trace. Eine Injection, der der Agent gefolgt ist, ist in der Kette sichtbar; eine, die er geblockt hat, genauso.

Zonen-neutrale Position

## Warum die Modell-Provider das nicht für Sie beweisen können.

Agent-Trust ist ein Cross-Provider-Problem. Ein Trust-Plane innerhalb eines Frontier-Labs ist strukturell in Interessenkonflikt — und strukturell unvollständig.

### Trust muss Provider übergreifen.

Ein Fortune-500-Unternehmen läuft nicht auf einem Modell. Claude, GPT, Gemini, Open-Weights Llama — alle in Produktion, oft im selben Workflow. Ein Trust-Plane, der von einem Modellanbieter gebaut wird, ist strukturell unfähig, die anderen zu attestieren.

### Incumbents können nicht Schiedsrichter sein.

Modellanbieter haben an jedem Verdict ihr eigenes Interesse. Zonen-neutrale Verifikation — derselbe Evidenz-Standard auf jedes Modell angewendet, von einer Partei ohne eigenes Modell — ist die einzige Position, die eine Regulierungsbehörde anerkennt.

### Cards sind portabel; Modelle nicht.

Eine Alignment Card reist mit dem Agenten über Provider, Version und Runtime. Die Proof Chain ist gültig, egal ob das zugrunde liegende Modell morgen, in sechs Monaten oder nie ausgetauscht wird.

Runtime-Enforcement

## Mnemom AEGIS ist die Runtime, die diese kryptografischen Nachweise in Enforcement-Entscheidungen verwandelt.

Die Proof Chain erzeugt signierte Evidenz. AEGIS ist die Schutzschicht, die darauf reagiert — an vier Checkpoints, über jedes Gateway im Netzwerk, mit signierten Managed Rules, die ein mandantenübergreifendes P95-Propagations-SLO-Ziel unter 30 Sekunden tragen.

1

### AAP — Alignment Card

Erklärt die Identität des Agenten, die Autonomiegrenzen und die Audit-Zusagen. Öffentlich unter /.well-known/alignment-card.json.

2

### AIP — IntegrityCheckpoint

Verifiziert das Reasoning des Agenten in flight. Verdict: clear, review-needed oder boundary-violation, mit SHA-256-gehashter Thinking-Block-Evidenz.

3

### CLPI — Governance + Beleg

Steuert den Card-Lebenszyklus über fünf Phasen und verankert Trust Ratings auf Base L2 für unabhängige Verifikation.

4

### Mnemom AEGIS — Evaluationskette

Prüft jede Transaktion an vier Checkpoints × vier Modes; signiert die mandantenübergreifenden Managed Rules, die auf dem integrierten Bild agieren. Die Runtime, das Netzwerk und der Beleg.

Ehrliche Konstruktion: AAP erklärt es. AIP verifiziert es in flight. CLPI steuert seinen Lebenszyklus und verankert die Evidenz on-chain. AEGIS signiert die mandantenübergreifenden Abwehrmechanismen, die darauf agieren.

[Learning Network ansehen](/de/learning-network)

## Die Card ist der Vertrag. Die Chain ist die Quittung.

Verdrahten Sie Ihre Agenten mit Mnemom. Übergeben Sie eine signierte Card. Bekommen Sie eine verifizierbare Antwort zurück, jedes Mal, wenn sie handeln.

[Beim Einstiegstier starten](/de/pricing)[Quickstart](https://docs.mnemom.ai/quickstart)[Flywheel ansehen](/de/learning-network)

---
_Source: /de/what-we-prove/index.html · Generated by build-markdown-mirrors.mjs · For agent-readability commitment #4 see https://www.mnemom.ai/for-agents_
