KI-Agenten – Sicherheitsvorkehrungen und Schutz in Jira

Guardrails vereinfachen die KI-Einführung im großen Stil, indem sie Vertrauen in agentenbasierte Workflows schaffen. Die funktionierenden Guardrails werden in deine Workflows integriert, sodass das System sie durchsetzt, statt auf die Agenten zu vertrauen.

In Jira ist dieses System dasjenige, in dem dein Team bereits arbeitet. Jira gewährt einem Agenten über Berechtigungen den vorgesehenen Zugriff. An vorgegebenen Checkpoints setzen Mitarbeiter bei Workflow-Übergängen ihr Urteilsvermögen ein. Jede von einem Agenten durchgeführte Aktion wird im Vorgang dokumentiert. Der Teamwork Graph liefert dem Agenten den richtigen Kontext für seine Aktionen.

In diesem Leitfaden geht es um die Risiken, denen du mit Guardrails für Agenten begegnen kannst. Du erfährst, wie du Guardrails in Jira durchsetzt, damit du KI sicher und verantwortungsvoll skalieren und den Agenten mehr Autonomie für ihren Einsatz im Team gewähren kannst – von Routineaufgaben, die den Betrieb aufrechterhalten, bis hin zu hochwertigen Projekten. Dabei behältst du immer die Kontrolle. Autonomie in diesem Umfang basiert auf vier Guardrails, die du über die Workflows, Berechtigungen und Regeln, die dein Team bereits verwendet, in Jira festlegst:

• Begrenzung des Zugriffs: Lege über deine bestehenden Jira-Berechtigungen fest, auf welche Daten ein Agent zugreifen darf, welche Tools er verwenden darf und wo er handeln darf.

• Absicherung riskanter Aktionen: Verwende Workflow-Übergänge, um eine Genehmigung durch einen Mitarbeiter vorzuschreiben, bevor Vorgänge mit großer Auswirkung umgesetzt werden.

• Überprüfung der Ausgabe: Prüfe die Ergebnisse des Agenten im Rahmen deiner normalen Überprüfung von Pull-Anfragen, bevor sie ausgeliefert werden.

• Dokumentation: Jede Agentenaktion wird im Vorgangsverlauf erfasst und mit der Information verknüpft, wer sie genehmigt hat.

Was sind Guardrails bei der agentenbasierten Entwicklung?

Guardrails für Agenten sind die Kontrollen, die dafür sorgen, dass ein KI-Agent sicher, wie vorgesehen und nachvollziehbar arbeitet. Sie regeln, worauf er zugreifen kann, an welchen Checkpoints Mitarbeiter eingreifen sollen und dass die ausgeführten Aktionen dokumentiert werden. Guardrails werden von dem System durchgesetzt, in dem der Agent arbeitet. Die Einhaltung wird also nicht dem Agenten selbst überlassen.

Für die Sicherheit eines Agenten genügt es nicht, ihn anzuweisen, dass er sich auf eine bestimmte Weise verhalten soll. Anweisungen können vergessen, missverstanden oder außer Kraft gesetzt werden. Echte Guardrails setzen oberhalb des Agenten in seiner Umgebung an, wo die Grenzen unabhängig von den Anweisungen des Agenten gelten. Es ist das Prinzip, nach dem dein Team bereits arbeitet: Was möglich ist, entscheidet das System und nicht die einzelne Person, die aufgefordert ist, die Regeln zu befolgen.

In der Praxis decken Guardrails für Agenten einige zusammenhängende Bereiche ab:

• Zugriff und Umfang. Die Daten, auf die ein Agent Zugriff hat, die Tools, mit denen er arbeiten kann, und wo er handeln kann.

• Begrenzte Aufgaben. Welche Aufgaben ein Agent vollständig besitzen kann und welche bei einer Person verbleiben.

• Genehmigung mit menschlicher Beteiligung. Die Kontrollpunkte, an denen eine Überprüfung oder Genehmigung erfolgt, ehe die Aufgabe fortgesetzt wird.

• Überprüfung der Ausgabe. Die Ausgabe des Agenten wird vor der Veröffentlichung validiert.

• Verantwortlichkeit und Audit. Ein Protokoll dessen, was der Agent getan hat, warum er es getan hat und wer es genehmigt hat.

• Governance. Die fortlaufenden Kontrollen, die für Konsistenz sorgen, wenn der Agent vermehrt zum Einsatz kommt.

All das zusammen schafft Vertrauen in agentenbasierte Workflows. Teams können Agenten mehr Verantwortung übertragen, ohne die Kontrolle zu verlieren, da eine Person für das Ergebnis verantwortlich bleibt.

Warum brauchen KI-Agenten Guardrails?

Agenten handeln. Im Gegensatz zu einem Chatbot, der nur Vorschläge macht, kann ein Agent Code ändern, Aufgaben verschieben und in all deinen Tools echte Aktionen auslösen. Diese Autonomie macht Agenten nützlich, sie ist aber auch der Grund für die Notwendigkeit von Guardrails, also Leitlinien: Je mehr ein Agent selbstständig handeln kann, desto wichtiger ist es, dass seine Arbeit abgestimmt, überprüft und nachvollziehbar bleibt.

Die zentralen Risiken, die Guardrails adressieren, und wo menschliches Urteilsvermögen unverzichtbar bleibt:

• Fehlausrichtung: Der Agent optimiert für das Falsche oder weicht von der Aufgabe ab.

• Minderwertige oder falsche Ausgabe: Die Arbeit sieht fertig aus, hat aber das Ziel verfehlt. Dazu gehören halluzinierter Code oder Fakten.

• Zu weit gefasster Zugriff: Der Agent greift auf Daten oder Systeme zu, auf die er keinen Zugriff haben sollte.

• Nicht überprüfte, unumkehrbare Aktionen: Änderungen mit großen Auswirkungen, die nicht sauber rückgängig gemacht werden können, wie die Weitergabe in die Produktion oder das Löschen von Daten, und die einen menschlichen Kontrollpunkt benötigen, bevor sie in Kraft treten.

• Keine Verantwortlichkeit oder Transparenz: Ohne einen Nachweis kann niemand sehen, was der Agent getan hat oder wer die Freigabe erteilt hat.

• Außer Kontrolle geratene Kosten: Agenten können Tokens und Rechenleistung unvorhersehbar verbrauchen. Daher müssen wie bei jeder anderen Ressource die Ausgaben begrenzt werden.

Guardrails funktionieren nur, wenn das System sie durchsetzt, nicht der Agent. Einem Agenten zu sagen, was er nicht tun soll, ist keine Guardrail, denn er kann diese Anweisung erhalten und die Handlung trotzdem ohne dein Wissen ausführen. Echte Guardrails sind über dem Agenten in seiner Umgebung angesiedelt, sodass die unerwünschte Aktion nicht nur erschwert wird, sondern unmöglich ist.

Deshalb sind Guardrails die Voraussetzung für Autonomie und keine Bremse dafür. Teams, die den Begrenzungen vertrauen, können Agenten mehr Verantwortung mit weniger direkter Aufsicht übertragen. Teams, die nicht vertrauen können, verlieren den Geschwindigkeitsvorteil, den sie durch Agenten eigentlich erreichen wollten.

Wie steuert man KI-Agenten sicher in Jira?

Wenn eine Guardrail über dem Agenten in dem System angesiedelt sein muss, in dem er arbeitet, dann ist dieses System ausschlaggebend. Für Entwicklungsarbeit ist dies Jira. Agenten, die innerhalb des System of Work von Atlassian arbeiten, greifen über dieselben Jira-Berechtigungen auf deine Daten und Vorgänge zu wie dein Team, neben den bestehenden Workflows und dem Audit-Trail. Was ein Agent in seiner eigenen Umgebung tun kann, wird weiterhin vom Agenten gesteuert. Daher regelt Jira den Zugriff auf den Vorgang, während Berechtigungen auf Agentenebene die Tools steuern, die er ausführt.

Für sich allein steuert ein Coding-Agent nur seine eigenen Aktionen. Jira steuert den Vorgang, sodass Guardrails an einer Stelle für alle Agenten gelten und du sehen kannst, welches Risiko jede einzelne Schutzmaßnahme abdeckt.

Workflows sind der Ort, an dem der Großteil dieser Durchsetzung erfolgt. Die Status, Übergänge und Regeln, die Vorgänge zwischen Personen weiterleiten, leiten diese auch an Agenten weiter, entscheiden, welche Übergänge ein Agent ausführen darf, und halten Änderungen mit großer Auswirkung zur Freigabe zurück.

Zugriff: was sich in Jira steuern lässt

Das erste steuerbare Element ist der Umfang: mit welchen Daten, Tools und Projekten ein Agent arbeiten kann. Das ist die Guardrail gegen zu weit gefassten Zugriff. In Jira legst du sie wie für jeden anderen Teamkollegen fest. Der Vorgang ist also vertraut und du kannst alles nach deinen Wünschen anpassen.

• So funktioniert das in Jira: Du wählst die Identität aus, als die ein Agent agiert. Standardmäßig handelt er im Namen der dahinterstehenden Person und kann nur auf die Daten, Projekte und Vorgänge zugreifen, auf die diese Person ebenfalls zugreifen kann. Du kannst einem Agenten auch ein eigenes Konto und eigene Berechtigungen geben, damit sein Zugriff nicht von einer einzelnen Person abhängt. Admins kontrollieren, welche Agenten aktiviert sind und wo. Was ein Agent mit seinen eigenen Tools machen kann, wird vom Agenten festgelegt, nicht von Jira. Halte den Zugriff breit gefasst oder begrenze den Umfang eng und erweitere ihn, wenn das Vertrauen wächst.

• Die Steuerelemente, die du anpasst. Es sind dieselben Berechtigungshebel, die du bereits für Personen verwendest: Berechtigungsschemas und Projektrollen legen fest, was ein Agent in einem Projekt tun kann. Die Vorgangssicherheit begrenzt, welche spezifischen Vorgänge er sehen kann. Wenn du einen dieser Hebel anziehst, wird auch die Reichweite des Agenten stärker begrenzt, ohne dass ein agentenspezifisches System erforderlich ist.

• Gewähre Zugriff auf das, was für die Aufgabe nötig ist. Die meisten Agenten arbeiten am besten mit etwas Spielraum, also richte den Umfang nach der Aufgabe aus. Bei wirklich sensiblen Systemen solltest du den Spielraum gezielt einengen.

Wie steuerst du, was Agenten in deinem Workflow tun?

Die zweite Guardrail ist der Workflow: die Regeln, die festlegen, wann ein Agent ausgeführt wird, was er selbstständig tun kann und bei welchen Aufrufen er auf eine Person warten muss. Das ist deine Absicherung gegen Fehlanpassungen und Aktionen, die nicht rückgängig gemacht werden können. Lege diese Regeln auf die Übergänge fest, die dein Team bereits nutzt, sodass die Kontrolle nicht erst an einem einzigen Punkt ganz am Ende erfolgt.

Eine Übergangsbedingung schränkt ein, in welchen Phasen ein Agent aktiv werden kann, eine Bestätigung blockiert Aufgaben, die noch nicht bereit sind, und ein Genehmigungsschritt hält Änderungen mit großer Auswirkung für eine Person zurück. Menschliche Genehmigung ist eine Regel unter vielen, und die Aufgabe besteht darin, jede Regel dem Risiko zuzuordnen.

• So erfolgt die Einrichtung in Jira: Öffne den Workflow für den Vorgangstyp und weise einen Agenten einem Übergang zu, wie etwa dem Wechsel zu "Wird überprüft". So wird der Agent ausgeführt, wenn ein Vorgang diesen Punkt erreicht. Das Hinzufügen eines Agenten legt fest, wann er ausgeführt wird, nicht ob eine Person ihn genehmigt. Die menschliche Genehmigung ist ein separates Kontrollelement: Ein Genehmigungsschritt im Workflow regelt den Übergang, und du kannst ihn mit den eigenen Anweisungen des Agenten kombinieren, wann er pausieren und nachfragen soll, oder mit einer Automatisierungsregel. Ein Übergang ist einer von mehreren Einstiegspunkten. Ein Agent kann auch starten, wenn:

  • ein Vorgang erstellt wird, sodass er direkt nach dem Eingang triagiert wird

  • ein Themenbereich oder Feld sich ändert oder nach einem Zeitplan durch eine Automatisierungsregel

  • er im Hintergrund für routinemäßige Updates wie das Erstellen von Versionshinweisen läuft

• Passe das Gate an das Risiko an. Lass Aufgaben mit geringem Risiko eigenständig ablaufen (die Aktualisierung einer Abhängigkeit), benachrichtige eine Person bei Aufgaben mit mittlerem Risiko (eine Änderung an einer gemeinsam genutzten Konfiguration) und fordere eine Genehmigung für Aktionen mit hohem Risiko oder nicht umkehrbare Aktionen an (Änderungen in der Produktion oder das Löschen von Daten).

• Entscheide, wofür der Agent zuständig ist. Bevor du den Kontrollpunkt festlegst, musst du entscheiden, was ein Agent besitzt. Lass einen Agenten Aufgaben mit geringem Risiko vollständig übernehmen. Bereite Aufgaben mit größerer Auswirkung so vor, dass eine Person sie abschließt, und überlasse Entscheidungen mit den höchsten Auswirkungen weiterhin einem Menschen. Das Begrenzen einer Aufgabe ist die erste Entscheidung, mit dem Kontrollpunkt wird sie durchgesetzt.

• Gib Agenten ihre eigenen Anweisungen. Du legst fest, wie sich ein Agent verhalten und Aufgaben voranbringen soll. Dazu gehören auch die Entscheidungen, die er selbst treffen soll, und wann er anhalten und nachfragen soll, damit er den Konventionen deines Teams statt generischen Standardeinstellungen folgt.

Die Ausgabe überprüfen: Wie wird die Ausgabe des Agenten überprüft?

Die dritte Guardrail ist die Überprüfung des Ergebnisses, bei der eine Person minderwertige Ausgaben und Halluzinationen frühzeitig erkennt. Für einen Coding-Agenten ist das die Pull-Anfrage, die geöffnet wird.

• In Jira: Die Ausgabe des Agenten wird so lange als nicht vertrauenswürdig betrachtet, bis eine Person oder etablierte Überprüfung sie verifiziert hat – diese Anforderungen würdest du auch an Code von einem neuen Mitarbeiter stellen. Die Arbeit des Agenten ist mit dem Vorgang verknüpft und Codeänderungen werden als Pull-Anfrage übermittelt, die deinen normalen Prüfungs- und Merge-Prozess durchläuft. Nichts, was von deinem Agenten erstellt wird, überspringt die Prüfung, die dein Team bereits durchführt.

• Sieh dir die Arbeit hinter der Ausgabe an. Du siehst nicht nur das Endergebnis. Agentensitzungen in Jira bieten dir einen zentralen Ort, an dem du sehen kannst, was ein Agent getan hat und warum. So hat ein Reviewer den nötigen Kontext, um die Ausgabe zu verstehen, anstatt sie rekonstruieren zu müssen.

Bildunterschrift: Beispiel: Definiere Standards für KI-Code-Reviews in Bitbucket Cloud und setze sie automatisch bei jeder Pull-Anfrage durch.

Führe ein nachvollziehbares Protokoll: Wer hat was getan und wann?

Die vierte Guardrail ist das Protokoll, die Antwort auf die Rechenschaftspflicht. Es verknüpft die Arbeit von Agenten wieder mit der Absicht: was der Agent getan hat, warum, welchem Vorgang es dient und wer es genehmigt hat. Diese Verknüpfung macht es einfach, Probleme nachzuverfolgen und zu beheben, wenn etwas schiefläuft.

• In Jira: Jeder Agent wird unter einer bekannten Identität ausgeführt: entweder der Person, die den Vorgang zugewiesen oder eingerichtet hat, und dabei mit den Berechtigungen dieser Person handelt, oder über das eigene Agentenkonto mit Berechtigungen, die du zuweist. In jedem Fall verknüpft das Protokoll jede Aktion mit einer verantwortlichen Identität. Im Vorgangsverlauf erfasst das Protokoll die Handlungen des Agenten und wer dafür verantwortlich ist, zusammen mit den menschlichen Handlungen. Dabei sind Genehmigungen mit dem Reviewer verknüpft, der sie erteilt hat. Admins können Audit-Protokolle auch auf ungewöhnliche Aktivitäten überwachen.

• Beziehe lokale Agentenvorgänge in den Datensatz ein: Die Agentensitzungsverfolgung liefert Daten zu Aktivitäten von lokalen KI-Programmierungsagenten in lokalen IDEs oder Terminals, die mit dem Vorgang verknüpft werden, sodass Vorgänge, die außerhalb von Jira erledigt werden, trotzdem in einem nachvollziehbaren Datensatz zusammenlaufen. Du kannst dich jetzt für die Warteliste registrieren.

Welche Best Practices gelten für Agenten-Guardrails?

• Stimme den Zugriff eines Agenten auf seine Aufgabe ab und erweitere ihn, wenn das Vertrauen wächst (Agenten verwenden deine vorhandenen Jira-Berechtigungen).

• Gib Agenten klare Anweisungen dazu, wie sie handeln sollen und wann sie stoppen und nachfragen sollen.

• Setze Agenten anfangs für risikoarme, reversible Aktionen ein, bevor du sie Aufgaben mit größeren Auswirkungen übernehmen lässt.

• Binde bei wichtigen Entscheidungen Menschen ein – mit Checkpoints an mehreren Stellen, nicht nur bei der abschließenden Freigabe.

• Überprüfe die Ausgabe der Agenten mit demselben Prozess wie die Ergebnisse deiner Mitarbeiter (Überprüfung und Zusammenführung von Pull-Anfragen).

• Dokumentiere alle von Agenten ausgeführten Aktionen und verknüpfe sie mit dem jeweiligen Vorgang (Verlauf und Audit-Protokoll).

• Stelle Agenten Kontextinformationen als Grundlage zur Verfügung, um die Kosten unter Kontrolle zu halten. Wenn die Agenten auf gut Glück handeln und daher mehrere Versuche brauchen, explodieren die Kosten schnell.

Atlassian hat festgestellt, dass die auf dem Teamwork Graph basierende KI die Antwortqualität um 44 % verbessert und gleichzeitig den Token-Verbrauch um 48 % gesenkt hat.

Welche Guardrails werden in Jira verwaltet, welche an anderen Stellen?

Guardrails gibt es auf mehreren Ebenen des Agenten-Stacks. Jira ist für die Aufgaben- und Zugriffsebene zuständig. Guardrails für andere Ebenen werden von Modellanbieter, Agenten-Framework und CI verwaltet.

Jira gibt vor, welche Aktivitäten für Agenten zulässig sind, und erfasst, wann diese ausgeführt wurden. So ergänzt es die Sicherheitsmaßnahmen auf Modell- und Laufzeitebene, statt sie zu ersetzen.

So fügst du deine ersten Agenten-Guardrails in Jira hinzu

Für den Anfang benötigst du kein komplettes Governance-Programm. Schon mit nur einem Guardrail kannst du echte Vorgänge verantwortungsvoll an einen Agenten übergeben. In die wichtigen Entscheidungen wird ein Mitarbeiter eingebunden. Mit zunehmendem Vertrauen kannst du den Einsatz erweitern.

1. Wähle eine einzelne reversible Routineaufgabe aus, beispielsweise einen instabilen Test oder ein Problem mit einer Abhängigkeit. (Damit begrenzt du die Kosten, wenn es nicht auf Anhieb funktioniert.)

2. Gewähre dem Agenten den Zugriff, den du auch einem neuen Teamkollegen geben würdest – nur genau so viel, wie für die Aufgabe erforderlich ist.

3. Füge ihn einem Workflow-Übergang hinzu, damit ein Mitarbeiter zuerst die Genehmigung erteilen muss. (So werden falsche oder riskante Aktionen verhindert.)

4. Überprüfe die Pull-Anfrage mit deinem normalen Prozess. (Damit deckst du Ausgaben von niedriger Qualität oder Halluzinationen auf.)

5. Vergewissere dich, dass die Aktion im Vorgang erfasst wurde. (Nachverfolgbarkeit ist wichtig, falls du etwas rückgängig machen musst.)

6. So erstellst du den Workflow, um KI verantwortungsvoll zu skalieren: bessere Agent-Ausgabe, schnellere Überprüfung und mehr Autonomie, die du nach und nach sicher erweitern kannst.

Lies auch unseren Leitfaden für verantwortungsvolle KI-Governance, der zu den Atlassian-Prinzipien verantwortungsvoller Technologie gehört.

Häufig gestellte Fragen zu Guardrails für KI-Agenten

Wie wahre ich die Sicherheit von KI-Agenten?

KI-Agenten sind dann sicher, wenn du steuerst, worauf sie zugreifen können, für Aktionen mit hoher Auswirkung eine Mitarbeitergenehmigung vorschreibst und alle ihre Aktionen dokumentierst. Das Maß an Überwachung sollte auf das mit der jeweiligen Aufgabe verbundene Risiko abgestimmt sein.

Wie werden KI-Agenten in Jira gesteuert?

In Jira gelten für KI-Agenten die Kontrollen, die dein Team bereits nutzt: Die Agenten arbeiten entsprechend den Berechtigungen und Workflows von Jira, du kannst bei einem Workflow-Übergang eine Genehmigung durch einen Mitarbeiter vorschreiben und ihre Aktionen werden im Vorgangsverlauf und im Audit-Protokoll erfasst.

Ist es möglich, für KI-Agenten in Jira eine Genehmigung durch einen Mitarbeiter zu verlangen?

Ja. Du kannst einen Agenten einem Workflow-Übergang hinzufügen, damit ein Mitarbeiter die Ausgabe zuerst überprüfen und genehmigen muss, bevor der Agent fortfahren darf. Autonome Aktionen bleiben dann für risikoarme, reversible Aufgaben vorbehalten.

Wie steht es mit Prompt Injection bei KI-Agenten?

Prompt Injection bedeutet, dass durch nicht vertrauenswürdige Eingaben versucht wird, einen Agenten zu unbeabsichtigten Aktionen zu bewegen. Atlassian filtert die Eingaben für Rovo-gestützte Agenten auf potenzielle Injection-Versuche hin. Da kein Filter alles abwehren kann, fangen mehrstufige Guardrails den Rest ab – mit Zugriffsbeschränkungen, verpflichtender Genehmigung durch einen Mitarbeiter und einen vollständigen Audit-Trail.