Lese- und Schreibrechte für KI-Agenten

Feste Scopes, ein klares Prinzip

read ist immer dabei, write erlaubt das Buchen — Rechnungsversand und Festschreibung sind eigene Rechte.

Jeder API-Schlüssel trägt feste Berechtigungsumfänge: read ist immer enthalten, write, send und finalize kommen nur hinzu, wenn Sie sie beim Anlegen wählen (für die REST-API zusätzlich webhooks). Der Scope ist fest an den Schlüssel gebunden und wird serverseitig geprüft — er lässt sich nicht per Aufruf-Parameter erweitern. Ein Agent kann also ausschließlich das ausführen, wofür sein Schlüssel freigeschaltet ist.

Das Leserecht (read) umfasst alle abfragenden Aufrufe: Stammdaten, Kontenrahmen, Saldenliste, Buchungsjournal, offene Posten, Rechnungen, Belege und Bankumsätze. Das Schreibrecht (write) erlaubt zusätzlich die verändernden Aufrufe — Buchungen anlegen und stornieren, Rechnungen ausstellen, Zahlungen, Belege und Bankumsätze buchen, Kasse, Anlagen, Rückstellungen, Abgrenzungen und Stammdaten pflegen. Den Versand von Rechnungen per E-Mail erlaubt erst send, die Festschreibung eines Zeitraums erst finalize.

Das Prinzip minimaler Rechte (least privilege) heißt konkret: Vergeben Sie standardmäßig read und heben Sie nur dort auf write an, wo der Agent tatsächlich buchen soll. Ein Auswertungs-Agent, der monatlich die BWA liest, braucht niemals write — und kann mit read schlicht keinen Schaden am Buchungsbestand anrichten.

Was ein Lese-Schlüssel kann — und niemals kann

Wofür Sie write brauchen

Sobald sich der Datenbestand ändert, ist Schreibrecht nötig.

• Eingangsrechnungen automatisch verbuchen lassen — als Soll/Haben-Buchung im Journal.
• Fehlbuchungen per Storno korrigieren, GoBD-konform und ohne Löschen.
• Ausgangsrechnungen aus Prompt-Vorgaben erstellen und verbuchen.
• Bankumsätze zuordnen und als Zahlung auf offene Posten buchen.
• Kurz: Bei jeder Änderung am Bestand ist write nötig — bei jeder reinen Abfrage nicht.

Die 91 MCP-Werkzeuge nach Scope

43 lesende und 45 schreibende Werkzeuge, dazu je eines für Rechnungsversand und Festschreibung sowie eines für die Übermittlung an ELSTER, dessen Recht derzeit noch nicht vergeben wird — dieselbe Scope-Logik wie in der REST-API.

Ein Schlüssel, eine Firma, ein Scope

Jeder Schlüssel beginnt mit dem Präfix jab_live_ und ist genau einer Gesellschaft zugeordnet. Die Firma leitet sich aus dem Schlüssel selbst ab — es gibt keinen Firmen-Parameter, den ein Agent setzen (oder verwechseln) könnte. Ein Schlüssel kann deshalb niemals in den Büchern einer anderen Mandantin landen.

Kombiniert mit dem Scope entsteht eine klare Matrix: read für Firma A, write für Firma A, read für Firma B und so fort. Praktisch heißt das etwa: Ihr monatlicher Reporting-Agent in ChatGPT erhält einen read-Schlüssel für Firma A, während die nächtliche Rechnungs-Automatisierung einen separaten write-Schlüssel für dieselbe Firma bekommt. Wir empfehlen, jedem Agenten und jeder Automatisierung einen eigenen Schlüssel zu geben — so widerrufen Sie im Ernstfall genau einen, ohne die übrigen Anbindungen zu stören.

Rechte in der Praxis vergeben

Zwei getrennte MCP-Anbindungen — eine nur lesend, eine schreibend. Beide nutzen die gehostete URL.

# Nur-Lese-Anbindung: der Agent darf abfragen, aber nie buchen
claude mcp add --transport http --scope user buchhaltung-read \
  "$MCP_URL" --header "Authorization: Bearer jab_live_…"   # read-Schlüssel

# Schreib-Anbindung: write-Scope für Buchung, Storno, Rechnung
claude mcp add --transport http --scope user buchhaltung-write \
  "$MCP_URL" --header "Authorization: Bearer jab_live_…"   # write-Schlüssel

# Den Scope legen Sie beim Erstellen des Schlüssels fest —
# er ist danach fest an den Schlüssel gebunden, nicht am Aufruf wählbar.

GoBD: Schreiben heißt nicht Löschen

Der write-Scope öffnet keine Hintertür an den Ordnungsmäßigkeitsregeln vorbei. Alle schreibenden Aufrufe laufen durch denselben Buchungskern wie die manuelle Erfassung in der Software — der Scope entscheidet nur, ob ein Agent diesen Kern überhaupt aufrufen darf.

Das bedeutet: Buchungen sind append-only und werden nach der Festschreibung nicht mehr verändert. Eine Korrektur erfolgt ausschließlich per Storno- oder Gegenbuchung, nie durch Löschen. Jede Buchung muss Soll = Haben erfüllen, sonst weist die API sie zurück. Ein Agent mit write kann also viel erledigen, aber die GoBD-konforme Historie nicht umschreiben — egal, mit welchem Prompt er angesteuert wird.

Häufige Fragen

Kann ein reiner Lese-Schlüssel aus Versehen buchen?

Nein. Der read-Scope ist serverseitig fest an den Schlüssel gebunden. Formuliert Ihr Agent trotzdem eine Buchung, weist die API den Aufruf ab, statt ihn auszuführen — es gibt keinen Parameter, mit dem sich das Leserecht zur Laufzeit auf Schreiben erweitern ließe.

Kann ich über einen write-Schlüssel den Jahresabschluss oder die E-Bilanz erstellen?

Nein. Mit einem write-Schlüssel bereiten Sie Buchungen, Salden und Rechnungen vor — die Datenbasis, aus der in der App der Jahresabschluss und die E-Bilanz werden. Steuermeldungen kann der Agent mit write amtlich prüfen und vorbereiten; die Übermittlung ans Finanzamt geschieht in der App über den Freigabe-Link, nicht durch den Agenten.

Welche MCP-Werkzeuge verlangen write?

Alle, die etwas verändern: Buchung anlegen und stornieren, Rechnungen ausstellen und buchen, Zahlungen, Belege, Bank, Kasse, Anlagen, Rückstellungen, Abgrenzungen und Stammdaten. Den Rechnungsversand gibt erst send frei, die Festschreibung erst finalize. Die lesenden Werkzeuge laufen mit einem read-Schlüssel — von der Saldenliste über das Buchungsjournal bis zu den Belegen.

Kann ein Agent mit write Buchungen löschen?

Nein. Auch mit Schreibrecht bleibt die Buchhaltung append-only. Korrekturen laufen per Storno- oder Gegenbuchung; festgeschriebene Buchungen werden nie gelöscht oder überschrieben. So bleibt die Historie GoBD-konform nachvollziehbar, egal welcher Agent den Schlüssel nutzt.

Sollte jeder Agent einen eigenen Schlüssel bekommen?

Ja. Vergeben Sie pro Agent oder Automatisierung einen eigenen jab_live_-Schlüssel mit dem passenden Scope. Dann widerrufen Sie im Zweifel genau diesen einen Zugang — die anderen Anbindungen, etwa Ihr Reporting in ChatGPT, laufen ungestört weiter. Und weil jeder Schlüssel an genau eine Firma gebunden ist, kann ein write-Schlüssel für Firma A nie in den Büchern von Firma B buchen.