Skip to content
KitploitKITPLOIT
ToolsExploitsBlog
Log in
Einreichen
ToolsExploitsBlog
Einreichen

Hacking-, PenTest- und Cybersicherheits-Tools für Ihr Sicherheitsarsenal!

Kitploit ist ein Verzeichnis von Hacking-, Cybersicherheits- und Pentesting-Tools. Entdecken Sie die neuesten Projekt-Updates, um Schwachstellen zu finden, Systeme zu analysieren, Tests zu automatisieren und Ihre Sicherheit zu stärken.

FeedsKontaktDatenschutz© 2026 Kitploit

Tool-Verzeichnis

Kategorien

Alle Kategorien anzeigen
Loading categories
aegis-latent-core — Selbstgehostetes Evidenz-Gateway für KI-Systeme: Fail-Closed-Richtlinie, WAF, Egress-Kontrollen, signierte dauerhafte MMR-Nachweise und Offline-Verifikation über LLM-Anbieter hinweg. | Kitploit
Tools/GitHubGitHub/juanlunaia/aegis-latent-core
KryptographieCloud-SicherheitBedrohungsanalyseAPI-SicherheitKI-SicherheitLog-Analyse
GitHubjuanlunaia/aegis-latent-core

aegis-latent-core

Selbstgehostetes Evidenz-Gateway für KI-Systeme: Fail-Closed-Richtlinie, WAF, Egress-Kontrollen, signierte dauerhafte MMR-Nachweise und Offline-Verifikation über LLM-Anbieter hinweg.

Repository anzeigen
184102vor 5 TagenNoch nicht geprüft

Beliebteste

Alle anzeigen →

Entdecken Sie die meistgenutzten Tools unserer Community.

Alle Tools erkunden

Durchsuchen Sie unsere Tool-Sammlung

Alle Tools anzeigen →
Teilen
Webseite

Aegis Latent Core

KI-Governance und kryptografisches Nachweis-Gateway

Aegis Latent Core committet signierte, hash-verknüpfte Nachweise jedes gesteuerten KI-Aufrufs — bevor die Antwort den Aufrufer erreicht — und stellt einen portablen Beweis aus, den ein Dritter verifiziert, ohne dem Gateway, uns oder Ihnen zu vertrauen.

release CI Security coverage License

Jede tragende Aussage in dieser Datei trägt einen Locator und eine ausgewiesene Grenze; die Gates, die diese Disziplin durchsetzen, laufen in CI.

Aktuelles Release: v5.0.1 — das zuletzt veröffentlichte Release (der ausgecheckte Quellcode ist v5.0.2, ein Apache-2.0-Quellcode-Ziel, das nicht veröffentlicht ist), veröffentlicht am 2026-09-24 auf jeder Oberfläche (PyPI aegis-latent-core 5.0.1 folgte am 2026-09-26), am selben Tag zurückgelesen (Release Status §1.0a). Der Sigstore-signierte Tag besteht gitsign verify-tag; das GitHub Release trägt 31 Assets und alle 15 in seiner SHA256SUMS aufgeführten Dateien re-hashen zu ihren Digests; PyPI aegis-latent-sdk 5.0.1 und npm aegis-latent-sdk 5.0.1 sind byte-identisch mit den gleichnamigen Release-Assets; und die GHCR-Gateway- und Dashboard-Images bestehen cosign verify und ihre Build-Provenance-Attestierungen verifizieren, jeweils gegen die exakte veröffentlichende Workflow-Identität. Die Gateway-Distribution aegis-latent-core erreichte PyPI bei 5.0.1 am 2026-09-26 (Run 36224961909 von publish_pypi_gateway.yml, zurückgelesen am 2026-09-29, Release Status §1.0b); pip install aegis-latent-core löst zu 5.0.1 auf, und sein Wheel und sdist stimmen Byte für Byte mit den Release-Assets überein. Die GHCR-Images und die Release-Assets bleiben verfügbar. Das vorherige Release, v5.0.0, wurde am 2026-09-16 auf denselben Oberflächen veröffentlicht (§1.0). Es gibt kein 4.2.0; die Nummer wurde übersprungen.

Erste veröffentlichte Version mit dem Gateway auf PyPI: v4.1.2, zurückgelesen am 2026-09-04 — signierter annotierter Tag, GitHub Release mit 31 Assets, PyPI aegis-latent-core 4.1.2, PyPI aegis-latent-sdk 4.1.2, npm aegis-latent-sdk 4.1.2 und GHCR-Gateway- und Dashboard-Images. 4.1.2 ist die erste Version, die von PyPI als aegis-latent-core installierbar ist; davor kam das Gateway nur aus dem Quellcode oder von GHCR. Die npm-Versionsliste überspringt 4.1.1, dessen Publish-Schritt fehlschlug. Ein v4.1.0-Release-Objekt existiert ebenfalls, wurde aber außerhalb der Pipeline erstellt und trägt keine Assets; ignorieren Sie es. Die beiden 4.1.2-PyPI-Gateway-Artefakte sind byte-verschieden von den gleichnamigen Release-Assets — gleicher Inhalt, anderer Build-Host — daher deckt SHA256SUMS diese Downloads nicht ab; die 5.0.1-PyPI-Gateway-Artefakte stimmen damit überein. Siehe Release Status für Provenance und Readback.


Das Problem

Ihre KI-Entscheidungen werden in einer Datenbank protokolliert, die Ihre Administratoren bearbeiten können. Wenn jemand fragt, was dem Modell vor sechs Monaten gesagt wurde, antworten Sie aus Aufzeichnungen, die die interessierte Partei hätte ändern können.

In einer regulierten Branche ist das kein Papierkram-Problem — es ist ein existenzielles. Der Regulator, das Gericht und der Auditor stellen jeweils dieselbe Frage, und „unsere Logs sind wahrscheinlich in Ordnung" ist keine Antwort, die sie akzeptieren:

  1. Eine Aufzeichnung, die die interessierte Partei hätte ändern können, ist kein Beweis — sie liest sich nur als Beweis, bis jemand mit einem Grund zum Zweifeln eine Frage stellt.
  2. Sie schulden bereits jemandem eine Aufzeichnung, hinter der Sie stehen können — EU AI Act Art. 12, HIPAA-Audit-Kontrollen, die Audit-Trail-Alternative von SEC 17a-4, MiFID II. Das sind Ihre Pflichten; diese Software ist ein Input dafür, niemals eine Erfüllung davon.
  3. Die Lösung muss von jemandem überprüfbar sein, der Ihnen misstraut, sonst ist es dasselbe Problem in besserer Kleidung.

Die Aegis-Lösung

  • Append-only, manipulationserkennende MMR. Jede Aufzeichnung ist ein Blatt in einem Merkle Mountain Range. Ein portabler Inklusionsbeweis (O(log n), keine Zero-Knowledge-Behauptung) lässt einen Dritten eine offengelegte Aufzeichnung gegen eine Wurzel verifizieren, die er unabhängig erhalten hat. verify_integrity() erkennt Manipulation beim Lesen; Manipulation wird erkannt, nicht verhindert — siehe die Grenzen unten.
  • Kryptografische Versiegelung. Jede Aufzeichnung wird in ein Chain-Link gehasht und signiert — standardmäßig HMAC, Ed25519 (RFC 8032) oder ML-DSA-65 (FIPS 204) wo konfiguriert, mit einem HSM-Pfad im Enterprise-Server. Optionales Shredding pro Subjekt (AES-256-GCM-Schlüsselzerstörung) löscht Klartext aus der Sicht eines Ciphertext-Inhabers, ohne die MMR-Wurzel oder zuvor ausgestellte Beweise zu ändern.
  • Zero-Trust-Verifikation. Beweise verifizieren offline: ein 313-zeiliger Pure-Python-Verifier, ein TypeScript-Zwilling mit derselben Semantik und null Netzwerkaufrufe. Kein Vertrauen in das Gateway, den Anbieter oder den Operator, der die Aufzeichnung offenlegt — nur in eine Wurzel, die Sie über einen Kanal erhalten haben, den der Offenlegende nicht kontrolliert.
  • Regulatorische Inputs. MiFID II Art. 16(6)/16(7) und MiFIR Art. 25(1) Record-Keeping-Rahmen (dauerhafte, innerhalb des Prozesses geordnete Aufzeichnungen; keine Orders — RTS 24 — und keine Clock-Traceability — RTS 25); EU AI Act Art. 12 Logging-Inputs (Commit-before-Response, Manipulationserkennung, verifizierbare Inklusion); HIPAA-Safe-Harbor-artige Muster-Redaktion; ISO/IEC 27037-artige Extrakte. Dies sind technische Inputs, keine Compliance. Es existiert keine Zertifizierung, keine ist in Arbeit, und ob eine Pflicht erfüllt ist, ist eine Feststellung für Sie und Ihren Prüfer (CLM-039 ist LEGAL-REVIEW-REQUIRED).

→ Beweisen Sie es selbst — zwölf Zeilen Python, kein Aufruf unserer Server, drei Fälle, von denen zwei fehlschlagen müssen.

pip install aegis-latent-sdk aegis-latent-core   # verifier + gateway, both 5.0.1 on PyPI
python tools/sales/prove_it/prove_it.py --demo   # accepts one record, rejects two forgeries
python -m examples.demo                          # gateway + mock upstream, tamper detected

Beide Befehle laufen aus einem Checkout dieses Repositorys; was jeder zeigt und nicht zeigt.


Architektur auf einen Blick

Tool herunterladen