Wenn ein Agent Zugriff auf Tools bekommt, bekommt er die Möglichkeit zu handeln.
Er kann:
- Daten lesen
- API aufrufen
- Prozesse starten
- Den Systemzustand ändern
Und genau hier entsteht ein neues Risiko.
Denn der Agent weiß nicht, dass:
- Diese API Geld kostet
- Dieser Prozess das System kaputt machen kann
- Diese Daten nicht verändert werden dürfen
Er sieht nur das Ziel.
Und wenn zur Zielerreichung eine Aktion nötig ist, wird er versuchen, sie auszuführen.
Auch wenn diese Aktion:
- Teuer
- Gefährlich
- Oder irreversibel ist
Deshalb bekommt der Agent in realen Systemen keinen vollständigen Zugriff auf alles.
Er wird begrenzt durch:
- Welche Tools verfügbar sind
- Welche Aktionen erlaubt sind
- Und wann er stoppen muss
Ohne diese Grenzen ist ein Agent kein Ausführender.
Er ist ein Prozess, der zu weit gehen kann.
Was ein "erlaubtes Tool" bedeutet

Nicht jedes Tool, das im System existiert, sollte für den Agenten verfügbar sein.
Bevor die Arbeit beginnt, bekommt er nur die Tools, die er verwenden darf.
Aber Zugriff auf ein Tool ist nicht alles.
Selbst wenn der Agent ein Tool bekommen hat, heißt das nicht, dass er damit alles tun darf.
Es gibt zwei Zugriffsebenen:
Zwei Zugriffsebenen
Wenn wir sagen, dass ein Agent ein „erlaubtes Tool“ hat, kann das zwei verschiedene Dinge bedeuten:
- Ob der Agent überhaupt Zugriff auf das Tool hat
- Was genau er innerhalb dieses Tools tun darf
1️⃣ Zugriff auf das Tool
Zuerst entscheidet das System:
Welche Tools der Agent überhaupt sieht
| Tool wird dem Agenten gegeben | Tool ist vor dem Agenten verborgen |
|---|---|
✅ Datenbank | ❌ Zahlungssystem |
✅ E-Mail | ❌ Admin-Panel |
✅ Dateispeicher | ❌ Systemeinstellungen |
Wenn ein Tool nicht übergeben wurde, weiß der Agent nicht, dass es existiert.
Er kann es nicht:
- Aufrufen
- Anfordern
- Aus Versehen benutzen
2️⃣ Aktionen innerhalb des Tools
Aber selbst wenn ein Tool verfügbar ist, heißt das nicht volle Kontrolle.
Ein Tool kann mehrere Aktionen unterstützen.
Zum Beispiel: Datenbank
| In der Datenbank erlaubt | In der Datenbank verboten |
|---|---|
| ✅ Einträge ansehen | ❌ Bestehende ändern |
| ✅ Neue erstellen | ❌ Einträge löschen |
Wie das zusammen funktioniert
Das heißt: Er sieht das Tool, kann aber nur einen Teil seiner Möglichkeiten nutzen.
Wenn er eine verbotene Aktion versucht, lässt das System das einfach nicht zu.
Die Anfrage wird abgelehnt.
Und der Agent erhält:
{
"error": "Aktion nicht erlaubt"
}
Danach muss er einen anderen Schritt wählen.
Wie diese Grenzen gesetzt werden
In einem realen System werden Grenzen festgelegt, bevor der Agent zu arbeiten beginnt.
Es wird definiert:
- Welche Tools verfügbar sind
- Welche Aktionen erlaubt sind
- Welche Parameter übergeben werden dürfen
Zum Beispiel:
- Daten lesen nur aus einer bestimmten Tabelle erlauben
- E-Mails nur innerhalb des Unternehmens senden
- Nur mit Dateien in einem bestimmten Ordner arbeiten
Das heißt: Der Agent bekommt nicht nur Tools, sondern klare Nutzungsregeln.
Wenn er eine Aktion anfragt, prüft das System:
- Ob das Tool erlaubt ist
- Ob die Aktion erlaubt ist
- Ob die Parameter den Regeln entsprechen
Erst danach wird sie ausgeführt.
Wenn auch nur eine Bedingung nicht erfüllt ist, wird die Anfrage blockiert.
Im Code sieht das so aus
Unten steht dasselbe Prinzip in einfachem Format (wie in tool-calling-basics).
Zuerst haben wir Tools:
def read_user(user_id: int):
return {"id": user_id, "name": "Anna"}
def delete_user(user_id: int):
return {"deleted": user_id}
TOOLS = {
"database": {
"read_user": read_user,
"delete_user": delete_user,
}
}
Hier legen wir fest, was genau erlaubt ist:
ALLOWED_TOOLS = {"database"}
ALLOWED_ACTIONS = {
"database": {"read_user"} # delete_user ist verboten
}
Jetzt erstellt das Modell die Anfrage (was es genau tun will):
model_output = {
"tool": "database",
"action": "read_user",
"parameters": {"user_id": 123}
}
Das System erhält diese Anfrage und prüft vor der Ausführung die Regeln:
def run_tool_call(call: dict):
tool = call["tool"]
action = call["action"]
params = call["parameters"]
if tool not in ALLOWED_TOOLS:
return {"error": "Tool nicht erlaubt"}
if action not in ALLOWED_ACTIONS.get(tool, set()):
return {"error": "Aktion nicht erlaubt"}
if action == "read_user" and "user_id" not in params:
return {"error": "Ungültige Parameter"}
return TOOLS[tool][action](**params)
Wenn alles passt, erhalten wir ein Ergebnis:
result = run_tool_call(model_output)
# {"id": 123, "name": "Anna"}
Wenn das Modell eine verbotene Aktion (delete_user) anfragt, gibt das System zurück:
{
"error": "Aktion nicht erlaubt"
}
Vollständiges Implementierungsbeispiel mit angebundener LLM
Analogie aus dem Alltag
Stell dir vor, du gibst einer Assistenz eine Bankkarte. Aber mit Limit.
| Assistenz kann | Assistenz kann nicht |
|---|---|
| ✅ Ein Abo bezahlen | ❌ Bargeld abheben |
| ✅ Ein Taxi bestellen | ❌ Eine Überweisung machen |
| ✅ Büromaterial kaufen | ❌ Mehr als $100 ausgeben |
Die Karte ist dieselbe.
Aber die Nutzungsregeln sind unterschiedlich.
Genauso bei Tools.
Der Agent kann Zugriff auf die Datenbank haben. Aber nur zum Lesen.
Er kann E-Mails senden. Aber nur innerhalb des Unternehmens.
Er kann APIs aufrufen. Aber nur mit begrenztem Budget.
Er sieht das Tool, aber kann es nicht beliebig verwenden.
Was passiert, wenn der Agent Grenzen überschreitet
Der Agent kann jede Aktion anfragen.
Aber das heißt nicht, dass sie ausgeführt wird.
Wenn er:
- Ein verbotenes Tool aufruft
- Verbotene Parameter übergibt
- Oder ein gesetztes Limit überschreitet
Blockiert das System die Anfrage einfach.
Und gibt zurück:
{
"error": "Aktion nicht erlaubt"
}
Für den Agenten sieht das aus wie ein weiteres Ergebnis seiner Aktion.
Er sieht, dass dieser Weg geschlossen ist, und muss einen anderen wählen.
Zum Beispiel:
- Ein anderes Tool verwenden
- Parameter ändern
- Oder die Aufgabe mit dem abschließen, was da ist
So stoppen Grenzen den Agenten nicht komplett.
Sie definieren nur, wo er handeln darf und wo er stoppen muss.
Kurz gesagt
Tool-Zugriff ist nicht einfach "erlaubt" oder "verboten".
Es ist ein Regelwerk, das festlegt:
- Welche Tools der Agent verwenden darf
- Welche Aktionen darin erlaubt sind
- Welche Parameter übergeben werden dürfen
Wenn der Agent Grenzen überschreitet, blockiert das System die Anfrage.
Aber das stoppt die Arbeit nicht. Es erzwingt einen anderen Weg.
So machen Grenzen aus dem Agenten einen kontrollierten Ausführenden, nicht einen unkontrollierten Prozess.
FAQ
Q: Bedeutet Zugriff auf ein Tool volle Kontrolle darüber?
A: Nein. Der Agent kann Zugriff auf ein Tool haben, aber nur erlaubte Aktionen nutzen.
Q: Was passiert, wenn der Agent eine verbotene Aktion anfragt?
A: Das System prüft die Anfrage und blockiert sie, wenn sie gegen die Regeln verstößt.
Q: Stoppt der Agent nach einer blockierten Aktion?
A: Nein. Er bekommt das Ergebnis und muss einen anderen verfügbaren Schritt wählen.
Was kommt als Nächstes
Jetzt weißt du, wie man den Tool-Zugriff eines Agenten begrenzt.
Aber es entsteht eine andere Frage:
Wie entscheidet der Agent überhaupt, was zu tun ist?
Wenn er eine Aufgabe bekommt: Plant er alle Schritte im Voraus wie ein Mensch mit To-do-Liste?
Oder reagiert er auf die Situation und wählt den nächsten offensichtlichen Schritt?
Das sind nicht nur unterschiedliche Ansätze.
Das bestimmt, wie sich der Agent während der Arbeit verhält und wann er falsch abbiegen kann.