API-Schlüssel absichern

API-Schlüssel für KI-Agenten sicher verwalten

Ein KI-Agent ist nur so vertrauenswürdig wie der Schlüssel, den Sie ihm geben. Der API-Zugang zu Ihrer Buchhaltung läuft über einen Bearer-Schlüssel mit dem Präfix jab_live_, der nach dem Anlegen ein einziges Mal im Klartext erscheint und danach nur noch als Hash existiert. Auf dieser Seite lesen Sie, wie Sie einen solchen Schlüssel richtig ausstellen, ihn auf Lese- oder Schreibrecht begrenzen, befristen und jederzeit widerrufen — damit Ihr eigener Agent präzise das darf, was er soll, und nichts darüber hinaus.

Wie der jab_live_-Schlüssel aufgebaut ist

Der Schlüssel ist ein reines Zugangsgeheimnis. Vier Eigenschaften bestimmen, warum er sicher zu handhaben ist.

Präfix jab_live_

Jeder produktive Schlüssel beginnt mit jab_live_. Das Präfix macht ihn in Protokollen und Konfigurationen sofort erkennbar und lässt sich als Muster in einem Secret-Scanner hinterlegen, damit ein versehentlich eingecheckter Schlüssel auffällt, bevor er Schaden anrichtet.

Nur einmal angezeigt

Der vollständige Schlüssel erscheint genau einmal — direkt nach dem Anlegen. Danach ist er nicht mehr abrufbar. Kopieren Sie ihn sofort in einen Passwort-Manager oder eine Umgebungsvariable; wer ihn verliert, legt einfach einen neuen an und widerruft den alten.

Als Hash gespeichert

Gespeichert wird nie der Klartext, sondern nur ein SHA-256-Hash sowie ein kurzes Präfix zur Wiedererkennung in der Übersicht. Selbst ein Blick in die Datenbank gibt den Schlüssel nicht preis — aus dem Hash lässt er sich nicht zurückrechnen, das Original besitzen nur Sie.

Ein Schlüssel, eine Firma

Die Gesellschaft ist fest an den Schlüssel gebunden und wird serverseitig aus ihm abgeleitet. Es gibt keinen Firmen-Parameter, den ein Aufruf setzen könnte. Für zwei Mandanten brauchen Sie zwei Schlüssel — eine Verwechslung über Firmengrenzen hinweg ist damit ausgeschlossen.

Lese- oder Schreibrecht: der Scope am Schlüssel

Der Scope ist eine feste Eigenschaft des Schlüssels und entscheidet, wie tief ein Agent eingreifen darf. Vergeben Sie ihn so eng wie möglich.

Beim Anlegen legen Sie fest, ob der Schlüssel nur lesen oder auch schreiben darf. Ein reiner Lese-Schlüssel deckt die zehn lesenden der insgesamt 14 MCP-Werkzeuge ab: Stammdaten, Wirtschaftsjahre, Kontenrahmen, das Buchungsjournal als Liste wie als Einzelbeleg, Saldenliste, offene Posten, Ausgangs- und Eingangsrechnungen sowie Bankumsätze. Für Auswertungen, eine BWA-Abfrage oder eine Offene-Posten-Prüfung reicht das vollständig aus — und der Agent kann per Konstruktion keinen einzigen Buchungssatz verändern.

Erst ein Schlüssel mit Schreibrecht schaltet die vier schreibenden Werkzeuge frei: Buchung anlegen, Storno, Ausgangsrechnung erstellen und Eingangsrechnung verbuchen. Geben Sie dieses Recht nur dem Agenten, der tatsächlich buchen soll. Ein reines Leseskript für den Steuerberater, ein Reporting-Ablauf oder ein Test mit einer neuen Client-Software bekommt einen Lese-Schlüssel — so bleibt der schreibende Zugriff auf genau die eine Stelle beschränkt, an der Sie ihn brauchen.

Ein Lese-Schlüssel lässt sich nachträglich nicht heimlich zu einem Schreib-Schlüssel machen. Der Scope steht mit dem Schlüssel fest; brauchen Sie mehr Rechte, stellen Sie bewusst einen neuen aus. Diese Trennung ist die wichtigste einzelne Schutzmaßnahme, wenn Sie mehreren Agenten oder Personen Zugang geben.

Befristen und widerrufen

Ein Schlüssel muss nicht ewig gelten. Kurze Laufzeiten und ein sofortiger Widerruf halten das Risiko klein.

  • Ablaufdatum setzen: Vergeben Sie beim Anlegen ein Verfallsdatum, wenn der Zugang nur für ein Projekt, eine Prüfung oder einen Testzeitraum gedacht ist. Nach Ablauf lehnt die API den Schlüssel automatisch ab, ohne dass Sie eingreifen müssen.
  • Sofort widerrufen: Jeder Schlüssel lässt sich mit einem Klick sperren. Der Widerruf wirkt umgehend — der nächste Aufruf des Agenten wird abgewiesen, ohne dass Sie ein Passwort ändern oder andere Zugänge anfassen müssen.
  • Getrennt ausstellen: Legen Sie pro Agent, Person oder Ablauf einen eigenen Schlüssel an. So widerrufen Sie gezielt genau den einen, der kompromittiert wurde, und alle anderen laufen ungestört weiter.
  • Nutzung im Blick behalten: In der Übersicht sehen Sie Name, Präfix, Scope, Erstelldatum und die letzte Verwendung jedes Schlüssels. Ein Zugang, der seit Monaten nicht mehr benutzt wurde, gehört widerrufen.
  • Rotieren statt aussitzen: Tauschen Sie langlebige Schlüssel regelmäßig aus — neuen anlegen, im Agenten hinterlegen, alten widerrufen. Weil vom Original nur ein Hash existiert, ist Rotation der einzige saubere Weg, ein Geheimnis zu erneuern.

Den Schlüssel im Agenten hinterlegen

Der Schlüssel gehört in eine Umgebungsvariable, nicht in den Quellcode und nicht in eine geteilte Konfigurationsdatei. Der Agent ist Ihr Werkzeug — Claude Code, Claude Desktop, Cursor, ein n8n-Ablauf oder ein eigenes Skript — und läuft in Ihrem Rahmen, nicht in unserer Software.

# Schlüssel als Umgebungsvariable halten — nie im Repository committen
export JAB_KEY="jab_live_…"

# Gehosteten MCP-Endpunkt anbinden (URL steht in der Buchhaltung unter API-Zugang)
claude mcp add --transport http buchhaltung \
  "$MCP_URL" --header "Authorization: Bearer $JAB_KEY"

Best Practices für den Bearer-Schlüssel

Ein Bearer-Schlüssel ist ein Inhaberpapier: Wer ihn hat, darf handeln. Behandeln Sie ihn wie ein Passwort.

Nie im Klartext ablegen

Kein Schlüssel im Quellcode, in Chatverläufen, Screenshots oder unverschlüsselten Notizen. Nutzen Sie Umgebungsvariablen oder einen Passwort-Manager und geben Sie ihn nur über den Authorization-Header als Bearer weiter.

Getrennt pro Zweck

Ein Schlüssel je Agent und Aufgabe statt eines universellen Master-Schlüssels. Das begrenzt den Schaden bei einem Leck und macht den Widerruf chirurgisch statt kollateral.

Minimaler Scope

Vergeben Sie Schreibrecht nur, wenn wirklich gebucht wird. Im Zweifel Lese-Schlüssel — er kann per Definition nichts verändern und ist damit die risikoärmste Standardwahl.

Widerruf einplanen

Legen Sie fest, wer einen Schlüssel bei Verdacht sperren darf, und dokumentieren Sie, welcher Schlüssel zu welchem Agenten gehört. Ein benannter Schlüssel ist schneller widerrufen als ein anonymer.

GoBD bleibt serverseitig erzwungen

Ein Schreib-Schlüssel öffnet keine Hintertür an den Buchführungsregeln vorbei.

Alle schreibenden Aufrufe eines Agenten laufen durch denselben Buchungskern wie die manuelle Erfassung in der Anwendung. Festgeschriebene Buchungen werden nicht gelöscht, sondern storniert; jede Buchung erfüllt Soll = Haben; das Journal ist append-only und bleibt lückenlos nachvollziehbar. Der Schlüssel entscheidet, ob der Agent schreiben darf — er entscheidet nie, ob die GoBD-Regeln gelten.

Das bedeutet auch: Selbst ein voll berechtigter Schreib-Schlüssel kann nichts anrichten, was Sie nicht per Storno korrigieren könnten. Ein kompromittierter Schlüssel führt zu unerwünschten, aber nachvollziehbaren und rückabwickelbaren Buchungen — nicht zu einer stillen Manipulation der Historie. Der Widerruf stoppt weitere Aufrufe, die Festschreibung bewahrt die Beweiskraft der bereits erfassten Daten.

Häufige Fragen

Was passiert, wenn ich den Schlüssel verliere oder er geleakt wird?

Widerrufen Sie ihn sofort in der Übersicht — der Widerruf wirkt umgehend, der nächste Aufruf des Agenten wird abgewiesen. Legen Sie danach einen neuen Schlüssel an und hinterlegen Sie ihn im Agenten. Weil nur ein SHA-256-Hash gespeichert ist, gibt es keinen Weg, den alten Klartext wiederherzustellen; Ersetzen und Widerrufen ist der saubere Ablauf. Und weil jeder Schlüssel für genau eine Firma gilt, bleibt der Vorfall auf diese eine Gesellschaft begrenzt.

Kann ein Lese-Schlüssel doch Buchungen anlegen?

Nein. Der Scope steht fest mit dem Schlüssel. Ein Lese-Schlüssel erreicht ausschließlich die zehn lesenden Werkzeuge; die vier schreibenden — Buchung, Storno, Ausgangsrechnung, Eingangsrechnung — verlangen einen Schlüssel mit Schreibrecht und werden andernfalls serverseitig verweigert. Ein nachträgliches Hochstufen ist nicht vorgesehen; für mehr Rechte stellen Sie bewusst einen neuen Schlüssel aus.

Kann der Agent mit dem Schlüssel eine E-Bilanz oder einen Jahresabschluss übermitteln?

Nein. Die API ist reine Buchhaltung. Der Agent liest und schreibt Buchungsdaten — Journal, Saldenliste, offene Posten, Rechnungen, Bank. Er bereitet damit die Zahlen vor, aus denen später in der Anwendung ein Abschluss entsteht. Der Jahresabschluss, die E-Bilanz oder eine Steuererklärung werden nicht über die API erstellt oder übermittelt; das geschieht im dafür vorgesehenen Bereich der Anwendung, nicht durch einen Schlüssel.

Sieht der Anbieter meinen Klartext-Schlüssel?

Nein. Der vollständige Schlüssel wird genau einmal beim Anlegen angezeigt und danach nie wieder. Gespeichert werden nur ein SHA-256-Hash und ein kurzes Präfix zur Wiedererkennung in der Übersicht. Aus dem Hash lässt sich der Schlüssel nicht zurückrechnen — das Original existiert ausschließlich dort, wo Sie es hinterlegt haben.

Gilt ein Schlüssel für mehrere Firmen?

Nein, ein Schlüssel gilt immer für genau eine Gesellschaft. Die Firma wird serverseitig aus dem Schlüssel abgeleitet und ist kein Parameter, den ein Aufruf setzen könnte. Wer mehrere Mandanten betreut, legt pro Firma einen eigenen Schlüssel an — das trennt die Datenbestände sauber und macht einen Widerruf gezielt auf einen einzelnen Mandanten möglich.

Brauche ich das npm-Paket, um loszulegen?

Nein. Das Paket @jahresabschluss/buchhaltung-mcp ist noch nicht veröffentlicht. Der verlässliche Weg ist der gehostete MCP-Endpunkt, den Sie per URL mit Ihrem Bearer-Schlüssel anbinden — ganz ohne lokale Installation. Die genaue Endpunkt-URL finden Sie in der Buchhaltung unter API-Zugang.