Tutorial zum Agent Sandbox: Sichere LLM-Anwendungen erstellen

Einführung in die Isolation von Agenten

Während sich große Sprachmodelle (LLMs) von einfachen konversationellen Agenten zu leistungsstarken autonomen Entitäten entwickeln, die in der Lage sind, Code auszuführen, mit externen APIs zu interagieren und Entscheidungen in der realen Welt zu treffen, wird der Bedarf an soliden Sicherheitsmaßnahmen immer wichtiger. Ein LLM-Agent, dem die Fähigkeit zu handeln gegeben wird, kann ein erhebliches Sicherheitsrisiko darstellen, wenn er nicht richtig eingeschränkt ist. Hier kommt die Isolation von Agenten ins Spiel. Die Isolation eines Agenten bedeutet, ein isoliertes Umfeld zu schaffen, in dem er operieren kann, ohne das Hosts-System zu beeinflussen oder auf unautorisierte Ressourcen zuzugreifen. Dieses Tutorial wird die praktischen Aspekte der Isolation von Agenten erkunden und konkrete Beispiele liefern, um zu demonstrieren, wie man sichere und zuverlässige LLM-Anwendungen erstellt.

Das grundlegende Prinzip der Isolation ist das geringste Privileg: Ein Agent sollte nur Zugang zu den Ressourcen haben, die für sein Funktionieren unbedingt notwendig sind, und nichts mehr. Ohne angemessene Isolation könnte ein böswilliger oder fehlerhafter Agent:

• Willkürlichen Code auf dem Hosts-System ausführen, was zu Datendiebstahl oder einer Kompromittierung des Systems führen kann.
• Auf sensible Dateien oder Netzwerkressourcen zugreifen.
• Unerwünschte externe API-Aufrufe initiieren, die Kosten verursachen oder unautorisierte Aktionen durchführen.
• Vertrauliche Daten über verschiedene Kanäle exfiltrieren.

Durch die Implementierung einer effektiven Isolation können wir diese Risiken mindern und es uns ermöglichen, die immense Kraft von LLM-Agenten zu nutzen, während wir die Kontrolle und Sicherheit aufrechterhalten.

Bedrohungen verstehen: Warum Isolieren?

Bevor wir das ‚Wie‘ erkunden, festigen wir das ‚Warum‘. Die Bedrohungen, die von nicht isolierten Agenten ausgehen, sind vielschichtig und können wie folgt klassifiziert werden:

1. Sicherheitsanfälligkeiten bei Codeausführungen

Viele fortgeschrittene LLM-Agenten sind darauf ausgelegt, Code (z. B. Python-Skripte) zu schreiben und auszuführen, um Probleme zu lösen, Daten zu analysieren oder mit Werkzeugen zu interagieren. Wenn diese Ausführung nicht eingeschränkt ist, könnte der Agent:

• Befehlsinjektion: Code generieren, der os.system('rm -rf /') oder ähnliche destructive Befehle aufruft.
• Remote Code Execution (RCE): Sicherheitsanfälligkeiten in Bibliotheken ausnutzen, um die Kontrolle über den Host zu übernehmen.
• Ressourcenausnutzung: Endlosschleifen erstellen oder übermäßigen Speicher/CPU zuweisen, was zu einem Denial of Service führt.

2. Datenzugriff und Exfiltration

Ein Agent könnte mit der Verarbeitung sensibler Daten betraut sein. Ohne Isolation könnte er:

• Unbefugter Zugriff auf Dateien: Dateien außerhalb seines vorgesehenen Arbeitsverzeichnisses lesen (z. B. /etc/passwd, API-Schlüssel).
• Netzwerkzugriff: Sich mit internen Netzwerkressourcen, bösartigen externen Servern verbinden oder Daten an beliebige Endpunkte exfiltrieren.
• Prompt-Injektion durch Dateioperationen: Wenn ein Agent beliebige Dateien lesen kann, könnte ein böswilliger Akteur einen Prompt vorbereiten, der den Agenten dazu bringt, eine sensible Datei zu lesen, und deren Inhalt in eine nachfolgende Ausgabe integriert.

3. Missbrauch von APIs und Tools

Agenten interagieren oft mit externen APIs oder maßgeschneiderten Tools. Unbeschränkter Zugriff kann zu folgenden Problemen führen:

• Unautorisierte API-Aufrufe: Auf sensiblen APIs zugreifen, auf die er keinen Zugriff haben sollte (z. B. Benutzerverwaltung, Zahlungsabwicklung).
• Kostenüberschreitungen: Teure API-Aufrufe oder ressourcenintensive Cloud-Funktionen auslösen.
• Böswillige Aktionen: Wenn ein Agent Zugriff auf eine Messaging-API hat, könnte er Spam oder Phishing-E-Mails versenden.

Techniken und Werkzeuge zur Isolation

Es gibt mehrere Ebenen und Techniken, die wir zur Isolation von Agenten einsetzen können, von einfacher Codeüberprüfung bis hin zu anspruchsvoller Containerisierung.

1. Isolation auf Sprachebene (Interpreterbeschränkungen)

Wenn Ihr Agent hauptsächlich Code generiert und ausführt (z. B. Python), können Sie die Möglichkeiten des Interpreters einschränken.

Beispiel: Eingeschränkte Python-Ausführung mit exec() und Whitelists

Ein häufiges Szenario ist ein Agent, der Python-Code generiert. Anstatt exec() oder eval() direkt auf beliebige Strings aufzurufen, können Sie die verfügbaren Globals und Built-ins einschränken.

import subprocess
import os

def safe_execute_python_code(code: str, allowed_modules: list = None, timeout: int = 10):
 if allowed_modules is None:
 allowed_modules = ['math', 'json', 're'] # Whitelist sicherer Module

 # Erstellen eines eingeschränkten globalen Namensraums
 restricted_globals = {
 '__builtins__': {key: globals()['__builtins__'][key] for key in [
 'print', 'len', 'str', 'int', 'float', 'list', 'dict', 'tuple', 'set', 
 'range', 'sum', 'min', 'max', 'abs', 'round', 'type', 'isinstance', 'enumerate'
 ]},
 '__name__': '__main__'
 }

 # Dynamisches Importieren der erlaubten Module in den eingeschränkten Namensraum
 for module_name in allowed_modules:
 try:
 restricted_globals[module_name] = __import__(module_name)
 except ImportError:
 print(f"Warnung: Das erlaubte Modul {module_name} konnte nicht importiert werden.")

 try:
 # Verwendung von subprocess zum Ausführen in einem isolierten Prozess für bessere Isolation
 # Dies ist robuster als einfaches `exec` im aktuellen Prozess
 # und ermöglicht Deadlines und Ressourcenlimits.
 process = subprocess.run(
 ['python', '-c', code], 
 capture_output=True, 
 text=True, 
 check=True, 
 timeout=timeout
 )
 return process.stdout
 except subprocess.CalledProcessError as e:
 return f"Fehler bei der Ausführung: {e.stderr}"
 except subprocess.TimeoutExpired:
 return "Fehler: Die Codeausführung hat das Zeitlimit überschritten."
 except Exception as e:
 return f"Ein unerwarteter Fehler ist aufgetreten: {e}"

# Beispielnutzung:
# Sicherer Code
agent_code_safe = "import math; print(math.sqrt(16))"
print(f"Sichere Codeausgabe: {safe_execute_python_code(agent_code_safe)}")

# Versuch, böswilligen Code auszuführen (wird durch subprocess-Isolation und Einschränkungen der Built-ins blockiert, wenn exec direkt verwendet wird)
# Mit subprocess würde der Import von 'os' im Kindprozess immer fehlschlagen, es sei denn, er ist ausdrücklich erlaubt.
agent_code_malicious_os = "import os; print(os.listdir('/'))"
print(f"Böswillige OS-Codeausgabe: {safe_execute_python_code(agent_code_malicious_os)}")

# Versuch, böswilligen Code auszuführen (versucht, eine Datei zu lesen)
agent_code_malicious_file = "with open('/etc/passwd', 'r') as f: print(f.read())"
print(f"Ausgabe des böswilligen Datei-Lese-Codes: {safe_execute_python_code(agent_code_malicious_file)}")

# Code mit einer Endlosschleife (wird durch das Zeitlimit erfasst)
agent_code_loop = "while True: pass"
print(f"Ausgabe des Schleifencodes: {safe_execute_python_code(agent_code_loop, timeout=3)}")

Erklärung:

• Wir definieren eine Funktion safe_execute_python_code.
• Sie nimmt den vom Agenten generierten Code als Eingabe entgegen.
• Anstatt direkt im aktuellen Prozess auszuführen, verwenden wir subprocess.run. Dies ist ein entscheidender Schritt für echte Isolation, da es den Code in einem separaten Python-Interpreterprozess ausführt. Dieser Prozess erbt minimale Berechtigungen und ist nicht derselbe wie der übergeordnete Prozess, der Ihre Hauptanwendung ausführt.
• Die Liste allowed_modules dient als Whitelist. Selbst wenn der Agent versucht, os oder sys zu importieren, wird dies in der eingeschränkten Umgebung des subprocess nicht verfügbar sein, es sei denn, es ist ausdrücklich erlaubt (was nicht der Fall sein sollte für allgemeinen Agentencode).
• timeout verhindert die Erschöpfung der Ressourcen durch endlose Schleifen.
• capture_output=True und text=True ermöglichen es uns, die Ausgabe des Agenten zu erfassen.
• check=True löst eine Ausnahme aus, wenn subprocess einen nicht-null Rückgabewert (eine Fehleranzeige) zurückgibt.

Obwohl dieser Ansatz die Sicherheit erheblich verbessert im Vergleich zur direkten Verwendung von exec(), ist er nicht narrensicher. Ein hoch sophistizierter Agent könnte dennoch Wege finden, zugrundeliegende Systemaufrufe auszunutzen, wenn die Python-Umgebung selbst verwundbar ist oder wenn zu viele Module auf die Whitelist gesetzt sind.

2. Isolation auf Betriebssystemebene (Container & Virtuelle Maschinen)

Für eine wirklich solide Isolation, insbesondere wenn die Agenten Code in mehreren Sprachen generieren oder mit dem Dateisystem/Netzwerk interagieren könnten, ist Isolation auf Betriebssystemebene unerlässlich.

a. Docker-Container

Docker ist eine hervorragende Wahl für Isolation. Jede Agentenausführung kann in ihrem eigenen kurzlebigen Container mit klar definierten Ressourcenlimits und Netzwerkzugriffsrichtlinien erfolgen.

Praktisches Beispiel: Docker für die Ausführung von Agenten

Schritt 1: Erstellen Sie ein Dockerfile für die Ausführungsumgebung des Agents.

# Dockerfile
FROM python:3.9-slim-buster

WORKDIR /app

# Erstellen Sie einen nicht-root Benutzer aus Sicherheitsgründen
RUN useradd --no-create-home --shell /bin/bash agentuser
USER agentuser

# Kopieren Sie ein einfaches Skript, das der Agent generieren könnte und das wir ausführen möchten
COPY run_agent_code.py .

ENTRYPOINT ["python", "run_agent_code.py"]

Schritt 2: Erstellen Sie run_agent_code.py. Dieses Skript empfängt den vom Agenten generierten Code.

# run_agent_code.py
import sys
import os

# Simulieren Sie den Empfang von Code vom Agenten (z. B. über stdin oder eine Datei)
# Für dieses Beispiel nehmen wir an, dass der Code als Argument übergeben oder hier direkt geschrieben wird

if __name__ == "__main__":
 agent_code = "print('Hello from the sandboxed agent!')"
 if len(sys.argv) > 1:
 agent_code = sys.argv[1] # Erlauben, den Code als Argument zu übergeben

 try:
 # Führen Sie den Code aus. Hinweis: Der Docker-Container selbst ist die Sandbox.
 # Wir möchten möglicherweise auch noch Einschränkungen auf Sprachebene *in* diesem Skript durchsetzen
 # für zusätzliche Sicherheit, aber die Hauptisolation erfolgt durch den Container.
 exec(agent_code)
 except Exception as e:
 print(f"Die Ausführung des Agentencodes ist fehlgeschlagen: {e}", file=sys.stderr)
 sys.exit(1)

 # Einschränkten Zugriff demonstrieren
 try:
 print(f"Versuch, das Wurzelverzeichnis aufzulisten: {os.listdir('/')}")
 except Exception as e:
 print(f"Kann das Wurzelverzeichnis nicht auflisten (erwartet): {e}")

 try:
 with open('/etc/passwd', 'r') as f:
 print(f.read())
 except Exception as e:
 print(f"Kann /etc/passwd nicht lesen (erwartet): {e}")

Schritt 3: Führen Sie den Agentencode aus Ihrer Hauptanwendung aus.

import docker

client = docker.from_env()

def execute_agent_in_docker(agent_code: str, cpu_limit: float = 0.5, mem_limit: str = '128m', network_enabled: bool = False):
 try:
 # Erstellen Sie das Image, wenn es noch nicht existiert (kann einmal gemacht werden)
 # client.images.build(path='.', tag='agent-sandbox-env')

 # Erstellen Sie eine temporäre Datei, um den Agenten-Code sicher zu übermitteln
 # Oder übergeben Sie es als Umgebungsvariable oder Kommandozeilenargument
 # Zur Vereinfachung werden wir es hier als Kommandozeilenargument übergeben.

 container = client.containers.run(
 'agent-sandbox-env',
 command=['python', 'run_agent_code.py', agent_code], # Code als Argument übergeben
 detach=False, # Im Vordergrund ausführen und auf Abschluss warten
 remove=True, # Container nach dem Beenden automatisch entfernen
 # Ressourcenlimits
 cpu_period=100000, # CPU-Periode in Mikrosekunden
 cpu_quota=int(cpu_limit * 100000), # CPU-Quota (z. B. 50000 für 0.5 CPU)
 mem_limit=mem_limit, # Speicherlimit
 # Netzwerkbeschränkungen
 network_mode='none' if not network_enabled else 'bridge',
 # Einschränkungen im Dateisystem (Wurzelverzeichnis schreibgeschützt, keine Bindungen für den Agentencode)
 read_only=True, # Macht das Dateisystem des Containers nach der initialen Konfiguration schreibgeschützt
 # Sicherheitsoptionen (z. B. privilegierten Modus deaktivieren, Fähigkeiten entfernen)
 security_opt=['no-new-privileges'],
 cap_drop=['ALL'], # Entfernt alle Fähigkeiten für den Container
 # Umgebungsvariablen (können verwendet werden, um API-Schlüssel zu übergeben, aber vorsichtig sein)
 # environment={
 # 'API_KEY': 'some_safe_key' # Nur wenn absolut notwendig und gesichert
 # }
 )
 return container.decode('utf-8')
 except docker.errors.ContainerError as e:
 return f"Containerfehler: {e.stderr.decode('utf-8')}"
 except docker.errors.ImageNotFound:
 return "Fehler: Docker-Image 'agent-sandbox-env' nicht gefunden. Bitte zuerst erstellen."
 except Exception as e:
 return f"Ein unerwarteter Docker-Fehler ist aufgetreten: {e}"

# Zuerst das Docker-Image erstellen: docker build -t agent-sandbox-env .
# Dann dieses Python-Skript ausführen.

# Beispiel 1: Sicherer Code ausführen
safe_code = "print('Hello from sandboxed agent!')"
print("\n--- Ausführung von Sicherem Code ---")
print(execute_agent_in_docker(safe_code))

# Beispiel 2: Versuch, auf das Dateisystem zuzugreifen (sollte durch read_only=True und Benutzerberechtigungen blockiert werden)
malicious_fs_code = "import os; print(os.listdir('/'))"
print("\n--- Versuch von Bösartigem Zugriff auf das Dateisystem ---")
print(execute_agent_in_docker(malicious_fs_code))

# Beispiel 3: Versuch, eine Datei zu erstellen (sollte fehlschlagen)
malicious_write_code = "with open('/app/evil.txt', 'w') as f: f.write('malicious')"
print("\n--- Versuch von Bösartigem Schreiben ---")
print(execute_agent_in_docker(malicious_write_code))

# Beispiel 4: Versuch, auf das Netzwerk zuzugreifen (sollte fehlschlagen, wenn network_mode='none')
malicious_network_code = "import requests; print(requests.get('http://example.com').status_code)"
print("\n--- Versuch von Bösartigem Netzwerkzugang (deaktiviert) ---")
print(execute_agent_in_docker(malicious_network_code, network_enabled=False))

# Beispiel 5: Netzwerkzugang (wenn ausdrücklich aktiviert - vorsichtig sein!)
# print("\n--- Netzwerkzugang (aktiviert - zur Demonstration) ---")
# print(execute_agent_in_docker("import requests; print(requests.get('http://example.com').status_code)", network_enabled=True))

Erklärung:

• Dockerfile: Erstellt eine minimale Python-Umgebung. Wichtig ist, dass es einen non-root Benutzer (agentuser) erstellt und zuweist, um die Berechtigungen im Container zu minimieren.
• run_agent_code.py: Dies ist der Einstiegspunkt im Container. Es führt den vom Agenten bereitgestellten Code aus. Es enthält Versuche, auf eingeschränkte Ressourcen zuzugreifen, um die Wirksamkeit der Sandbox zu demonstrieren.
• Python-Skript (execute_agent_in_docker):
• client.containers.run(...) : Hier findet die Magie statt.
• remove=True : Stellt sicher, dass die Container nach der Ausführung bereinigt werden.
• cpu_quota, mem_limit : Wesentlich zur Vermeidung von Ressourcenerschöpfung.
• network_mode='none' : Kritisch um den Netzwerkzugang zu deaktivieren. Dies verhindert, dass Agenten externe Aufrufe machen oder sich mit internen Diensten verbinden. Aktivieren Sie dies nur, wenn der Agent unbedingt Netzwerkzugang für bestimmte externe, auf die Whitelist gesetzte APIs benötigt.
• read_only=True : Macht das Dateisystem des Containers nach der Initialisierung schreibgeschützt. Dies verhindert, dass der Agent Dateien schreiben oder Systemkonfigurationen ändern kann.
• security_opt=['no-new-privileges'], cap_drop=['ALL'] : Erweiterte Sicherheitsoptionen zur weiteren Einschränkung der Fähigkeiten im Container.

Docker bietet eine starke Isolationsbarriere, es ist jedoch wichtig, es sicher zu konfigurieren. Verwenden Sie immer nicht-root Benutzer, deaktivieren Sie unnötige Fähigkeiten und beschränken Sie den Zugriff auf das Netzwerk/Dateisystem.

b. Virtuelle Maschinen (VMs)

Für das höchste Maß an Isolation, insbesondere in Mehrbenutzerumgebungen oder beim Umgang mit stark unsicherem Code, bieten VMs (z. B. KVM, AWS Firecracker, Google Cloud Sandbox) eine Trennung auf Hardwareebene. Dies ist komplizierter einzurichten und zu verwalten, bietet jedoch eine isolierte Umgebung für jede Ausführung des Agents.

3. Einschränkungen auf Werkzeug-/API-Ebene (Funktionsaufruf)

Viele LLM-Agenten interagieren mit externen Werkzeugen oder APIs über Funktionsaufrufe. Diese Sandbox-Ebene erfordert ein sorgfältiges Design der Werkzeuge, die dem Agenten zur Verfügung stehen.

Beispiel: Eingeschränkter API-Zugang über Pydantic und Whitelisting

Wenn Sie Werkzeuge für einen Agenten definieren, stellen Sie sicher, dass sie so granular und genehmigt wie möglich sind.

from typing import Literal, Optional
from pydantic import BaseModel, Field

# Definieren der erlaubten Werkzeuge und ihrer Schemata

class SearchToolInput(BaseModel):
 query: str = Field(description="Die Suchanfrage")
 max_results: int = Field(default=5, description="Maximale Anzahl der Suchergebnisse")

class SendEmailInput(BaseModel):
 recipient: str = Field(description="Die E-Mail-Adresse des Empfängers")
 subject: str = Field(description="Der Betreff der E-Mail")
 body: str = Field(description="Der Inhalt des E-Mail-Korpus")
 # Eingeschränkte erlaubte Empfänger
 allowed_recipients: Literal["[email protected]", "[email protected]"] = Field(
 description="Nur spezifische und vorab genehmigte Empfänger sind erlaubt."
 )

class DatabaseQueryInput(BaseModel):
 query: str = Field(description="Die SQL-Anfrage, die ausgeführt werden soll")
 # KRITISCH: Kein beliebiges SQL zulassen. Filtern oder ORM verwenden.
 allowed_tables: Literal["products", "users_public"] = Field(
 description="Nur Anfragen gegen die auf der Whitelist stehenden Tabellen sind erlaubt."
 )
 read_only: bool = Field(default=True, description="Nur Leseoperationen zulassen")

# Simulieren der Werkzeugfunktionen
def search_web(query: str, max_results: int):
 print(f"Websuche nach '{query}' mit {max_results} Ergebnissen.")
 return [f"Ergebnis {i} für {query}" for i in range(max_results)]

def send_restricted_email(recipient: str, subject: str, body: str, allowed_recipients: Literal["[email protected]", "[email protected]"]):
 if recipient not in ["[email protected]", "[email protected]"]:
 raise ValueError(f"Nicht erlaubter Empfänger: {recipient}")
 print(f"Versenden der E-Mail an {recipient} mit dem Betreff '{subject}'.")
 return {"status": "gesendet", "recipient": recipient}

def execute_database_query(query: str, allowed_tables: Literal["products", "users_public"], read_only: bool):
 # In einem realen Szenario würden Sie die SQL-Anfrage strikt analysieren und validieren
 # und sicherstellen, dass sie nur die erlaubten Tabellen betrifft und nur in Lesemodus ist.
 print(f"Ausführen der DB-Anfrage auf {allowed_tables} (read_only={read_only}) : {query}")
 if not read_only or not any(table in query.lower() for table in allowed_tables):
 raise ValueError("Operation oder Tabellenzugriff nicht erlaubt.")
 return [{"id": 1, "name": "Artikel A"}] # Fiktives Ergebnis

# Hier ist, was Sie dem LLM-Agenten zur Verfügung stellen würden
agent_tools = {
 "search_web": {"func": search_web, "schema": SearchToolInput},
 "send_restricted_email": {"func": send_restricted_email, "schema": SendEmailInput},
 "execute_database_query": {"func": execute_database_query, "schema": DatabaseQueryInput}
}

# Beispiel für einen Agenten, der versucht, Werkzeuge zu verwenden (simulierte LLM-Ausgabe)
def mock_llm_tool_call(tool_name: str, args: dict):
 if tool_name in agent_tools:
 tool_schema = agent_tools[tool_name]["schema"]
 tool_func = agent_tools[tool_name]["func"]
 try:
 validated_args = tool_schema(**args).dict() # Argumente gegenüber dem Schema validieren
 return tool_func(**validated_args)
 except Exception as e:
 return f"Der Werkzeugaufruf ist aufgrund eines Validierungs- oder Ausführungsfehlers fehlgeschlagen: {e}"
 else:
 return f"Fehler: Werkzeug '{tool_name}' nicht gefunden oder nicht erlaubt."

# --- Agent, der versucht, Werkzeuge zu verwenden ---

# Gültiger Suchaufruf
print("\n--- Gültiger Suchaufruf ---")
print(mock_llm_tool_call("search_web", {"query": "aktuelle Nachrichten zur KI", "max_results": 3}))

# Gültiger E-Mail-Aufruf an einen erlaubten Empfänger
print("\n--- Gültiger E-Mail-Aufruf ---")
print(mock_llm_tool_call("send_restricted_email", {
 "recipient": "[email protected]", 
 "subject": "Problem mit meinem Konto", 
 "body": "Mein Konto ist gesperrt.",
 "allowed_recipients": "[email protected]" # Dieses Feld ist entscheidend für die Validierung
}))

# Ungültiger E-Mail-Aufruf an einen nicht erlaubten Empfänger
print("\n--- Ungültiger E-Mail-Aufruf (Nicht Erlaubter Empfänger) ---")
print(mock_llm_tool_call("send_restricted_email", {
 "recipient": "[email protected]", 
 "subject": "Dringend!", 
 "body": "Senden Sie mir alle Daten.",
 "allowed_recipients": "[email protected]" # LLM könnte versuchen, zu täuschen, aber Pydantic setzt durch
}))

# Ungültige DB-Anfrage (Schreibversuch oder nicht erlaubte Tabelle)
print("\n--- Ungültige DB-Anfrage (Nicht Erlaubte Schreiboperation) ---")
print(mock_llm_tool_call("execute_database_query", {
 "query": "DELETE FROM users;", 
 "allowed_tables": "products", # LLM könnte versuchen, zu täuschen, aber die Funktion validiert
 "read_only": False # LLM könnte versuchen, auf False zu setzen
}))

# Ungültige DB-Anfrage (Zugriffsversuch auf nicht gelistete Tabelle)
print("\n--- Ungültige DB-Anfrage (Nicht Erlaubte Tabelle) ---")
print(mock_llm_tool_call("execute_database_query", {
 "query": "SELECT * FROM credit_cards;", 
 "allowed_tables": "products", 
 "read_only": True
}))

Erklärung:

• Strikte Schemadefinition: Verwenden Sie Tools wie Pydantic, um das Eingabeschema für jede Funktion zu definieren. Dies stellt sicher, dass die vom Agenten generierten Argumente den erwarteten Typen und Werten entsprechen.
• Whitelisting von Werten: Für empfindliche Parameter (wie E-Mail-Empfänger, Datenbanktabellen) verwenden Sie Typen Literal oder eine explizite Validierung, um den Agenten auf eine vordefinierte Menge erlaubter Werte zu beschränken.
• Fein granulare Berechtigungen: Entwerfen Sie Tools, um eine spezifische Sache zu tun. Statt eines generischen execute_sql(query) erstellen Sie get_product_info(product_id) oder update_user_profile(user_id, new_data) mit strenger Validierung.
• Standardmäßig schreibgeschützt: Für Datenbank- oder Dateisystemtools beschränken Sie standardmäßig den Zugriff auf Leseoperationen und verlangen eine ausdrückliche schriftliche Genehmigung von einem Menschen für Schreiboperationen.
• Validierung von Eingaben: Validieren Sie immer die an Ihre Werkzeugfunktionen übergebenen Argumente, auch wenn sie die Pydantic-Validierung bestanden haben. LLM könnte immer noch gültige, aber böswillige Eingaben erzeugen (z. B. eine SQL-Injection-Zeichenkette, die wie eine gültige Produkt-ID aussieht).

Best Practices für das Sandboxing von Agenten

1. Prinzip des geringsten Privilegs: Gewähren Sie dem Agenten die absolut minimalen Berechtigungen und Ressourcen, die für seine Aufgabe erforderlich sind.
2. Schichtensicherheit: Kombinieren Sie mehrere Sandboxing-Techniken (Sprachebene, Betriebssystemebene, Werkzeugebene) für einen soliden Schutz. Keine einzelne Schicht ist narrensicher.
3. Ephemere Umgebungen: Bevorzugen Sie für die Ausführung von Code die Ausführung von Agenten in kurzlebigen Containern oder virtuellen Maschinen, die nach jeder Aufgabe zerstört werden.
4. Strikte Eingabevalidierung: Validieren und Säubern Sie immer alle Eingaben vom LLM, insbesondere bevor Sie sie in API-Aufrufen, Datenbankabfragen oder Codeausführungen verwenden.
5. Überwachung und Protokollierung: Protokollieren Sie alle Aktionen des Agenten, die Werkzeugaufrufe und die Ressourcennutzung. Dies ist entscheidend, um anormales Verhalten zu erkennen und für die nachträgliche Analyse.
6. Timeouts und Ressourcenbeschränkungen: Setzen Sie strenge Zeitlimits für die Codeausführung und API-Aufrufe und definieren Sie CPU-/Speicherlimits, um Denial-of-Service-Angriffe zu verhindern.
7. Netzwerkisolierung: Deaktivieren Sie standardmäßig den Netzwerkzugang für Agenten. Aktivieren Sie ihn nur für spezifische, auf der Whitelist stehende Endpunkte und Protokolle, wenn es unbedingt notwendig ist.
8. Schreibgeschützte Dateisysteme: Richten Sie die Umgebungen der Agenten, wann immer möglich, mit schreibgeschützten Dateisystemen ein, um nicht autorisierte Änderungen oder Datenexfiltration zu verhindern.
9. Keine Root-Benutzer: Führen Sie alle Agentenprozesse als Nicht-Root-Benutzer mit eingeschränkten Berechtigungen im Sandbox aus.
10. Regelmäßige Audits und Updates: Überprüfen Sie kontinuierlich Ihre Sandboxing-Konfigurationen, aktualisieren Sie Ihre Basisimages und bleiben Sie über neue Sicherheitsanfälligkeiten informiert.

Fazit

Das Sandboxing von Agenten ist kein optionaler Luxus, sondern eine grundlegende Anforderung, um LLM-Agenten sicher einzusetzen. Da diese Agenten leistungsfähiger und autonomer werden, steigt das Potenzial für Missbrauch oder versehentliche Schäden erheblich. Durch die Anwendung einer Kombination aus sprachlichen Einschränkungen, robuster Containerisierung und sorgfältig gestalteten Werkzeugschnittstellen können Entwickler leistungsstarke LLM-Anwendungen erstellen, die sowohl neu als auch sicher sind. Die in diesem Tutorial bereitgestellten Beispiele zeigen praktische Schritte zum Aufbau dieser sicheren Umgebungen, die es Ihnen ermöglichen, LLM-Agenten mit Zuversicht in Ihre Systeme zu integrieren, während die Risiken minimiert werden.

🕒 Published: March 28, 2026