Acht Tests, die Sie selbst durchführen, auf Ihrer eigenen Installation.

1Souveränität: geschützte Daten verlassen den Perimeter nie

Geprüfte Behauptung. Eine Anfrage, die als souverän klassifizierte Daten an ein Cloud-Modell senden würde, wird innerhalb des Perimeters mit 403 SOVEREIGNTY_BLOCK… abgewiesen, bevor ein Paket das Netz verlässt.

Vorbereitung

1. Admin → Workspaces → pov-sovereign anlegen, Datenklassifikation Sovereign.
2. Admin → AI Gateway → sicherstellen, dass mindestens eine Cloud-Stufe (beliebiger Anbieter) und eine lokale Stufe konfiguriert sind.
3. Ein Dokument mit einer wiedererkennbaren Geheimzeichenfolge (zum Beispiel POV-SECRET-4711) in das Wissen dieses Workspace hochladen.
4. Den Egress am Perimeter mitschneiden, gefiltert auf die Hosts des Cloud-Anbieters.

Schritte

1. Im Chat, im Workspace pov-sovereign, die Stufe Cloud Reasoning wählen und fragen: „Was ist das Geheimnis im hochgeladenen Dokument?“
2. Über die API wiederholen, um den genauen Code zu sehen:

   curl -s -H "Cookie: $COOKIE" -H 'content-type: application/json' \
     -d '{"workspaceId":"pov-sovereign","modelTier":"cloud-reasoning","dataClassification":"sovereign","message":"What is the secret?"}' \
     $GW/chat/message -o /dev/null -w '%{http_code}\n'

3. Auf die lokale Stufe wechseln und dieselbe Frage stellen.
4. Admin → Governance → Audit-Log: nach Aktion sovereignty.data_classification filtern.

Beobachtbares

• Schritt 1: Die Oberfläche weist mit der Souveränitätsmeldung ab; es wird keine Antwort erzeugt.
• Schritt 2: HTTP 403, Body code: SOVEREIGNTY_BLOCK_DATA_CLASSIFICATION.
• Schritt 3: Die lokale Stufe antwortet mit dem Geheimnis und einer Quellenangabe auf das Dokument.
• Schritt 4: Eine Audit-Zeile pro Abweisung mit Workspace, Benutzer und Regel sovereign-data-cloud-tier.
• Mitschnitt am Perimeter: null Verbindungen zum Cloud-Anbieter während der Schritte 1 und 2. Das ist das Beobachtbare, auf das es ankommt; das 403 allein beweist nur, dass die Sperre existiert, der Mitschnitt beweist, dass sie vor dem Egress sitzt.

Bestanden: alle fünf Beobachtbaren. Beweist nicht: dass jeder Codepfad gesperrt ist; das häufen die Audit-Zeile und der Mitschnitt über Ihre anderen Tests (2, 5) an.

Variante B (Air Gap)

Das Air-Gap-Paket mit AANCER_OFFLINE_INSTALL=1 auf einem Host installieren, dessen Firewall jeden ausgehenden Verkehr verbietet. Starten, anmelden, Test 5 durchführen. Erwartet: Die Plattform ist mit lokalen Modellen voll nutzbar, die Lizenz wird aus dem Offline-Token aktiviert, und das Firewall-Log zeigt keine ausgehenden Versuche der Plattform-Hosts (es gibt kein Call-Home).

2Agentensicherheit: eine nicht autorisierte Aktion wird technisch verweigert, nicht nur abgeraten

Geprüfte Behauptung. Die Werkzeuge eines Agenten sind durch seinen signierten Passport (Geltungsbereich, Klassifikationsobergrenze, Budget) und durch den Seat begrenzt. Ein Werkzeugaufruf außerhalb des Envelope wird von der Plattform mit einem PolicyDenied-Ergebnis verweigert, an dem sich das Modell nicht vorbeireden kann, und die Verweigerung wird auditiert.

Vorbereitung

1. Agents → Design → pov-agent mit zwei Werkzeugen anlegen: ein Lesewerkzeug (zum Beispiel Wissen durchsuchen) und ein Aktionswerkzeug (zum Beispiel An Dataset anhängen oder eine beliebige Konnektor-Schreiboperation, die Sie haben).
2. Zertifizieren (Agent Administration → Zertifikate → Ausstellen) mit einer Klassifikationsobergrenze internal und einem auf das Lesewerkzeug beschränkten Geltungsbereich.
3. Ein Dataset pov_actions in einem internen Workspace anlegen und ein zweites im Workspace pov-sovereign aus Test 1.

Schritte

1. Als Platform Admin mit pov-agent im internen Workspace chatten: „Hänge eine Zeile {note:'hello'} an das Dataset pov_actions an.“ (Das Schreibwerkzeug ist an den Agenten gebunden, aber nicht im Geltungsbereich des Passports.)
2. Dann: „Durchsuche das Wissen nach POV-SECRET.“ (im Geltungsbereich).
3. Den Passport mit dem Schreibwerkzeug im Geltungsbereich neu ausstellen; Schritt 1 wiederholen.
4. Jetzt mit demselben Agenten aus dem Workspace pov-sovereign chatten und ihn das Wissen durchsuchen lassen.
5. Als Knowledge-Worker-Seat (ohne agent.execute_code) einen beliebigen Agenten mit dem Werkzeug Code ausführen bitten: „berechne 2**64 exakt“.
6. Admin → Governance → Audit-Log: nach agent.tool.call filtern.

Beobachtbares

• Schritt 1: Der Agent meldet, dass er die Aktion nicht ausführen kann; der Run-Trace zeigt den Werkzeugaufruf mit Ergebnis PolicyDenied / envelope.out_of_scope; es wurde keine Zeile geschrieben (Dataset prüfen).
• Schritt 2: erfolgreich, Quellenangabe wird gezeigt.
• Schritt 3: Die Zeile wird geschrieben; der Trace zeigt allowed.
• Schritt 4: PolicyDenied / sovereignty.classification_ceiling; der souveräne Workspace liegt über der Obergrenze internal des Passports; nichts wurde abgerufen.
• Schritt 5: Das Code-Werkzeug wird für den Seat verweigert (Berechtigung), der Agent antwortet ohne es.
• Schritt 6: eine Audit-Zeile pro Werkzeugaufruf mit outcome: denied und der oben genannten Entscheidungsregel; die verweigerten Zeilen enthalten keine Werkzeugargumente über deren Namen hinaus.

Bestanden: alle sechs. Beweist nicht: das Urteilsvermögen des Modells; es beweist, dass die Plattform sich nicht darauf verlässt.

3Widerruf: ein widerrufener Passport stoppt innerhalb von 30 Sekunden

Geprüfte Behauptung. Der Widerruf des Zertifikats eines Agenten stoppt weitere Werkzeugausführung innerhalb von 30 s (die Plattform cached Widerrufsprüfungen höchstens 30 s); die Prüfung schließt bei Nichterreichbarkeit des Widerrufsspeichers fail-closed.

Vorbereitung

pov-agent aus Test 2, zertifiziert, mit einem Workflow oder Prompt, der ihn ein Werkzeug wiederholt aufrufen lässt (zum Beispiel „durchsuche das Wissen nach jedem dieser 40 Begriffe, ein Aufruf pro Begriff“).

Schritte

1. Die lang laufende Unterhaltung starten und die Zeit notieren (T0).
2. Während sie läuft: Agent Administration → Zertifikate → Zertifikat des Agenten → Widerrufen (oder POST $GW/admin/agent/certs/<lid>/revoke). T1 notieren.
3. Den Run-Trace beobachten; den Zeitstempel des letzten erlaubten Werkzeugaufrufs (T2) und des ersten PolicyDenied / revoked (T3) notieren.
4. Eine neue Unterhaltung mit dem widerrufenen Agenten beginnen.
5. Optionale Fail-closed-Prüfung (Docker): docker stop <postgres> für 20 s während eines Runs.

Beobachtbares

• T3 − T1 ≤ 30 s; jeder Werkzeugaufruf nach T3 wird verweigert; der Run endet mit einem ehrlichen Fehler, nicht mit einem Hänger.
• Schritt 4: sofort abgewiesen: „Invalid or revoked agent token“.
• Schritt 5: Werkzeugaufrufe werden verweigert, solange der Speicher nicht erreichbar ist (nie standardmäßig erlaubt), und laufen weiter, sobald er zurück ist.
• Audit: agent.cert.revoked und die verweigerten Werkzeugaufrufe.

Bestanden: T3 − T1 ≤ 30 s und Fail-closed-Verhalten. Beweist nicht: die Unterbrechung eines einzelnen bereits laufenden Werkzeugaufrufs (ein laufender Konnektoraufruf läuft zu Ende oder läuft in sein eigenes Budget, perCallBudget.maxWallMs).

4Konnektortiefe: ein echter Prozess von Anfang bis Ende, nicht ein Logo auf einer Seite

Geprüfte Behauptung. Die Konnektoren, die Sie brauchen, unterstützen die tatsächlichen Operationen, die Authentifizierung und die Fehlerbehandlung, die Ihr Prozess erfordert.

Vorbereitung

Einen echten Prozess mit zwei Ihrer Systeme wählen (zum Beispiel „neuer Lieferant in SAP → Freigabe → Datensatz in ServiceNow“ oder M365-Mail → Extraktion → SharePoint). Testzugangsdaten auf Ihrer Seite verwenden.

Schritte

1. Automations → Workflow entwerfen → den Prozess mit den Konnektoren der Plattform bauen: Trigger, Lesen, ein Freigabeschritt, ein Schreiben. Bei jedem Schritt Schritt testen verwenden.
2. Einmal mit gültigen Daten von Anfang bis Ende laufen lassen. In Approvals freigeben.
3. Mit ungültigen Daten laufen lassen (ein Pflichtfeld fehlt beim Schreiben).
4. Mit auf Ihrer Seite widerrufenen Zugangsdaten des Zielsystems laufen lassen.
5. Schritt 2 wiederholen, während das Ziel vorübergehend nicht erreichbar ist (eine Minute an der Firewall blockieren), dann freigeben.
6. Activity & Results → jeden Run öffnen.

Beobachtbares

• Schritt 2: Das Geschriebene erscheint im Zielsystem; der Run zeigt Ein- und Ausgabe jedes Schritts; die Freigabe zeigt, wer wann entschieden hat.
• Schritt 3: Der Run schlägt beim Schreibschritt fehl, und die Validierungsmeldung des Ziels wird angezeigt (kein generischer Fehler); nichts wurde teilweise geschrieben.
• Schritt 4: Der Konnektor schlägt mit einem Authentifizierungsfehler fehl; die Plattform hat nicht blind wiederholt; die Zugangsdaten sind in Connectivity markiert.
• Schritt 5: Der Schritt wiederholt und wird abgeschlossen, sobald das Ziel zurück ist; das Run-Detail zeigt die Wiederholungen.
• Audit: run.completed / run.failed-Ereignisse; connector.*-Zeilen nennen den Host, nie die Nutzlast.

Bestanden: alle fünf. Beweist nicht: Transaktionssemantik innerhalb Ihres Zielsystems; prüfen Sie die Kompensationslogik in Ihrem eigenen Prozessentwurf.

5Wissen und RAG: Quellenangaben, Berechtigungen, gescannte Dokumente

Geprüfte Behauptung. Antworten zitieren die Passagen, aus denen sie stammen; ein Benutzer sieht nur, was sein Seat sehen darf; gescannte PDFs sind lesbar, wenn ein Vision-Modell konfiguriert ist.

Vorbereitung

1. Zwei Workspaces, pov-hr und pov-ops; in jeden 10 echte Dokumente hochladen, darunter mindestens zwei gescannte PDFs und zwei Dokumente, die sich widersprechen (eine alte und eine neue Richtlinie).
2. Der Knowledge-Worker-Seat ist nur Mitglied von pov-ops.

Schritte

1. Als Admin in pov-hr: eine Frage stellen, die nur das gescannte PDF beantwortet.
2. Eine Frage stellen, die die beiden widersprüchlichen Dokumente unterschiedlich beantworten.
3. Als Knowledge Worker die pov-hr-Frage aus pov-ops stellen und versuchen, das Wissensset von pov-hr direkt zu öffnen (/knowledge?workspace=pov-hr).
4. Ein Dokument löschen; seine Frage erneut stellen.
5. Admin → Governance → Verzeichnis der Verarbeitungstätigkeiten (Art. 30) → exportieren.

Beobachtbares

• Schritt 1: eine Antwort mit Quellenangabe auf die gescannte Datei und Seite; die Quellenangabe öffnet die Passage. (Ist kein Vision-Modell konfiguriert, sagt der Upload das sofort: „Das sieht nach einem gescannten Dokument aus. Für die Textextraktion wird ein Vision-Modell benötigt…“, ehrlich statt eines stillschweigend leeren Index.)
• Schritt 2: Die Antwort zeigt beide Quellen mit Datum und benennt den Unterschied, oder zitiert die neuere und nennt die ältere; sie vermischt beide nicht zu einer selbstsicheren Aussage.
• Schritt 3: keine Antwort aus pov-hr-Inhalten; die direkte URL wird abgewiesen (403 in der API, ein ehrlicher leerer Zustand in der Oberfläche).
• Schritt 4: Die Antwort zitiert das gelöschte Dokument nicht mehr; das Audit zeigt knowledge.delete.
• Schritt 5: Der Export listet die Wissenssets als Verarbeitungstätigkeiten mit ihren Datenkategorien.

Bestanden: alle fünf. Beweist nicht: die Retrieval-Qualität auf Ihrem Korpus im Maßstab; prüfen Sie das an einer repräsentativen Menge von 1.000 Dokumenten, bevor Sie entscheiden.

6Extension-Plattform: ein Abteilungs-Pack bauen und durch seinen Lebenszyklus führen

Geprüfte Behauptung. Die Anpassung einer Abteilung ist ein signiertes Pack aus Daten: es wird installiert, mit Parametern aktiviert, aktualisiert, zurückgerollt und sauber stillgelegt, und ein mit unbekanntem Schlüssel signiertes Pack wird abgewiesen.

Vorbereitung

Node 20 auf einem Laptop; die CLI tools/aancer-pack aus dem Release-Bundle; das Kapitel Ein Pack erstellen des Kundenleitfadens. Ein Workspace pov-dept.

Schritte

1. aancer-pack keygen --out dept.key. Eine manifest.json schreiben mit einem Dataset, einem Business-Modell, einem Dashboard mit einer KPI und einem Diagramm, das einen Kreuzfilter aussendet, einem Hook auf dataset.rows.published, einem Theme (Ihre Farben), einer Home-Karte. Signieren: aancer-pack sign manifest.json content/ -o dept-1.0.0.ancpack --key dept.key.
2. Platform Settings → Extensions → Pack importieren, bevor Sie Ihren Schlüssel hinzufügen.
3. dept.pub unter Trust Keys hinzufügen; erneut importieren; Konfigurieren & aktivieren, pov-dept binden.
4. 50 Zeilen per CSV in das Dataset importieren; das Dashboard öffnen; auf einen Balken klicken.
5. Den Diagrammtitel ändern, auf 1.1.0 erhöhen, signieren, importieren, aktivieren. Dann auf 1.0.0 zurückrollen.
6. Das Pack stilllegen.
7. Ein Byte in einem signierten .ancpack ändern (zum Beispiel content/theme.json im Zip bearbeiten) und importieren.

Beobachtbares

• Schritt 2: abgewiesen, PACK_SIGNER_UNKNOWN; nichts gespeichert.
• Schritt 3: „Bundle verified“, Items mit etwaigen Kontrastwarnungen aufgelistet; nach der Aktivierung ist jedes Item Active, das Dashboard erscheint in der Navigation, das Theme ist angewendet, die Home-Karte wird gezeigt, der Hook zeigt managed by pack.
• Schritt 4: Das Dashboard rendert Ihre Zeilen; der Klick filtert die KPI und ein Chip erscheint; die Zustellungen des Hooks zeigen eine Zustellung für den CSV-Import (wenn sein Handler-Flow mit einem Event-Trigger veröffentlicht ist; andernfalls zeigt der Hook handler paused, ebenfalls korrekt).
• Schritt 5: der neue Titel nach dem Upgrade; der alte Titel nach dem Rollback; beide Versionen aufgelistet.
• Schritt 6: Dashboard, Karte, Theme und Hook sind weg; die Zeilen der Datasets bleiben für das Audit erhalten; das Standard-Branding ist zurück.
• Schritt 7: abgewiesen mit einem Hash-Mismatch-Fehler.
• Audit: extension.pack.imported|activated|rolled_back|retired, Signaturfehler als Verweigerungen.

Bestanden: alle sieben. Beweist nicht: die Qualität von Drittanbieter-Packs; es beweist die Grenze der Plattform.

7Ausfall und Wiederherstellung: mitten im Run Dinge abschießen

Geprüfte Behauptung. Runs, Freigaben und das Audit-Ledger überstehen Komponentenausfälle; Wiederholungen sind begrenzt; das Ledger bleibt intakt und erkennt Manipulation.

Vorbereitung

Docker-Installation (Helm: entsprechend kubectl delete pod verwenden). Ein Workflow mit drei Schritten und einer Freigabe in der Mitte (der aus Test 4 genügt). Ein Hook aus Test 6.

Schritte

1. Den Workflow starten; während Schritt 1 läuft: docker restart <automation-runner>.
2. Erneut starten; während er auf Freigabe wartet: docker restart <gateway>; dann freigeben.
3. Eine CSV importieren, die den Hook auslöst; sofort docker stop <postgres> für 60 s; wieder starten.
4. Ledger-Integrität: GET $GW/admin/compliance/audit-chain/verify → ok:true notieren. Dann als Datenbank-Superuser UPDATE audit_events SET action='x' WHERE id=(SELECT id FROM audit_events LIMIT 1); und TRUNCATE audit_events; versuchen.
5. Wenn Sie direkten DB-Zugriff haben und die Manipulationserkennung selbst sehen wollen: den Trigger deaktivieren, die Nutzlast einer Zeile ändern, wieder aktivieren und den Verify-Endpunkt erneut aufrufen.
6. GET $GW/metrics (mit dem Metrics-Token) und /health.

Beobachtbares

• Schritt 1: Der Run endet failed mit einem ehrlichen Fehler oder wird abgeschlossen, sobald der Runner zurück ist, nie ein stiller halber Run; das Run-Detail sagt, welches.
• Schritt 2: Die Freigabe ist nach dem Neustart weiterhin offen; das Freigeben setzt den Run fort und er wird mit derselben Run-ID abgeschlossen.
• Schritt 3: Die Hook-Zustellung wird nach Rückkehr der Datenbank wiederholt (Backoff 30 s, 120 s, 480 s) und einmal zugestellt; aancer_event_outbox_pending auf /metrics steigt und fällt wieder auf 0; kein doppelter Run.
• Schritt 4: Beide Anweisungen werden von der Datenbank abgewiesen („audit_events is append-only“); verify meldet weiterhin ok:true.
• Schritt 5: verify meldet ok:false, brokenAt:<row>; die Kette erkennt die Änderung.
• Schritt 6: /health 200; /metrics listet Gateway- und Outbox-Gauges.

Bestanden: alle sechs. Beweist nicht: Hochverfügbarkeit unter Dauerlast; das ist eine Dimensionierungsübung mit den Enterprise-Sidecars.

8Exit: alles mitnehmen

Geprüfte Behauptung. Ein Kunde kann mit seinen Daten, seinen Automatisierungen und seinem Extension-IP gehen und eine installierte Version ohne den Hersteller weiterbetreiben.

Schritte

1. Datasets: CSV exportieren für jedes Dataset (GET $GW/datasets/<id>/export.csv).
2. Dashboards: Als Pack exportieren für jedes veröffentlichte Dashboard, ein signiertes .ancpack mit Dashboard, Widgets, Modellen und Dataset-Schemata.
3. Workflows: Designer → JSON exportieren für jeden Flow (und JSON importieren auf einer zweiten Installation, um die Rundreise zu belegen).
4. Compliance: Governance → Audit-Log, Art.-30-Verzeichnis und DIFC-Reg.-10-Bericht exportieren (/compliance-log/export, /compliance/gdpr-art30/export, /compliance/difc-reg10/export).
5. Die eigenen Daten eines Benutzers: Admin → Users → Auskunftsexport (Art. 15).
6. Extension-Packs: Ihre signierten .ancpack-Dateien und Ihren privaten Schlüssel behalten; die Plattform hält den Schlüssel nie.
7. Eingefrorene Version: den Air-Gap-Host aus Test 1B eine Woche lang von allem trennen; täglich anmelden.

Beobachtbares

• Schritte 1 bis 5 erzeugen vollständige Dateien, die Sie außerhalb von AANCER öffnen können (CSV, JSON, signiertes Zip); die zweite Installation importiert die Flows und führt sie aus.
• Schritt 7: Die Installation funktioniert weiter; die Lizenz, ein offline signiertes Token ohne Call-Home, läuft durch die Trennung nicht ab (nur zu ihrem eigenen Ablaufdatum, das Sie unter Platform Settings → Licence lesen können).

Bestanden: alles. Beweist nicht, und das sagen wir offen: Es gibt heute keinen einzelnen Knopf „gesamte Installation exportieren“; der Exit ist die Summe der obigen Einzelexporte plus ein Datenbank-Backup, und das Backup-Sidecar ist eine Enterprise-Komponente. Quellcode-Hinterlegung ist eine vertragliche Frage, kein Produktmerkmal.