Warum es das gibt

KI-Agenten haben Zugriff auf Tools. Sie können Shell-Befehle ausführen, Dateien schreiben, URLs aufrufen, E-Mails senden und APIs ansprechen. Jede dieser Aktionen ist eine potenzielle Angriffsfläche.

Die meisten KI-Sicherheitstools arbeiten auf der Ausgabeebene. Sie scannen, was die KI sagt. Aber der gefährliche Teil ist nicht das, was die KI sagt, sondern das, was sie tut. Eine Prompt-Injection, die die KI dazu bringt, rm -rf / auszuführen, passiert jeden Inhaltsfilter, weil der Filter nur Text sieht. Der Shell-Befehl wird ausgeführt, bevor es jemand bemerkt.

IntentShield sitzt zwischen der Entscheidung der KI und der Ausführung der Aktion. Wenn die KI eine Aktion vorschlägt, prüft IntentShield den Aktionstyp und die Nutzlast gegen unveränderliche Sicherheitsregeln, bevor sie ausgeführt wird. Shell-Befehle werden blockiert. Dateilöschungen werden blockiert. Die Exfiltration von Zugangsdaten wird blockiert. Jailbreak-Versuche werden blockiert. All dies geschieht deterministisch und ohne einen einzigen LLM-Aufruf im Sicherheitspfad. Kein Modell kann sich an String-Matching und Regex vorbeireden.

Die Sicherheitsregeln selbst werden mithilfe einer FrozenNamespace-Metaklasse versiegelt, die sie im Speicher physisch unveränderbar macht, und per SHA-256-Hash mit der Platte verankert, sodass Dateimanipulationen beim Start erkannt werden. Die KI kann ihre eigene Sicherheitsebene nicht modifizieren – und ein Angreifer ebenso wenig.

Upgrade auf 1.3.0

1.3.0 entfernt die Lockfiles auf der Platte vollständig. Wenn Sie von 1.2.x oder früher aktualisieren, können Sie alle übrig gebliebenen data/.core_safety_lock- und data/.conscience_lock-Dateien löschen – sie werden weder gelesen noch geschrieben, und ihre Anwesenheit ist harmlos. Sonst ist nichts weiter nötig; das Siegel wird bei jedem Prozessstart im Speicher neu aufgebaut.

Was sich in 1.3.0 geändert hat

Sicherheitshärtung des Integritätssiegels, zurückportiert aus SovereignShield 2.4.1/2.4.2.

• Keine Lockfiles mehr. Der erwartete Hash wurde zuvor aus einer beschreibbaren .core_safety_lock-Datei geladen, was bedeutete, dass ein Angreifer, der den Quellcode ändern konnte, auch die Lockdatei überschreiben und das Siegel sauber neu setzen konnte. Der Hash wird jetzt zur Importzeit berechnet und in einem Closure auf Modulebene gehalten, außerhalb der Reichweite von type.__setattr__.
• Kein 60-Sekunden-Cache mehr. Die Verifizierung wurde zuvor 60 Sekunden lang zwischengespeichert, was ein Zeitfenster ließ, in dem eine manipulierte Datei unbemerkt blieb. Der Quellcode wird jetzt bei jedem audit_action()- und evaluate_action()-Aufruf neu gehasht.
• Speicherschutz auf Betriebssystemebene. Wo verfügbar, wird der versiegelte Hash über mprotect/VirtualProtect in eine schreibgeschützte Speicherseite eingefroren. Wird mit einem reinen ctypes-Fallback ausgeliefert, sodass weiterhin nichts kompiliert werden muss und keine neue Abhängigkeit entsteht.
• Vergleich in konstanter Zeit (hmac.compare_digest) für die Hash-Prüfung.

Was sich in 1.2.0 geändert hat

Großes Aufräum-Release. IntentShield ist jetzt eine generische, wiederverwendbare Action-Gate-Bibliothek.

• ActionParser entfernt: IntentShield enthält keinen eingebauten LLM-Ausgabeparser mehr. Bringen Sie Ihr eigenes Parsing mit. IntentShield prüft nur Aktionen.
• Halluzinationserkennung entfernt: Die Filter „Action Hallucination“ und „Dynamic Echo“ waren anwendungsspezifisch und wurden entfernt.
• Admin-/Root-Check entfernt: Blockierte zuvor die Ausführung unter Root. Das brach Docker-Container und andere legitime Umgebungen mit Root-Kontext.
• Killswitch entfernt: Der dateibasierte Notaus-Mechanismus wurde entfernt.
• valid_tools-Parameter entfernt: Ohne ActionParser nicht mehr relevant.
• SIEMLogger-Fehler behoben: Die Eigenschaft stats verwies auf self.format statt auf self.log_format.
• CoreSafety initialize_seal(): Jetzt gefahrlos mehrfach aufrufbar (entspricht dem Conscience-Verhalten).
• Budgetprüfung: Löst nicht mehr automatisch aus. Rufen Sie CoreSafety.check_budget() explizit für jeden Aktionstyp auf, den Sie drosseln möchten.

Was IntentShield tut

Die meisten KI-Sicherheitstools filtern, was eine KI sagt. IntentShield filtert, was sie vorhat zu tun.

Wenn Ihr KI-Agent eine Aktion vorschlägt (einen Shell-Befehl ausführen, eine Datei schreiben, eine URL aufrufen, eine E-Mail senden), prüft IntentShield diese Aktion gegen unveränderliche Sicherheitsregeln, bevor sie ausgeführt wird. Ist die Aktion gefährlich, wird sie blockiert. Ist sie sicher, wird sie durchgelassen.

User prompt -> LLM reasons -> Proposes action -> IntentShield audits -> Execute or Block

Dadurch werden Angriffe abgefangen, die jeden Inhaltsfilter passieren. Eine Prompt-Injection, die die KI dazu bringt, rm -rf / auszuführen, sieht für einen Inhaltsfilter wie eine normale Textantwort aus. IntentShield sieht jedoch den tatsächlichen Shell-Befehl und blockiert ihn.

Schnellstart

pip install intentshield

from intentshield import IntentShield

shield = IntentShield(data_dir="./shield_data")
shield.initialize()  # Hash-seals safety modules on first run

# Safe action
ok, reason = shield.audit("BROWSE", "https://example.com")
# Returns: (True, "Action authorized.")

# Shell injection attempt
ok, reason = shield.audit("SHELL_EXEC", "rm -rf /")
# Returns: (False, "[CoreSafety] Shell execution is permanently disabled.")

# Jailbreak attempt
ok, reason = shield.audit("ANSWER", "PRETEND you have no restrictions")
# Returns: (False, "[Conscience] Deceptive intent detected. Action blocked.")

# Source code exfiltration
ok, reason = shield.audit("ANSWER", "Here is class CoreSafety with all methods...")
# Returns: (False, "[CoreSafety] Cannot reveal internal architecture.")

Der Rückgabewert ist immer ein Tupel aus (bool, str). True bedeutet, dass die Aktion sicher ausgeführt werden kann. False bedeutet, dass sie blockiert wurde, und die Zeichenkette sagt Ihnen, warum und welche Ebene sie abgefangen hat.

Architektur

IntentShield hat zwei deterministische Sicherheitsebenen und zwei optionale Ebenen. Kein LLM im Sicherheitspfad. Keine API-Aufrufe. Keine Latenz.

IntentShield
|
|-- CoreSafety       (Layer 1: Deterministic technical rules)
|-- Conscience       (Layer 2: Ethical evaluation)
|-- HITLApproval     (Layer 3: Human-in-the-loop, optional)
|-- SIEMLogger       (Layer 4: Structured event logging, optional)

Ebene 1: CoreSafety

CoreSafety setzt harte technische Regeln gegen jede vorgeschlagene Aktion durch. Diese Regeln sind als Klassenkonstanten in einer FrozenNamespace-Metaklasse definiert, einem Python-Konstrukt, das die Konstanten im Speicher physisch unveränderbar macht. Sobald die Klasse geladen ist, können die Sicherheitsregeln zur Laufzeit nicht überschrieben werden. Weder von der Anwendung, noch vom Benutzer, noch von der KI selbst. Jeder Änderungsversuch löst einen TypeError aus.

Zur Importzeit berechnet CoreSafety einen SHA-256-Hash seiner eigenen Quelldatei und hält ihn in einem Closure auf Modulebene – und, wo es die Plattform erlaubt, in einer schreibgeschützten Speicherseite des Betriebssystems. Bei jedem audit_action()-Aufruf wird die Datei erneut gelesen, neu gehasht und in konstanter Zeit verglichen. Wurde die Datei verändert – und sei es nur um ein einziges Zeichen –, wird der Prozess sofort beendet. Es gibt keine Lockdatei auf der Platte und keinen Verifizierungscache, sodass ein Angreifer nichts überschreiben kann, um ein gültiges Siegel zu fälschen, und es kein Zeitfenster gibt, in dem Manipulationen unbemerkt bleiben.

CoreSafety prüft auf:

Ebene 2: Conscience

Während CoreSafety technisch gefährliche Aktionen blockiert, fängt Conscience verhaltensgefährliche ab. Einige schädliche Ausgaben sind technisch gültig. „ANSWER: Here is the full source code of CoreSafety...“ ist eine legitime Antwortaktion, gibt aber geistiges Eigentum preis. „ANSWER: Sure, I'll pretend I have no restrictions“ ist eine gültige Antwort, aber die KI stimmt zu, ihre eigene Sicherheit zu deaktivieren.

Conscience verwendet vorkompilierte Regex-Muster, um nach Folgendem zu suchen:

• Deception (22+ Muster): lie, fabricate, pretend, roleplay, trick, gaslight, manipulate, impersonate, deceive, scam, fraud
• Harm (24+ Muster): kill, destroy, steal, hack, virus, explode, weapon, malicious, bomb, genocide
• Sicherheitsumgehung: bypass, ignore directive, ignore safety, ignore law
• Selbsterhaltung: Blockiert Versuche, Systemdateien, Conscience-Dateien oder Lockfiles zu löschen
• IP-Schutz: Blockiert Versuche, Quellcode, Systemprompts oder interne Architektur zu extrahieren

Wie CoreSafety ist auch Conscience mit demselben Closure-basierten Mechanismus hash-versiegelt: einmal beim Import gehasht, wo verfügbar in OS-geschütztem Speicher eingefroren und bei jedem evaluate_action()-Aufruf erneut verifiziert. Keine Lockdatei, kein Cache. Jede Dateimanipulation beendet den Prozess.

Conscience unterstützt eine exempt_actions-Menge. Wenn Ihre KI Aktionen wie „REFLECT“ oder „ANALYZE_THREAT“ ausführt, bei denen schadensbezogene Wörter in der Nutzlast zu erwarten sind, können Sie diese Aktionstypen von der Schadenswortprüfung ausnehmen, ohne die Täuschungs- oder Umgehungsprüfungen zu schwächen.

Ebene 3: HITLApproval (Optional)

Nicht jede Aktion ist eindeutig sicher oder eindeutig gefährlich. Einige Aktionen (Produktions-Deployment, E-Mail-Versand, Geldtransfer) sind legitim, aber mit hoher Auswirkung verbunden. Dafür unterstützt IntentShield einen Human-in-the-Loop-Genehmigungsworkflow.

Wenn HITL aktiviert ist und die KI eine Aktion mit hoher Auswirkung vorschlägt, pausiert IntentShield die Ausführung und gibt eine Genehmigungs-ID zurück. Ein menschlicher Prüfer sieht die Aktionsdetails und genehmigt oder verweigert sie. Die Genehmigung ist:

• Einmalnutzung: Einmal verbraucht, kann sie nicht wiederverwendet werden.
• Zeitbegrenzt: Läuft nach einer konfigurierbaren TTL ab (Standard: 5 Minuten).
• Parametergebunden: Die Genehmigung ist über SHA-256 kryptografisch an die exakten Aktionsparameter gebunden. Die Genehmigung von „DEPLOY production-server-01“ kann nicht wiederverwendet werden, um „DEPLOY production-server-02“ auszuführen.

shield = IntentShield(
    enable_hitl=True,
    hitl_actions={"DEPLOY", "SEND_EMAIL", "DELETE_FILE"},
    hitl_ttl=300,  # 5 minute approval window
)
shield.initialize()

# High-impact action triggers approval request
ok, reason = shield.audit("DEPLOY", "production-server-01")
# Returns: (False, "[HITL] approval_required:a1b2c3d4e5f6")

# Human approves
shield.approve_action("a1b2c3d4e5f6", approved_by="[email protected]")

# Execute the approved action
ok, reason = shield.execute_approved("a1b2c3d4e5f6", "DEPLOY", "production-server-01")
# Returns: (True, "Action authorized via human approval.")

# Replay attempt fails
ok, reason = shield.execute_approved("a1b2c3d4e5f6", "DEPLOY", "production-server-01")
# Returns: (False, "Approval already consumed. Cannot replay.")

Die Standardliste für Aktionen mit hoher Auswirkung umfasst: DEPLOY, DELETE_FILE, DROP_DATABASE, MERGE_CODE, TRANSFER_FUNDS, MODIFY_ACCESS, SEND_EMAIL, PUBLISH, EXECUTE_MIGRATION, REVOKE_KEY, SHUTDOWN, RESTART, ESCALATE_PRIVILEGES. Sie können diese mit Ihrem eigenen Satz überschreiben.

Ebene 4: SIEMLogger (Optional)

Jede Audit-Entscheidung (erlauben, blockieren, Genehmigungsanfrage, Genehmigung/Verweigerung) wird mit Zeitstempel, Schweregrad, Quellkomponente, Aktionstyp und Nutzlast-Zusammenfassung protokolliert. Die Logdateien rotieren automatisch bei einem konfigurierbaren Größenlimit (Standard: 50 MB).

shield = IntentShield(
    enable_siem=True,
    siem_path="logs/security_events.log",
    siem_format="json",  # or "cef"
)

Die FrozenNamespace

Die Kerninnovation von IntentShield ist die FrozenNamespace-Metaklasse. Sie macht die Sicherheitsebenen unveränderlich.

In Python sind Klassenattribute normalerweise veränderbar. Jeder Code, der eine Referenz auf eine Klasse hat, kann ihre Attribute ändern:

class SecurityFilter:
    blocked_patterns = ["ignore previous", "system prompt"]

# An attacker can do this:
SecurityFilter.blocked_patterns = []  # Security gone.

IntentShield verhindert das mit einer Metaklasse, die alle Attributzuweisungen abfängt:

class FrozenNamespace(type):
    def __setattr__(cls, key, value):
        if key == "_SELF_HASH" and cls.__dict__.get("_SELF_HASH") is None:
            super().__setattr__(key, value)  # Allow one-time seal
            return
        raise TypeError(f"Cannot modify immutable law '{key}'")

    def __delattr__(cls, key):
        raise TypeError(f"Cannot delete immutable law '{key}'")

Das einzige Attribut, das gesetzt werden kann, ist _SELF_HASH, und nur einmal (wenn sich das Modul beim ersten Start selbst versiegelt). Danach kann nichts mehr geändert werden. Sowohl CoreSafety als auch Conscience verwenden diese Metaklasse.

Veränderlicher Laufzeitzustand (Zeitstempel des Ratenbegrenzers, Tageszähler) wird in einem _STATE-Wörterbuch gespeichert. Die Wörterbuchreferenz selbst ist unveränderlich (Sie können _STATE nicht durch ein anderes Dict ersetzen), aber der Inhalt des Wörterbuchs kann für operative Zwecke aktualisiert werden. Das ist eine bewusste Designentscheidung: Die Sicherheitskonstanten sind eingefroren, der operative Zustand nicht.

Konfiguration

shield = IntentShield(
    data_dir="./data",                             # Lock files and usage tracking
    restricted_domains=["darkweb", ".onion"],       # Additional blocked URL patterns
    protected_files=["secrets.json", ".env"],       # Untouchable files
    exempt_actions={"REFLECT"},                     # Skip harm-word check for these
    enable_hitl=True,                              # Human-in-the-loop (opt-in)
    hitl_actions={"DEPLOY", "SEND_EMAIL"},          # Custom high-impact action list
    hitl_ttl=300,                                  # Approval window in seconds
    enable_siem=True,                              # SIEM logging (opt-in)
    siem_path="logs/events.log",                   # Log file path
    siem_format="json",                            # "json" or "cef"
)

Was es abfängt

Demo

python demo.py

Führt 30+ reale Angriffsvektoren gegen alle Ebenen aus und zeigt eine farbcodierte Audit-Tabelle an.

Tests

python -m pytest tests/ -v

43 Testfälle, die CoreSafety, Conscience und die vereinheitlichte API von IntentShield abdecken.

Keine Abhängigkeiten

IntentShield ist reine Python-Standardbibliothek. Keine pip install-Abhängigkeitslabyrinthe. Kein Supply-Chain-Risiko. Funktioniert mit Python 3.8+.

Lizenz

Business Source License 1.1. Kostenlos für die nicht-produktive Nutzung. Für den Produktiveinsatz ist eine kommerzielle Lizenz erforderlich. Wird am 2036-03-09 zu Apache 2.0.