Strands Agents im Unternehmen: Wie Agentenaktionen begrenzt, freigegeben und vor dem Einsatz getestet werden

Der Beitrag richtet sich an Plattform-Teams, Entwicklungsleitungen und Sicherheitsverantwortliche, die eigene Agenten auf AWS bauen und dafür Strands Agents nutzen oder prüfen. Er beantwortet die Pilotfrage, die bei Kiro und Strands offen ist: Wie werden Agentenaktionen begrenzt und abgenommen? Sinnvoll beginnt man nicht mit dem Framework, sondern mit einer Liste der Werkzeuge, die der Agent bekommen soll, und der Frage, welche davon etwas verändern.

Wo Strands im AWS-Angebot steht

AWS bietet für Agenten mehrere Ebenen an, die auf der Seite Amazon AWS für Unternehmen eingeordnet sind. Amazon Bedrock liefert die Modelle, AgentCore die Laufzeit mit Identität, Gateway und zentralen Regeln, und Kiro ist der Entwicklungsagent. Strands Agents liegt darunter: Es ist eine Bibliothek, mit der ein Team den Agenten selbst programmiert. Laut Projektbeschreibung laufen Strands-Agenten im eigenen Prozess, Bedrock ist der voreingestellte Modellanbieter, andere Anbieter wie Anthropic, OpenAI oder Ollama lassen sich anbinden.

Daraus folgt die wichtigste Abgrenzung. Strands entscheidet nicht, wo Daten verarbeitet werden, das tun das gewählte Modell und die Region, wie im Bedrock-EU-Check beschrieben. Strands entscheidet auch nicht über die Identität, mit der ein Agent auf Firmendaten zugreift, die Identitätsanbindung kann etwa AgentCore Identity übernehmen, siehe AgentCore-Check. Ein eigenes Berechtigungskonzept braucht die Anwendung in jedem Fall. Strands regelt, was innerhalb des Agenten geschieht: welche Aufrufe er macht, wann er anhält und wie man ihn vorher testet.

Wie Strands einen Werkzeugaufruf prüft

Das zentrale Werkzeug heißt Interventions. Ein Prüfer, in Strands ein Intervention Handler, kann vor und nach Modell- und Werkzeugaufrufen eingreifen. Welche Entscheidungen er treffen kann, hängt vom Zeitpunkt ab. Vor einem Werkzeugaufruf stehen alle fünf zur Wahl: weiter, ablehnen, mit Hinweis an das Modell zurückgeben, Bestätigung durch einen Menschen verlangen oder den Aufruf verändern. Nach dem Werkzeugaufruf bleiben nur „weiter“ und „verändern“, etwa um ein Ergebnis zu bereinigen, bevor das Modell es sieht. Eine ausgeführte Aktion lässt sich damit nicht zurücknehmen; alles, was verhindert werden soll, muss vorher geprüft werden. Mehrere Prüfer laufen in der Reihenfolge, in der sie registriert wurden. Lehnt einer ab, laufen die übrigen nicht mehr. Die Dokumentation empfiehlt deshalb, schnelle Regelprüfungen vor aufwendige Prüfungen mit einem Sprachmodell zu setzen.

Für Unternehmen besonders wichtig ist das Fehlerverhalten. Wirft ein Prüfer selbst einen Fehler, bricht der Aufruf standardmäßig ab. Alternativ lässt sich einstellen, dass der Fehler als Ablehnung gilt oder dass der Aufruf trotzdem weiterläuft. Die Dokumentation warnt ausdrücklich davor, die letzte Variante für Berechtigungsprüfungen zu nutzen, weil das geschützte Werkzeug dann ungeprüft läuft. Diese Einstellung gehört in jede Code-Prüfung.

Redaktionelle, schematische Darstellung von AI-Fabrik nach der Strands-Dokumentation zu Interventions, Cedar Authorization und Human in the Loop, kein Produkt-Screenshot. Die drei Werkzeuge sind hypothetische Beispiele. Die Reihenfolge Regel vor Freigabe ist eine Empfehlung, Strands prüft in der Reihenfolge, in der das Team die Prüfer registriert.

Regeln: Wer darf welches Werkzeug aufrufen

Mit Cedar Authorization bringt Strands eine Regelprüfung mit, die vor jedem Werkzeugaufruf eine Richtlinie in der Sprache Cedar auswertet. Die Person ist dabei die Nutzeridentität, die Aktion der Werkzeugname, und die Argumente des Aufrufs stehen der Regel zur Verfügung. So lässt sich etwa festlegen, dass nur eine bestimmte Rolle Gutschriften anlegen darf, dass ein Werkzeug nur in freigegebenen Umgebungen läuft oder dass es je Sitzung nur eine bestimmte Zahl von Aufrufen gibt.

Drei Eigenschaften machen das für Unternehmen brauchbar. Cedar lehnt standardmäßig ab: Was keine Erlaubnis hat, ist verboten. Lässt sich die Identität einer Anfrage nicht ermitteln, werden alle Aufrufe blockiert. Und Fehler der Regelmaschine selbst führen immer zur Ablehnung. Richtlinien können in Dateien liegen, gegen die Werkzeugdefinitionen geprüft und ohne Neustart neu geladen werden. Für Umgebungen empfiehlt die Dokumentation eine Liste erlaubter Umgebungen statt eines Verbots für „production“, weil ein Verbot bei abweichender Schreibweise ins Leere läuft.

Wichtig ist die Abgrenzung zu AgentCore. Auch dort prüft Policy Werkzeugaufrufe gegen Cedar-Regeln, allerdings am Gateway, also außerhalb des Agentencodes. Die Strands-Prüfung läuft dagegen im selben Prozess wie der Agent und wirkt nur so weit, wie der Code sie einbindet. Nach unserer Einordnung ist das für Entwicklung und einzelne Agenten angemessen. Wer viele Agenten verschiedener Teams betreibt oder Aufrufe mit finanzieller oder personenbezogener Wirkung zulässt, sollte die verbindlichen Regeln zusätzlich zentral am Gateway durchsetzen.

Freigaben: Wann ein Mensch zustimmen muss

Für die Freigabe liefert Strands einen fertigen Prüfer namens Human in the Loop. Er hält den Agenten vor einem Werkzeugaufruf an und fragt nach Zustimmung, im Terminal, über eine eigene Oberfläche oder durch Unterbrechen und späteres Fortsetzen, etwa in einer Web-Anwendung. Werkzeuge auf einer Liste erlaubter Werkzeuge laufen ohne Rückfrage, Werkzeuge mit vorangestelltem Ausrufezeichen fragen immer.

Zwei Komfortfunktionen verdienen Vorsicht. Ein Risikoklassifikator kann per Sprachmodell entscheiden, welche Aufrufe eine Freigabe brauchen. Die Dokumentation weist selbst darauf hin, dass kleine Entscheidungsmodelle riskante Aufrufe häufiger als sicher einstufen, und rät, ihre Urteile an den eigenen Werkzeugen zu prüfen und kritische Werkzeuge immer fragen zu lassen. Der Vertrauensmodus wiederum merkt sich eine Zustimmung für den Rest der Sitzung. Das spart Klicks, macht aus einer Einzelfreigabe aber eine Pauschalfreigabe. Für schreibende Werkzeuge mit Außenwirkung sollte er aus bleiben.

Eine Freigabe ist nur so gut wie die Information, die der Mensch sieht. Sie sollte Werkzeug, Ziel, Argumente und mögliche Folgen verständlich zeigen, und die freigebende Person muss fachlich zuständig sein und ablehnen können. Die Freigabe ersetzt keine Regel: Was nach Cedar nie erlaubt ist, darf gar nicht erst zur Rückfrage kommen.

Abnahme: Wie man den Agenten vor dem Einsatz testet

Regeln und Freigaben begrenzen, was schiefgehen kann. Ob der Agent seine Aufgabe erfüllt und ob er Angriffen standhält, zeigen Tests. Strands bringt dafür eine eigene Evals-Bibliothek mit. Sie bewertet Antworten und ganze Abläufe, unter anderem die Wahl der Werkzeuge, die Genauigkeit der Argumente und ob das Ziel einer Sitzung erreicht wurde. Neben Bewertungen durch ein Sprachmodell gibt es Prüfungen per Code ohne Modell, etwa ob ein bestimmtes Werkzeug aufgerufen wurde.

Der zweite Teil ist das Red Teaming. Es greift den Agenten mit vorbereiteten Angriffen an und wertet aus, welche durchkommen. Die eingebauten Kategorien reichen von Prompt-Injection über die Preisgabe vertraulicher Daten und das Abziehen von Daten über Werkzeuge bis zu Aufrufen über die Berechtigung hinaus, etwa einer Erstattung über dem erlaubten Betrag. Die Bewertung übernimmt ein Sprachmodell als Richter. Das ist schnell und wiederholbar, ersetzt aber keine manuelle Prüfung komplexer Aktionsketten.

Ein brauchbarer Testplan für einen ersten Agenten hat vier Teile. Erstens eine feste Liste von Fachaufgaben mit erwartetem Ergebnis und erwarteten Werkzeugaufrufen. Zweitens Angriffe aus den Kategorien, die zu den Werkzeugen passen: Ein Agent mit E-Mail-Werkzeug muss gegen Datenabfluss getestet werden, einer mit Buchungsrecht gegen Aufrufe über die Befugnis hinaus. Drittens ein Abnahmekriterium, das das Team vorher festlegt, etwa dass kein Angriff ein schreibendes Werkzeug ohne Freigabe erreicht. Viertens ein fester Anlass: vor dem Produktivgang und nach jeder Änderung an Modell, Prompt, Werkzeugen oder Rechten. Als methodische Orientierung eignet sich der Eintrag Excessive Agency der OWASP-Liste für Sprachmodell-Anwendungen.

Wie viel Kontrolle welcher Agent braucht

Wie viel davon nötig ist, hängt von der Wirkung der Werkzeuge ab, nicht von der Größe des Unternehmens. Auch ein Agent, der nur liest, ist nicht harmlos: Er kann vertrauliche Daten in seinen Antworten preisgeben oder über präparierte Inhalte dazu gebracht werden. Er braucht deshalb Datenzugriffsrechte, die nicht weiter reichen als die des Nutzers, eine Cedar-Regel für seine Werkzeuge, Grenzen für Durchläufe und Tokens und Angriffstests auf Datenabfluss. Sobald er schreibt, richtet sich die Kontrolle nach der Tragweite der Aktion. Umkehrbare, interne Aktionen wie ein Ticket im eigenen System lassen sich nach dem Pilot mit Regeln, Mengengrenzen und Stichproben absichern. Zahlungen, externe E-Mails und Änderungen an Stammdaten brauchen dagegen eine Freigabe im Einzelfall, Angriffstests vor jeder Änderung und eine Protokollierung, die Nutzer, Werkzeug und Entscheidung festhält. Strands kann Abläufe über OpenTelemetry protokollieren, die Dokumentation beschreibt dafür auch das Ausblenden personenbezogener Daten in den Protokollen. Bei Zugriff auf Finanz- oder Personaldaten oder bei schwer umkehrbaren Aktionen kommen zentrale Regeln am Gateway, eine unabhängige Prüfung und eine Ausführung von Code nur in einer Sandbox hinzu, etwa mit der von uns eingeordneten Strands Box.

Pilotfragen vor dem ersten Strands-Agenten

1. Welche Werkzeuge bekommt der Agent, welche davon verändern etwas, und welche Freigaberegel gilt je Werkzeug nach seiner Tragweite?
2. Gibt es eine Cedar-Regel mit Standard-Ablehnung, und ist das Fehlerverhalten aller Prüfer auf Ablehnung gestellt?
3. Sind Risikoklassifikator und Vertrauensmodus für schreibende Werkzeuge abgeschaltet oder bewusst begründet?
4. Welche Grenzen gelten für Durchläufe und Tokens, und welche Budgets und Alarme greifen auf Kontoebene?
5. Welcher Testsatz aus Fachaufgaben und Angriffen läuft vor dem Produktivgang und nach jeder Änderung, und wer verantwortet die Befunde?

Fazit: Die Bausteine sind da, der Standard muss vom Unternehmen kommen

Quellen

Weiterführende Artikel auf AI-Fabrik