Directus KI-Agenten-Workflow: RBAC-sichere Tools für LLMs

KI-Agenten sind nur so gut wie die Werkzeuge, auf die sie zugreifen dürfen. Genau hier wird Directus spannend: Als Daten-Plane verbindet Directus strukturierte Inhalte, Rollenrechte, APIs, Flows, Activity-Logs und MCP zu einer robusten Grundlage für produktive AI-Agent-Workflows.

Der entscheidende Vorteil: Agenten arbeiten nicht mit einem unkontrollierten Admin-Zugang, sondern über klar begrenzte Rollen, Service-Accounts und Permissions.

Das macht Directus zu einem starken Backend für Unternehmen, die LLMs nicht nur chatten lassen wollen, sondern sicher handeln lassen möchten.

Was unterscheidet einen Agenten von einem Chat-Assistant?

Ein Chat-Assistant beantwortet Fragen. Ein Agent plant, handelt, prüft Ergebnisse und entscheidet über nächste Schritte.

Ein klassischer Assistant sagt:

„Hier ist eine mögliche Antwort auf das Support-Ticket.“

Ein Agent kann zusätzlich:

• das Ticket analysieren,
• Kundendaten prüfen,
• einen Antwortentwurf erzeugen,
• eine interne Freigabe starten,
• den Status aktualisieren,
• die Aktion protokollieren.

Der Unterschied liegt also nicht im Modell allein, sondern in der Tool-Schicht dahinter.

Planen, handeln und iterieren

Ein produktiver KI-Agent durchläuft meist mehrere Schritte:

1. Ziel verstehen
2. Kontext laden
3. passende Tools auswählen
4. Aktion ausführen
5. Ergebnis prüfen
6. nächsten Schritt ableiten

Dafür braucht er Zugriff auf Systeme wie CRM, CMS, Datenbanken, Tickets, Dateien oder Workflows.

Genau an dieser Stelle wird ein kontrolliertes Backend notwendig. Ohne Zugriffskontrolle wird aus Automatisierung schnell ein Sicherheitsrisiko.

Anforderungen ans Backend: RBAC, Audit und Replay

Ein produktives Agent-Backend muss mindestens drei Anforderungen erfüllen:

RBAC: Der Agent darf nur sehen und tun, was seine Rolle erlaubt.

Audit: Jede Aktion muss nachvollziehbar sein.

Replay: Lange oder fehleranfällige Aufgaben müssen wiederholbar sein, ohne doppelte Seiteneffekte auszulösen.

Directus deckt RBAC und Audit direkt ab. Für langlebige, asynchrone Prozesse ergänzt Inngest die notwendige Durability.

Warum Directus als Daten-Plane?

Directus eignet sich besonders gut als Daten-Plane für KI-Agenten, weil es auf vorhandenen SQL-Datenbanken aufsetzt und daraus sofort APIs, Rollenrechte, Admin-Oberflächen und Automatisierungen erzeugt.

Statt für jeden Agenten eine eigene Backend-Schicht zu bauen, wird Directus zur zentralen Schnittstelle zwischen LLM, Datenbank, Business-Logik und menschlicher Freigabe.

Auto-APIs auf jeder SQL-Datenbank

Directus generiert automatisch REST- und GraphQL-APIs auf Basis deines Datenmodells.

Für Agenten bedeutet das:

• strukturierter Datenzugriff,
• einheitliche API-Schicht,
• weniger Custom-Code,
• schnellere Tool-Definitionen.

Ob Support-Tickets, Produkte, Leads, Bestellungen oder Content-Items: Alles kann als Collection modelliert und kontrolliert verfügbar gemacht werden.

Granulare Permissions pro Service-Account

Der wichtigste Baustein für RBAC-sicheres Agent-Tooling ist ein eigener Service-Account pro Agent.

Beispiel:

So erhält jeder Agent nur die Rechte, die er wirklich benötigt.

Audit-Log out-of-the-box

Directus bietet ein Activity-Log, mit dem Aktionen, Nutzer, Systemereignisse und Änderungen nachvollziehbar bleiben. Für Agenten ist das zentral, weil jede automatisierte Handlung später erklärbar sein muss. (directus.com – Activity log⁠)

Ein guter Agenten-Workflow speichert deshalb immer:

• Agent-ID,
• Service-Account,
• Session-ID,
• Tool-Aufruf,
• betroffene Collection,
• vorheriger Status,
• neuer Status.

MCP für Tool-Exposition

Das Model Context Protocol ist ein offener Standard, um LLM-Anwendungen mit externen Datenquellen und Tools zu verbinden. (Model Context Protocol⁠)

Directus stellt seit Version 11.12 einen eingebauten MCP-Server bereit, der manuell aktiviert werden muss. Laut Directus-Dokumentation lässt sich ein KI-Assistant damit in wenigen Schritten verbinden. (directus.com – Installation⁠)

Damit wird Directus nicht nur API-Backend, sondern direkt Tool-Schicht für LLMs.

Referenz-Architektur

Eine robuste Agenten-Architektur trennt klar zwischen Denken, Tool-Zugriff, langlebigen Tasks und menschlicher Freigabe.

User
↓
LLM / Agent Runtime
↓
MCP Tool Layer
↓
Directus Service Account
↓
Directus Collections / Files / Flows
↓
Inngest für lange Tasks
↓
Directus Activity Log + Agent Session State

LLM → MCP-Tools → Directus

Das LLM entscheidet, welches Tool benötigt wird. Der MCP-Server stellt die verfügbaren Directus-Aktionen bereit. Directus prüft anschließend über Rolle und Permissions, ob die Aktion erlaubt ist.

Wichtig:

Ein MCP-Tool ist kein Freifahrtschein. Es sollte immer an konkrete Directus-Permissions gebunden sein.

Heavy Tasks → Inngest → Directus-Update

Nicht jede Aufgabe gehört synchron in den Chat.

Beispiele für Heavy Tasks:

• Embeddings erzeugen,
• Bildanalyse,
• PDF-Verarbeitung,
• Datenanreicherung,
• externe API-Abfragen,
• Batch-Updates.

Solche Prozesse sollten asynchron laufen. Directus dokumentiert selbst Integrationsmuster mit Inngest für langlebige AI-Workflows. (directus.com – Invinible AI content workflows⁠)

State-Collection für Agent-Sessions

Für produktive Agenten empfiehlt sich eine eigene Collection, zum Beispiel agent_sessions.

Typische Felder:

Diese Collection macht Agenten nachvollziehbar und wiederaufnehmbar.

Human-in-the-Loop über Flows

Nicht jede Aktion sollte vollautomatisch passieren.

Directus Flows eignen sich für Freigabeprozesse:

• Antwortentwurf erzeugen,
• Manager-Freigabe anfordern,
• Status nach Freigabe ändern,
• finale Aktion ausführen.

So bleibt der Mensch dort im Prozess, wo Risiko, Tonalität oder rechtliche Wirkung relevant sind.

RBAC-sicheres Tool-Design

RBAC-sicheres Agent-Tooling ist das zentrale Designprinzip.

Ein Agent sollte niemals direkt mit einem Admin-Token arbeiten. Stattdessen bekommt er eine Rolle, deren Rechte exakt zu seiner Aufgabe passen.

Pro Agent ein Service-Account

Verwende einen separaten Service-Account pro Agent.

Nicht: agent_all_access

Besser:

agent_support_readonly
agent_support_draft_writer
agent_content_editor
agent_ops_monitor

So kannst du Rechte getrennt vergeben, rotieren und auditieren.

Permissions auf Item-Level einschränken

Item-Level-Permissions verhindern, dass Agenten alle Datensätze sehen.

Beispiele:

• Support-Agent sieht nur Tickets mit status != archived.
• Sales-Agent sieht nur Leads der eigenen Region.
• Content-Agent sieht nur Artikel im Status draft.
• Finance-Agent sieht keine personenbezogenen Notizen.

Das ist der Unterschied zwischen „Agent darf Tickets lesen“ und „Agent darf genau die richtigen Tickets lesen“.

Sensible Felder per Field-Permission ausblenden

Nicht alle Felder einer Collection müssen für Agenten sichtbar sein.

Beispiele für Felder, die oft verborgen werden sollten:

• interne Margen,
• private Notizen,
• Gesundheitsdaten,
• Zahlungsinformationen,
• personenbezogene Identifikatoren,
• vertrauliche Vertragsdetails.

Ein Agent braucht meistens Kontext, aber nicht jedes Detail.

Maskierungs-Strategien

Zusätzlich zu Field-Permissions können Daten maskiert werden.

Beispiele:

Maskierung ist besonders wichtig, wenn externe LLM-Anbieter beteiligt sind.

Durability mit Inngest

Agenten-Workflows brechen in der Praxis oft nicht wegen des LLMs, sondern wegen Infrastrukturproblemen.

Typische Probleme:

• API-Timeout,
• Rate-Limit,
• Modellfehler,
• Netzwerkfehler,
• doppelte Ausführung,
• unvollständiger Zwischenstand.

Durability bedeutet: Ein Workflow kann pausieren, neu starten und kontrolliert fortgesetzt werden.

Lange Tasks auslagern

Alles, was länger als wenige Sekunden dauert, sollte nicht im Chat-Kontext blockieren.

Beispiele:

• „Analysiere alle PDFs dieses Kunden.“
• „Erzeuge Embeddings für 5.000 Artikel.“
• „Bewerte alle offenen Tickets nach Dringlichkeit.“
• „Generiere Produktbeschreibungen für 300 SKUs.“

Der Agent stößt den Prozess an. Inngest verarbeitet ihn. Directus speichert Status und Ergebnis.

Step-Functions mit Replay

Ein Inngest-Workflow kann in einzelne Schritte zerlegt werden:

1. Kontext laden
2. Daten validieren
3. LLM-Aufruf durchführen
4. Ergebnis prüfen
5. Directus aktualisieren
6. Benachrichtigung senden

Wenn Schritt 4 fehlschlägt, muss nicht alles neu laufen. Genau dafür ist Replay wichtig.

Korrelationsfeld in Directus speichern

Jeder Agentenlauf sollte eine correlation_id erhalten.

Diese ID wird gespeichert in:

• Directus agent_sessions,
• Inngest-Run,
• Logs,
• Tool-Aufrufen,
• externen API-Requests.

Damit lassen sich Fehler später über alle Layer hinweg verfolgen.

Beobachtbarkeit & Audit

Produktive Agenten brauchen Observability.

Nicht nur für Entwickler, sondern auch für Fachbereiche, Compliance und Support.

Activity-Log pro Aktion

Jede Agentenaktion sollte sichtbar sein:

• Wer oder welcher Agent hat gehandelt?
• Welche Collection war betroffen?
• Was wurde geändert?
• Wann wurde die Änderung vorgenommen?
• Mit welchem Tool-Aufruf?

Das Activity-Log von Directus ist dafür der erste Ankerpunkt. (directus.com -Activity log⁠)

Tracing-IDs durch alle Layer

Eine gute Trace-Kette sieht so aus

agent_session.id
→ mcp_tool_call.id
→ inngest_run.id
→ directus_activity.id
→ external_api_request.id

So wird ein Agentenlauf nicht zur Blackbox.

Anomalie-Erkennung

Sinnvolle Warnsignale:

• ungewöhnlich viele Schreibzugriffe,
• Zugriff außerhalb erwarteter Collections,
• wiederholte Permission-Fehler,
• viele fehlgeschlagene Tool-Aufrufe,
• plötzliche Token-Nutzungsspitzen.

Agenten sollten nicht nur funktionieren, sondern beobachtbar bleiben.

End-to-End-Beispiel: Customer-Support-Agent

Ein Support-Agent ist ein gutes Beispiel, weil er Daten lesen, priorisieren, schreiben und teilweise eskalieren muss.

Architektur

Kunde schreibt Anfrage
↓
Ticket entsteht in Directus
↓
Support-Agent wird gestartet
↓
Agent liest Ticket + Kundendaten
↓
Agent klassifiziert Anliegen
↓
Agent erstellt Antwortentwurf
↓
Human Review per Flow
↓
Antwort wird freigegeben
↓
Ticketstatus wird aktualisiert

Tool-Inventar

Das ist RBAC-sicheres Agent-Tooling in der Praxis: Jedes Tool entspricht einer eng begrenzten Permission.

Beispiel-Konversatio

User: Prüfe bitte das Ticket #4821.

Agent:
Ich lade Ticket #4821, prüfe Kundensegment und bisherige Kommunikation.

Tool: read_ticket
Tool: read_customer_summary

Agent:
Das Anliegen betrifft eine fehlerhafte Rechnung. Ich erstelle einen Antwortentwurf und markiere das Ticket als "Review erforderlich".

Tool: create_reply_draft
Tool: update_ticket_status

Wichtig: Der Agent sendet nicht automatisch die Antwort. Er erstellt nur einen Entwurf und startet die Freigabe.

Sicherheits-Tests

Vor Produktivbetrieb sollte jeder Agent getestet werden:

Diese Tests sind genauso wichtig wie Prompt-Tests.

Anti-Patterns

Admin-Token für Agenten

Der häufigste Fehler ist ein Admin-Token im LLM-Client.

Warum gefährlich?

• keine echte Begrenzung,
• schwer auditierbar,
• hohes Schadenspotenzial,
• Risiko bei Prompt Injection.

Besser: Service-Account mit minimalen Rollenrechten.

Synchrone Long-Tasks

Ein Agent sollte keine minutenlangen Aufgaben im Chat-Kontext blockieren.

Problematisch:

• Timeouts,
• verlorene Zwischenergebnisse,
• doppelte Ausführungen,
• schlechte Nutzererfahrung.

Besser: Long-Tasks an Inngest auslagern und Status in Directus speichern.

Fehlende Idempotenz

Wenn ein Agent dieselbe Aktion zweimal ausführt, darf daraus kein Schaden entstehen.

Beispiel:

Nicht: Sende Rechnung erneut.

Besser: Erstelle Versandauftrag mit eindeutiger idempotency_key. Wenn key bereits existiert, keine neue Aktion ausführen.

Idempotenz ist Pflicht für produktive Agenten.

Zu breite Tool-Namen

Schlecht: update_customer

Besser: update_customer_support_note

Je konkreter das Tool, desto leichter lässt es sich absichern.

Kein Human-in-the-Loop

Agenten sollten nicht alles allein entscheiden.

Besonders bei:

• rechtlichen Aussagen,
• Kündigungen,
• Zahlungen,
• Kundennachrichten,
• medizinischen oder finanziellen Themen,
• öffentlichen Veröffentlichungen.

Hier gehört ein Mensch in den Freigabeprozess.

Checkliste: RBAC-sichere KI-Agenten auf Directus

• eigener Service-Account pro Agent
• keine Admin-Tokens
• minimale Rollenrechte
• Item-Level-Permissions
• Field-Permissions für sensible Daten
• Activity-Log aktiv nutzen
• agent_sessions Collection anlegen
• Korrelations-ID speichern
• Long-Tasks an Inngest auslagern
• Human-in-the-Loop für riskante Aktionen
• Idempotenzschlüssel verwenden
• Permission-Tests vor Produktivbetrieb durchführen

Fazit

Directus ist ein starkes Backend für produktive KI-Agenten, weil es genau die Bausteine mitbringt, die in Agenten-Projekten oft fehlen: strukturierte Daten, Auto-APIs, Rollenrechte, Field-Permissions, Flows, Activity-Logs und MCP.

In Kombination mit Inngest entsteht daraus eine robuste Architektur:

• LLMs planen und entscheiden,
• MCP exponiert kontrollierte Tools,
• Directus erzwingt RBAC,
• Inngest verarbeitet langlebige Tasks,
• Flows ermöglichen Human-in-the-Loop,
• Activity-Logs schaffen Nachvollziehbarkeit.

Das Ergebnis ist kein experimenteller Chatbot, sondern ein RBAC-sicherer Agenten-Workflow, der sich produktiv betreiben lässt.

Bereit für den ersten Agenten? Starte mit dem Directus MCP Server Setup und binde Claude, ChatGPT, Cursor oder VS Code sicher an deine Directus-Instanz an.

FAQ

Wie schränke ich KI-Agenten in Directus ein?

Am besten über eigene Service-Accounts, granulare Rollenrechte, Item-Level-Permissions und Field-Permissions. Jeder Agent sollte nur die Collections, Items und Felder sehen oder verändern dürfen, die er für seine Aufgabe benötigt.

Brauche ich Inngest für Agenten?

Nicht zwingend. Für einfache, kurze Agentenaktionen genügt Directus mit MCP und Flows. Inngest wird besonders dann sinnvoll, wenn Aufgaben lange laufen, wiederholt werden müssen oder Replay, Retries und Durability benötigen.

Wie debugge ich fehlerhaftes Agent-Verhalten?

Nutze eine Kombination aus Directus Activity-Log, Agent-Session-Collection, Tool-Call-Logs, Inngest-Run-IDs und Korrelations-IDs. So lässt sich nachvollziehen, welcher Agent welches Tool mit welchem Ergebnis aufgerufen hat.

Kann ich mehrere Agenten parallel laufen lassen?

Ja. Dafür sollte jeder Agent einen eigenen Service-Account, eine eigene Rolle und idealerweise eine eigene Agent-Session-Kategorie erhalten. So bleiben Rechte, Logs und Verantwortlichkeiten sauber getrennt.