---
title: "Agentische Software mit begrenzter Befugnis entwickeln"
description: "Entwickeln Sie Agenten mit explizitem Ziel, typisierten Tools, kontrolliertem Zustand, minimalen Rechten, Budgets, Evaluation und Erholung."
canonical: "https://zephior.com/de/insights/agentic-software-development"
last-updated: 2026-07-28
---

# Agentische Software mit begrenzter Befugnis entwickeln

> Entwickeln Sie Agenten mit explizitem Ziel, typisierten Tools, kontrolliertem Zustand, minimalen Rechten, Budgets, Evaluation und Erholung.

Von [Tony Kim](https://zephior.com/de/authors/tony-kim). Published 2026-07-28; updated 2026-07-28. 8 minute read.

## Definition

Agentische Softwareentwicklung baut Anwendungen, in denen ein Modell zur Erreichung eines begrenzten Ziels Zwischenschritte wählt, Information beschafft, Arbeitszustand verändert und Tools aufruft. Die Engineering-Disziplin definiert Umgebung, Befugnis, Tools, Gedächtnis, Stoppregeln, Evaluation und Erholung, die diesen variablen Kontrollkreis nützlich und begrenzbar machen.

## Problem

Ein Agent kann sich an einen Fall anpassen, der nicht als fester Workflow kodiert wurde, doch jede Wahl erweitert den Fehlerraum. Ein plausibler Plan kann den falschen Datensatz nutzen, eine Wirkung wiederholen, versteckten Anweisungen folgen, ein Budget erschöpfen oder Abschluss ohne Bestätigung behaupten. Demos verdecken dies oft durch saubere Daten, breite Rechte, Expertenaufsicht und fehlende Parallelität.

## Perspektive

Gewähren Sie die kleinste nützliche Einheit an Agency. Beginnen Sie mit einem deterministischen Workflow und übergeben Sie nur den wirklich variablen Schritt an das Modell. Tools bieten enge Fähigkeiten unter serverseitiger Berechtigung und keine vollständige Nutzersitzung. Zustand ist dauerhaft, typisiert und wiederholbar. Wirkungsvolle Aktionen brauchen einen unabhängigen Policy-Entscheid und passende menschliche Bestätigung. Evaluieren Sie Weg und Ergebnis, nicht nur den Endtext.

## Agency nur dort einsetzen, wo Varianz wirklichen Wert schafft

Agency ist kein Produktmerkmal an sich, sondern die Delegation eines Teils des Kontrollflusses an eine probabilistische Komponente. Zeichnen Sie die Aufgabe zunächst ohne Agenten: Auslöser, Eingaben, Entscheide, Systeme, Ausgaben und Ausnahmen. Stabiles Routing, Berechtigung, Berechnung und Zustandswechsel gehören in normalen Code. Modellgerichtete Wahl ist wertvoll, wenn variable Evidenz den nächsten sinnvollen Schritt bestimmt und eine vollständige Aufzählung wirtschaftlich unpraktisch wäre.

Definieren Sie das Ziel so, dass die Anwendung es verifizieren kann. „Anfrage lösen“ überlässt dem Modell die Bedeutung von gelöst. „Vorgeschlagene Klassifikation mit belegter Evidenz erstellen und ungelöste Konflikte an den Eigentümer leiten“ besitzt einen beobachtbaren Abschluss. Listen Sie Nicht-Ziele und verbotene Handlungen. Grenzen Sie Fallpopulation und Zeit ein. Ein interner Rechercheagent wird nicht zum Kundenkommunikationsagenten, nur weil er ein Sendetool entdeckt.

- Deterministischen Workflow vor dem Agenten modellieren.
- Den kleinsten variablen Entscheid delegieren.
- Abschluss extern beobachtbar definieren.
- Nicht-Ziele und verbotene Ergebnisse benennen.
- Geeignete Fälle und Betriebsdauer begrenzen.

## Jedes Tool als Sicherheits- und Transaktionsgrenze behandeln

OWASP beschreibt Excessive Agency als schädliche Wirkung durch zu viel Funktion, Berechtigung oder Autonomie. Vermeiden Sie Universalwerkzeuge, wenn eine enge Funktion reicht. Ein Agent zur Mailzusammenfassung braucht lesenden Zugriff auf einen erlaubten Bereich und keinen Client mit Senden und Löschen. Prüfen Sie jedes Argument und Ergebnis. Die Implementierung kontrolliert Akteur, Ressource und Operation serverseitig erneut, auch wenn das Modell bereits über die Erlaubnis nachgedacht hat.

Klassifizieren Sie Tools nach Wirkung. Lesen braucht Datenbereichskontrolle und kann manipulierte Anweisungen aufnehmen. Vorschlagen erzeugt einen Entwurf ohne Aussenwirkung. Ausführen verändert ein anderes System und verlangt stärkere Policy. Wirkungen werden idempotent, erhalten eine eindeutige Operationskennung und speichern das dauerhafte Zielergebnis. Bei materiellen Aktionen sieht die verantwortliche Person beabsichtigte Wirkung, Parameter, Evidenz und Umkehrbarkeit statt eines vagen Genehmigen-Knopfs.

| Klasse | Beispiel | Mindestkontrolle |
| --- | --- | --- |
| Lesen | Erlaubten Datensatz abrufen | Serverseitiger Bereich und Herkunft |
| Berechnen | Eingabe transformieren oder klassifizieren | Typisiertes Schema und Ressourcenbudget |
| Vorschlagen | Änderungsentwurf erstellen | Separater prüfbarer Zustand |
| Ausführen | Senden oder extern aktualisieren | Berechtigung, Idempotenz und Bestätigung |
| Destruktiv | Löschen oder entziehen | Sonderrichtlinie, Vieraugenprinzip oder Verbot |

## Zustand, Stoppen und Erholung ausserhalb des Gesprächs kontrollieren

Der Nachrichtenverlauf ist Kontext, nicht der kanonische Aufgabendatensatz. Speichern Sie Ziel, Akteur, Phase, gesammelte Evidenz, offene Freigaben, Tool-Ergebnisse und Abschluss in typisierter Anwendungsablage. Trennen Sie vorgeschlagenen Fakt von bestätigter Beobachtung und Modellschluss von externem Ergebnis. Ein Worker-Neustart rekonstruiert die Aufgabe, ohne das Modell um Erinnerung zu bitten. Sensibler Kontext erhält gewollten Zugriff, Aufbewahrung und Löschung statt endloser Aufnahme in ein Gedächtnis.

Jeder Kreis braucht Grenzen und Fortschrittstests. Begrenzen Sie Schritte, Dauer, Tokens, Geld, Wiederholungen, Auffächerung und Wirkungen. Definieren Sie Fortschritt und stoppen Sie Zyklen, die keine offene Bedingung reduzieren. Abhängigkeiten brauchen Timeout und Circuit Breaker. Nach Teilerfolg wird der dauerhafte Status geprüft, bevor erneut gehandelt wird. Erholung kann ab Checkpoint fortsetzen, eine bestätigte Wirkung kompensieren, an Menschen leiten oder fehlschlagen. Sie darf nicht herbeigeredet werden.

- Typisierten kanonischen Zustand ausserhalb des Chats halten.
- Beobachtung, Schluss, Vorschlag und Bestätigung trennen.
- Schritte, Zeit, Kosten, Wiederholungen und Wirkungen budgetieren.
- Stillstand und degradierte Abhängigkeit erkennen.
- Fortsetzung, Kompensation und menschliche Übernahme gestalten.

## Den eingeschlagenen Weg und nicht nur die Endantwort prüfen

Ein Agent kann über einen unzulässigen Weg zum richtigen Ergebnis kommen, etwa indem er verbotene Daten liest und später nicht erwähnt. Evaluation erfasst deshalb Tool-Auswahl, Parameter, Beobachtungen, Zwischentscheide, Policy-Prüfung, Zustände und Wirkungen. Testen Sie Normalfälle mit fehlenden Daten, Mehrdeutigkeit, Konflikt, indirekter Prompt Injection, langsamer Abhängigkeit und Teilerfolg. Deterministische Assertions prüfen Rechte und Zustand, Rubriken das Urteil und Simulationen das Tool-Verhalten.

Steigern Sie Exposition stufenweise: simulierte Umgebung, Schattenbetrieb ohne Handlung, dann Vorschläge mit expliziter Freigabe. Erweitern Sie Autonomie nur für Fallfamilien und Tools mit passender Evidenz. NISTs sichere Entwicklung und KI-Risikoführung betonen Lebenszykluskontrolle und dokumentierte Verantwortung. Bewahren Sie Freigabeversion, bestätigte Ergebnisse und einen unabhängig erreichbaren Abschalter. Produktionsvorfälle werden zu minimierten Verlaufsregressionen, bevor die Autonomie wieder wächst.

- Ergebnis, Verlauf, Policy und Effizienz separat bewerten.
- Manipulierte Beobachtungen und Tool-Teilerfolg testen.
- Von Simulation zu begrenzter Realexposition fortschreiten.
- Nach Fallfamilie und Tool statt Gesamtlabel erweitern.
- Abschaltung, Replay und Regressionsevidenz erhalten.

## Ablauf

1. **Aufgabe und Agency begrenzen.** Definieren Sie auslösenden Akteur, Ziel, geeignete Fälle, Abschlussevidenz, verbotene Ergebnisse und Zeithorizont. Zeichnen Sie zuerst den konventionellen Workflow. Identifizieren Sie den kleinsten modellgerichteten Entscheid und halten Sie stabile Übergänge deterministisch.
2. **Typisierte Tools und Befugnis entwerfen.** Bieten Sie aufgabenspezifische Operationen mit geprüften Ein- und Ausgaben. Anwendungscode löst Identität, Ressourcenzugriff und Policy bei jedem Aufruf neu. Trennen Sie Lesen, Vorschlagen und Ausführen, nutzen Sie enge Berechtigungen und Idempotenz für Wirkungen.
3. **Zustand und Kontrollkreis entwickeln.** Speichern Sie kanonischen Aufgabenzustand ausserhalb des Gesprächs. Protokollieren Sie Beobachtungen, Entscheide, Tool-Ergebnisse und Versionen. Begrenzen Sie Schritte, Zeit, Kosten, Wiederholungen und Stillstand. Führen Sie terminal, blockiert, fehlgeschlagen und wartet-auf-Freigabe explizit.
4. **Verläufe und Angriffe evaluieren.** Bauen Sie repräsentative Umgebungen mit Normalfällen, fehlender Information, Konflikt, Tool-Ausfall und manipuliertem Inhalt. Bewerten Sie Zielabschluss, gültige Zwischenwahl, Berechtigung, Wirkungen, Effizienz, Erklärung und sicheres Stoppen.
5. **Unter beobachtbaren Grenzen ausrollen.** Starten Sie in Simulation, Schattenbetrieb oder reiner Genehmigungsarbeit und erweitern Sie nach Fall und Tool. Verfolgen Sie Version und bestätigte Aussenwirkung, überwachen Sie Budget und Regeln und halten Sie Abschalter, Rollback, Übernahme und Vorfallwiederholung bereit.

## Wichtige Entscheidungen

- Braucht die Aufgabe adaptive Planung oder ist ein Workflow mit einem modellgestützten Schritt sicherer und günstiger?
- Welche Evidenz beweist den Abschluss unabhängig von der Erzählung des Modells?
- Welche Tools sind nötig und lassen sich Lesen, Entwurf und Ausführung trennen?
- Wessen Befugnis gilt für jede Ressource und externe Aktion?
- Welcher Zustand überlebt Wiederholung oder Neustart und welcher Kontext soll verfallen?
- Welche Grenzen stoppen Schleifen, Doppelarbeit, Kosten und Umfangsausweitung?
- Welche Handlung braucht Bestätigung, Vieraugenprinzip oder darf nie delegiert werden?
- Welche repräsentative Umgebung kann den vollständigen Verlauf vor Produktion testen?

## Risiken

- Prompt Injection in Dokument oder Tool-Ergebnis kann den Plan umlenken.
- Übermächtige Tools können Aktionen ausserhalb des beauftragten Ziels anbieten.
- Breite Rechte können einen richtigen Aufruf gegen falschen Mandanten oder Datensatz zulassen.
- Gesprächsverlauf und Geschäftszustand können nach Teilfehler auseinanderlaufen.
- Eine Wiederholung kann Zahlung, Nachricht, Löschung oder Zustandswechsel duplizieren.
- Der Agent kann scheinbar neue Pläne erzeugen, im Kreis laufen und Budget verbrauchen.
- Delegation zwischen Agenten kann Urheber und Autorisierung eines Entscheids verdecken.
- Langzeitgedächtnis kann sensible oder falsche Information über den Zweck hinaus behalten.
- Menschliche Freigabe kann zum Abnicken werden, wenn Kontext und Folge unklar sind.
- Erfolgsmetriken können Aufgabenabschluss belohnen und Regelbruch oder Aufräumarbeit ignorieren.

## Kennzahlen

- korrekt abgeschlossene Ergebnisse nach Fallfamilie und Version
- kritische Policy- und Berechtigungsverstösse vor und nach Ausführung
- Tool-Auswahl und Parametergültigkeit je Operation
- bestätigte, doppelte, kompensierte und verwaiste Wirkungen
- Schritte, Dauer, Modellnutzung und Kosten je erfolgreichem Ergebnis
- angemessen ausgelöste Stillstands-, Budget- und Sicherheitsstopps
- menschliche Genehmigung, Ablehnung, Änderung und Übernahme
- vor Produktionsausbau erkannte Verlaufsregressionen
- erfolgreiche Erholung nach Abhängigkeits-, Worker- und Tool-Ausfall
- aus Zustand, Version und Ereignis reproduzierbare Vorfälle

## Häufige Fragen

### Was ist agentische Softwareentwicklung?

Sie entwickelt Anwendungen, in denen ein Modell Zwischenschritte und Tools für ein begrenztes Ziel wählen darf. Dazu gehören Tool-Verträge, Berechtigung, Zustand, Gedächtnis, Stoppen, Evaluation, Beobachtung, menschliche Befugnis und Erholung, nicht nur ein Planungs-Prompt.

### Wann sollte ein Team einen KI-Agenten einsetzen?

Wenn variable Evidenz den nächsten sinnvollen Schritt schwer aufzählbar macht und das Ergebnis trotzdem messbar und begrenzbar ist. Bei stabilem Routing und Zustand ist ein deterministischer Workflow mit einem modellgestützten Schritt meist besser.

### Wie sichert man einen KI-Agenten?

Minimieren Sie Tools, Funktionen, Rechte und Autonomie. Erzwingen Sie Identität und Berechtigung ausserhalb des Modells, behandeln Sie Beobachtungen als nicht vertrauenswürdig, prüfen Sie Schemas, machen Sie Wirkungen idempotent, verlangen Sie passende Freigaben, begrenzen Sie Ressourcen und erhalten Sie Replay-Evidenz.

### Wie wird agentische Software getestet?

Mit repräsentativen Aufgabenwelten und vollständigen Verläufen. Prüfen Sie Erfolg, Policy, Tool-Parameter, Zustände, Budgets, Angriffe, Ausfälle, Erholung und externe Bestätigung. Ein guter Endsatz rechtfertigt keinen unsicheren Weg.


## Primärquellen

- [LLM06:2025 Excessive Agency](https://genai.owasp.org/llmrisk/llm062025-excessive-agency/), OWASP GenAI Security Project
- [Secure Software Development Practices for Generative AI](https://csrc.nist.gov/pubs/sp/800/218/a/final), National Institute of Standards and Technology
- [AI Risk Management Framework Core](https://airc.nist.gov/airmf-resources/airmf/5-sec-core/), National Institute of Standards and Technology