Zum Hauptinhalt springen
Connic
Platform

Approvals

Geschützte Tool-Aufrufe erfordern eine menschliche Freigabe. Der Run pausiert, bis ein Teammitglied die Aktion genehmigt oder ablehnt. Approval-Gates gelten je Tool; Webhooks binden externe Systeme ein.

Zuletzt aktualisiert

So funktioniert es

Füge einen approval-Block zur Agent-YAML hinzu, um bestimmte Tools durch eine menschliche Freigabe abzusichern. Ruft der Agent ein geschütztes Tool auf, pausiert der Run und das Projekt-Team wird benachrichtigt.

Ausführungsablauf
1Der Agent führt Tools normal aus (Lookup, Query usw.)
2Der Agent ruft ein geschütztes Tool auf → der Run pausiert mit dem Status Awaiting Approval
3Die Anfrage wird über die aktivierten Mitgliederbenachrichtigungen und Projekt-Channels versendet
4Ein Mitglied mit approvals.decide genehmigt oder lehnt über Dashboard oder API ab
5Genehmigt: Der Run wird fortgesetzt, das Tool ausgeführt und der Agent macht an der unterbrochenen Stelle weiter
5Abgelehnt / Timeout (on_rejection: fail): Der Run schlägt mit dem Ablehnungsgrund fehl (Standard)
5Abgelehnt / Timeout (on_rejection: continue): Der Run wird fortgesetzt, das Tool gibt die Ablehnung zurück und der Agent reagiert auf die Ablehnung
Nur geschützte Tools pausieren den Run. Alle anderen Tools werden normal ausgeführt. Beim Fortsetzen eines Runs werden abgeschlossene Tool-Aufrufe nicht erneut ausgeführt.
Detail-Drawer eines Runs mit dem Status Awaiting Approval. Eine Approval Required Card zeigt das geschützte Tool orders.update_status, seine Parameter sowie die Buttons Approve und Reject.
Ein Run pausiert im Status Awaiting Approval. Beim Öffnen zeigt eine Approval Required Card das geschützte Tool, seine Parameter und die Aktionen Approve / Reject.

Quickstart

Füge einer beliebigen Agent-YAML einen approval-Block hinzu, um bestimmte Tools zu schützen:

agents/my-agent.yaml (snippet)
approval:
  tools:
    - order_tools.delete_order
    - db_delete
  timeout: 3600
  message: "Diese Aktion erfordert eine menschliche Freigabe."

Nach dem Deploy pausiert jeder Aufruf von order_tools.delete_order oder db_delete den Run und benachrichtigt das Projekt-Team. In der vollständigen Referenz zur Agent-Konfiguration stehen alle verfügbaren Optionen.

Vollständiges Beispiel

Ein vollständiger Agent mit einem ungeschützten und zwei freigabepflichtigen Tools:

agents/order-management/order-manager.yaml
version: "1.0"
name: order-manager
type: llm
model: connic/gpt-5.6-luna
description: "Verwaltet Bestellungen mit freigabepflichtigen destruktiven Aktionen"

system_prompt: |
  Du bist ein Assistent für die Bestellverwaltung.
  Verwende lookup_order, um Bestellungen zu finden, process_refund für Rückerstattungen
  und cancel_order für Stornierungen.

  Wenn ein Tool mit "awaiting_approval" antwortet, teile dem Nutzer mit,
  dass die Aktion auf eine menschliche Prüfung wartet.

temperature: 0.3

tools:
  - order_tools.lookup_order
  - order_tools.process_refund
  - order_tools.cancel_order

approval:
  tools:
    - order_tools.cancel_order
    - order_tools.process_refund
  timeout: 600
  message: "Diese Bestellaktion erfordert die Freigabe eines Managers."

In diesem Beispiel wird lookup_order ohne Einschränkung ausgeführt. Nur cancel_order und process_refund sind geschützt. Der Agent kann zunächst Bestelldetails abrufen und pausiert erst, wenn er eine destruktive Aktion ausführen will.

Bedingte Approvals

Approval-Tools unterstützen Bedingungsausdrücke mit derselben Syntax wie bedingte Tools. Ist eine Bedingung gesetzt, ist die Freigabe nur erforderlich, wenn der Ausdruck zu true ausgewertet wird. So lassen sich die tatsächlichen Parameter des Tool-Aufrufs und Kontext-Werte aus der Middleware berücksichtigen.

agents/order-manager.yaml (snippet)
approval:
  tools:
    - order_tools.cancel_order                                          # erfordert immer eine Freigabe
    - order_tools.process_refund: param.amount > 50 and not context.is_admin  # bedingt
  timeout: 600
  message: "Diese Bestellaktion erfordert die Freigabe eines Managers."
Expression-Syntax

Python-ähnliche Syntax: and, or, not; Vergleiche == != > < >= <=; Zugehörigkeit mit in und not in; Klammern zur Gruppierung; String-Literale in einfachen oder doppelten Anführungszeichen. Verschachtelte Objekte sind über Pfade mit Punktnotation wie context.user.role erreichbar. Ein einzelner Pfad wie context.active prüft, ob der Wert gesetzt und weder leer noch null oder false ist. Fehlt ein Feld, ist die Bedingung nicht erfüllt; es wird kein Fehler ausgelöst.

param.<key>
Die für diesen konkreten Aufruf an das Tool übergebenen Parameter. Zum Beispiel liest param.amount das Argument amount.
context.<key>
Werte aus dem Kontext des Runs, befüllt durch Middleware und vorherige Tools, sowie von Connic bereitgestellte Systemfelder (run_id, agent_name usw.). Dasselbe Binding wie bei bedingten Tools.
Kann eine Bedingung nicht ausgewertet werden, etwa weil ein Parameter fehlt, ist eine Freigabe erforderlich.

Verhalten bei Ablehnung

Standardmäßig beendet eine abgelehnte Freigabe den Run mit dem Status FAILED. Setze on_rejection: continue, damit der Agent sich stattdessen anpassen kann. Der Tool-Aufruf gibt eine Ablehnung an das LLM zurück; der Agent kann einen alternativen Ansatz versuchen, den Nutzer informieren oder die Aktion überspringen.

agents/order-manager.yaml (snippet)
approval:
  tools:
    - order_tools.cancel_order
    - order_tools.process_refund: param.amount > 50
  timeout: 600
  message: "Diese Bestellaktion erfordert die Freigabe eines Managers."
  on_rejection: continue   # der Agent passt sich an, statt fehlzuschlagen

Modi

  • fail (Standard): Der Run endet sofort mit einer Fehlermeldung, die den Ablehnungsgrund enthält.
  • continue: Der Run wird fortgesetzt und der Tool-Aufruf gibt eine Meldung wie „Tool 'X' wurde abgelehnt: Grund. Das Tool wurde nicht ausgeführt.“ zurück. Der Agent sieht sie als Antwort des Tools und kann sein Verhalten anpassen. Derselbe Modus gilt, wenn das Approval abläuft.
Ruft der Agent im Modus continue dasselbe abgelehnte Tool erneut auf, erhält er dieselbe Ablehnung, ohne dass eine neue Approval-Anfrage erstellt wird. Die Konfiguration max_iterations des Agenten verhindert Endlosschleifen bei Wiederholungsversuchen.

Approvals verwalten

Die Seite Approvals in der Sidebar zeigt alle Approval-Anfragen für das aktuelle Environment. Ausstehende Approvals stehen oben.

Die Seite Approvals mit einer Liste der Approval-Anfragen. Oben stehen drei ausstehende Anfragen mit aktiven Buttons Approve und Reject; danach folgen abgeschlossene Anfragen mit deaktivierten Aktionen.
Die Seite Approvals: Ausstehende Anfragen werden mit aktiven Buttons Approve / Reject nach oben sortiert. Jede Zeile zeigt Agent, geschütztes Tool, Status, Erstellungszeitpunkt und die Person, die sie bearbeitet hat.
Approve: Der Run wird fortgesetzt und das Tool mit den ursprünglichen Parametern ausgeführt.
Reject: Mit on_rejection: fail (Standard) endet der Run. Mit on_rejection: continue wird der Run fortgesetzt und der Agent reagiert auf die Ablehnung. Beide Modi akzeptieren optional einen Grund.
Timeout: Wird innerhalb des konfigurierten Timeouts keine Entscheidung getroffen, schlägt der Run automatisch fehl (oder wird fortgesetzt, wenn on_rejection: continue gesetzt ist).

Anfragen lassen sich auch im Run-Detail-Drawer genehmigen oder ablehnen. Klicke auf eine beliebige Zeile in der Approvals-Tabelle oder öffne auf der Seite Agent Runs einen Run mit dem Status „Awaiting Approval“. Die Approval Card zeigt Tool-Name, Parameter und Aktionsbuttons.

approvals.view gewährt Zugriff auf Approval-Anfragen, approvals.decide erlaubt Genehmigen und Ablehnen und approvals.configure erlaubt die Konfiguration des Weiterleitung von Benachrichtigungen.

Benachrichtigungen

Wenn ein Approval erforderlich ist, erhalten Projekt-Mitglieder standardmäßig eine E-Mail und eine In-App-Benachrichtigung. Jedes Mitglied kann diese Einstellungen in den Benachrichtigungseinstellungen des Projekts ändern. Der Drawer Notification Config auf der Seite Approvals konfiguriert das Routing über Projekt Channels:

  • Approvals für bestimmte Agenten (oder alle Agenten) an Projekt Channels weiterleiten

Channel-Integration

Enterprise-Projekte können wiederverwendbare Channels für Benachrichtigungen, Approvals sowie Audit- oder Log-Drains nutzen. So werden Approval-Anfragen an einen Channel weitergeleitet:

  1. Öffne Projekt-Settings → Notifications und füge einen Channel hinzu.
  2. Konfiguriere den HTTPS-Endpoint des Webhooks und optional ein Signing Secret.
  3. Wähle auf der Seite Approvals ein Environment aus und öffne Notification Config.
  4. Aktiviere den Channel und wähle aus, für welche Agenten er Approvals erhält. Lass die Auswahl für alle Agenten leer.

Webhook Channels senden die folgende Payload an einen HTTPS-Endpoint. Ein optionales Signing Secret fügt die Header X-Connic-Signature und X-Connic-Timestamp hinzu, damit der Empfänger jeden Request verifizieren kann. Die zuständigen Personen genehmigen oder lehnen in Connic oder über die REST API ab.

Webhook POST payload
{
  "type": "approval_requested",
  "approval_id": "a1b2c3d4-...",
  "run_id": "e5f6a7b8-...",
  "agent_name": "order-manager",
  "tool_name": "order_tools.cancel_order",
  "tool_params": {
    "order_id": "ORD-1234",
    "reason": "Kunde hat die Stornierung angefordert"
  },
  "message": "Diese Bestellaktion erfordert die Freigabe eines Managers.",
  "timeout": 600,
  "environment_id": "f9e8d7c6-...",
  "environment_name": "Produktion",
  "project_id": "b4c3d2e1-...",
  "channel_id": "c5d4e3f2-...",
  "channel_name": "Bereitschafts-Approvals",
  "created_at": "2026-04-05T10:30:00Z"
}

Mehrere Approvals

Ruft ein Agent mehrere geschützte Tools nacheinander auf, löst jedes einen eigenen Ablauf mit Pause und Freigabe aus. Der Run durchläuft folgende Status:

Started → Awaiting Approval → Queued → Started → Awaiting Approval → ... → Completed

Bei jeder Fortsetzung werden der gespeicherte Gesprächsverlauf und Tool-Zustand geladen, ohne abgeschlossene Tool-Aufrufe erneut auszuführen.

API

Approvals können über die REST API verwaltet werden. API Keys verwenden approvals.view zum Auflisten von Anfragen, approvals.decide zum Genehmigen oder Ablehnen und approvals.configure zur Verwaltung des Weiterleitung von Benachrichtigungen.

Approvals API öffnen

Audit Trail

Jede Approval-Entscheidung wird mit Aktion, entscheidender Person, Tool-Name und Parametern im Audit Log erfasst. Approval-Traces erscheinen außerdem in der Trace-Ansicht des Runs und zeigen Wartezeit und Angaben zur prüfenden Person.