AgentenRechte, Freigaben, Abbruch.
Ein Agent handelt, ein Chatbot antwortet. Diese Seite ist der alleinige Ort für Agenten-Kontrollen: minimale Rechte, eigene Identität, Freigabeschwellen, Limits, Abbruchschalter, Protokollierung, MCP-Server, Multi-Agent-Systeme, Laufzeitsteuerung und eine Checkliste vor der Produktivsetzung.
Rechtsstand: 11. Oktober 2026. Die Bedrohungen stehen auf der Seite Bedrohungslandschaft. OWASP Agent Control Standard (ACS) und NIST COSAIS sind Entwürfe, keine verbindlichen Vorgaben.
Was Agenten
anders macht.
Ein Agent kombiniert ein Sprachmodell mit Werkzeugen, Gedächtnis und einem Ziel. Er plant Schritte, ruft Schnittstellen auf und verändert Systeme, oft ohne dass ein Mensch jeden Schritt sieht. Damit verschiebt sich das Risiko: Nicht die Antwort ist das Problem, sondern die Handlung.
Das Modell kann Anweisungen aus Daten nicht verlässlich von Anweisungen des Auftraggebers trennen. Jede Kontrolle muss deshalb ausserhalb des Modells greifen: in Identität, Berechtigung, Netzwerk und Freigabe.
Die Bedrohungskataloge stehen auf Bedrohungslandschaft: OWASP Top 10 for Agentic Applications 2026 (ASI01 bis ASI10), die Kategorie Excessive Agency der OWASP LLM Top 10 2026 und MITRE ATLAS. Diese Seite enthält nur die Gegenmassnahmen.
Betreiber und Anbieter von Agenten, auch bei Eigenentwicklung im Fachbereich. Einordnung der Systeme: Inventar und Klassifizierung. Referenzarchitektur: Architektur-Referenz.
Sechs Kontrollen
je Agent.
| Kontrolle | Umsetzung | Nachweis |
|---|---|---|
| Minimale Rechte je Werkzeug | Jedes Werkzeug erhält nur die Operationen, die der Anwendungsfall braucht, getrennt nach lesen, schreiben, löschen. Keine Sammelrechte, keine Administratorkonten. Rechte gelten für den Auftrag, nicht dauerhaft. | Berechtigungsmatrix Agent × Werkzeug × Operation |
| Eigene Identität je Agent | Jeder Agent hat ein eigenes Dienstkonto mit eigenen, kurzlebigen Zugangsdaten aus einem Secrets-Dienst. Keine geteilten Konten, keine Zugangsdaten im Prompt oder im Code. Bei Handlungen im Namen eines Nutzers gelten dessen Rechte höchstens im Schnitt mit denen des Agenten. | Identitätsinventar, Rotationsprotokoll |
| Freigabeschwellen mit Mensch in der Schleife | Handlungen nach Wirkung abstufen (Tabelle unten). Die Freigabe zeigt Handlung, Ziel und Parameter, nicht nur eine Zusammenfassung des Agenten. | Freigabeprotokoll mit Person und Zeit |
| Ressourcen- und Kostenlimits | Obergrenzen je Lauf und je Zeitraum für Schritte, Werkzeugaufrufe, Token, Laufzeit und Kosten. Bei Erreichen stoppt der Lauf und meldet. | Limitkonfiguration, Alarmprotokoll |
| Abbruchschalter | Ein Mensch kann einen Agenten, eine Agentenklasse oder alle Agenten sofort anhalten und seine Zugangsdaten sperren. Der Schalter liegt ausserhalb des Agenten und wird geübt. | Übungsprotokoll, Zeit bis zur Sperre |
| Protokollierung je Aktion | Jede Handlung wird mit Agent, Auftrag, Werkzeug, Parametern, Ergebnis und Freigeber festgehalten, manipulationsgeschützt und getrennt vom Agenten gespeichert. Der Lauf ist über eine Kennung nachvollziehbar. | Ereignisprotokoll im zentralen Monitoring |
Für Hochrisiko-KI-Systeme verlangt der AI Act (EU-Recht, Marktortprinzip Art. 2) Aufsicht durch natürliche Personen mit der Möglichkeit, den Betrieb über eine «Stopptaste» zu unterbrechen (Art. 14 Abs. 4 Bst. e), und automatische Protokollierung (Art. 12 Abs. 1). Für andere Agenten sind das Empfehlungen dieser Seite.
Wirkung bestimmt
die Freigabe.
Die Stufen sind eine Gestaltungsempfehlung von STOP.LI, keine Norm. Massgebend ist die Wirkung der einzelnen Handlung, nicht der Agent insgesamt.
| Stufe | Wirkung | Beispiel | Steuerung |
|---|---|---|---|
| 0 | Lesen, intern, ohne vertrauliche Daten | Wissensartikel abrufen | Automatisch, protokolliert |
| 1 | Schreiben, intern, rückgängig machbar | Ticket anlegen, Entwurf speichern | Automatisch mit Limit, Stichprobenprüfung |
| 2 | Extern wirksam oder nicht rückgängig machbar | E-Mail versenden, Zahlung auslösen, Daten exportieren | Freigabe durch fachlich verantwortliche Person |
| 3 | Rechte, Konfiguration, Löschung, Produktivsysteme | Berechtigung vergeben, Regel ändern | Freigabe durch zwei Personen, nach Änderungsprozess |
Anbindungen
wie Lieferanten.
Das Model Context Protocol (MCP) verbindet Agenten mit Werkzeugen und Datenquellen. Jeder MCP-Server ist eine Code- und Datenquelle mit eigenen Rechten und gehört ins Inventar. Die Spezifikation beschreibt eigene Angriffe und Gegenmassnahmen; die folgende Tabelle ordnet sie Kontrollen zu und ergänzt sie um Inventar, Herkunft und zentralen Zugang (Empfehlungen dieser Seite).
| Kontrollfeld | Vorgabe |
|---|---|
| Inventar | Alle MCP-Server mit Zweck, Eigner, Version, Transport (lokal oder entfernt), angebotenen Werkzeugen und angebundenen Daten führen. Nur freigegebene Server sind erreichbar (Allowlist). |
| Herkunft | Server und Pakete aus geprüften Quellen mit festgelegter Version beziehen, Abhängigkeiten prüfen und Änderungen der Werkzeugbeschreibungen als Änderung behandeln. Beschreibungen sind Eingaben des Servers und damit nicht vertrauenswürdig. |
| Berechtigungen | Zugriffsbereiche (Scopes) schrittweise und eng vergeben; keine Sammel- oder Platzhalterbereiche. Der Server akzeptiert nur Token, die für ihn ausgestellt sind. Die Weitergabe fremder Token an nachgelagerte Dienste (Token Passthrough) ist unzulässig. Proxy-Server holen die Einwilligung je Client ein. |
| Netzwerkgrenzen | Ausgehende Verbindungen von MCP-Clients über einen Egress-Proxy führen; private Adressbereiche und Metadatendienste sperren, Umleitungen prüfen (Schutz gegen Server-Side Request Forgery). |
| Lokale Server | Startbefehle vor der Ausführung vollständig anzeigen und bestätigen lassen; Server in einer Sandbox mit minimalen Rechten starten; bevorzugt stdio oder gesicherte lokale Kanäle. |
| Zentraler Zugang | Ein MCP-Gateway kann Authentifizierung, Allowlist, Ratenbegrenzung und Protokollierung bündeln. Es ersetzt die Prüfung der Server nicht. |
Agenten, die
Agenten rufen.
In Verbünden gibt jeder Agent Eingaben an den nächsten weiter. Ein manipulierter Agent kann so andere beeinflussen. Das Bedrohungsmodell MAESTRO der Cloud Security Alliance beschreibt Kommunikationskanäle und Identitätsangriffe zwischen Agenten und nennt gegenseitige Authentifizierung, sichere Kommunikation und Eingabeprüfung als Gegenmassnahmen.
- Jeder Agent authentifiziert sich gegenüber jedem anderen; kein Vertrauen allein aus der Position im Verbund.
- Rechte werden nicht vererbt: Ein aufgerufener Agent erhält höchstens die Rechte, die der Auftrag braucht.
- Nachrichten zwischen Agenten gelten als nicht vertrauenswürdige Eingabe und durchlaufen dieselben Prüfungen wie Nutzereingaben.
- Aufrufketten haben eine Tiefenbegrenzung und eine gemeinsame Lauf-Kennung für Protokoll und Abbruch.
- Ein Mensch verantwortet jeden Verbund; Agenten können keine Freigaben füreinander erteilen.
Regeln im Lauf
durchsetzen.
Der OWASP Agent Control Standard (ACS) beschreibt Laufzeitsteuerung für Agenten. Er legt fest, wie Agentenplattformen Hooks bereitstellen, über die Sicherheitsregeln deklarativ und unabhängig vom Agenten-Framework durchgesetzt werden. Nach der Einordnung der Cloud Security Alliance (4. September 2026) steht der Standard auf Version 0.1; Implementierungsbeispiele sind noch nicht veröffentlicht. Er eignet sich als Zielbild, nicht als Pflicht.
ACS sieht Hooks und einen Wächter-Agenten (Guardian Agent) vor. Als eigene Ableitung empfiehlt STOP.LI Punkte vor Modellaufruf, Werkzeugaufruf und Ausgabe, an denen Allowlist, Freigabestufe, Limits und Datenabfluss geprüft werden.
Ereignisse des Agenten werden nach ACS über OpenTelemetry und OCSF erfasst. Ein einheitliches Format erleichtert Korrelation im Monitoring und die Untersuchung von Vorfällen.
Die Agent Bill of Materials (AgBOM) listet Werkzeuge, Modelle und erreichbare Daten eines Agenten. Vorgesehen sind die Formate CycloneDX, SPDX und SWID; die Umsetzung ist laut Fahrplan für Version 2 geplant.
Ergänzend entwickelt das NIST unter COSAIS Kontrollüberlagerungen (Overlays) auf Basis von SP 800-53. Für Agenten sind Einzel- und Multi-Agent-Einsatz als vorgeschlagene Anwendungsfälle genannt; ein Entwurf war beim Abruf am 11.10.2026 nicht aufgeführt. Eine eigene Agenten-Stückliste lässt sich schon heute mit den Verfahren aus SBOM und VEX führen.
Vor der
Produktivsetzung.
Alle Punkte müssen mit Nachweis beantwortet sein. Ein offener Punkt der Stufen 2 und 3 verhindert die Freigabe.
- Der Agent ist im Inventar mit Eigner, Zweck, Modell, Werkzeugen und Datenzugriffen erfasst.
- Er hat eine eigene Identität mit kurzlebigen Zugangsdaten; keine Zugangsdaten stehen in Prompts oder Code.
- Berechtigungsmatrix liegt vor und ist durch den Eigner und die Informationssicherheit abgenommen.
- Alle Handlungen sind in Freigabestufen eingeteilt; Stufen 2 und 3 setzen eine Freigabe mit sichtbaren Parametern voraus.
- Limits für Schritte, Aufrufe, Laufzeit und Kosten sind gesetzt und mit Alarm hinterlegt.
- Der Abbruchschalter ist getestet; die Zeit bis zur Sperre der Zugangsdaten ist gemessen.
- Jede Aktion wird manipulationsgeschützt protokolliert und ins Monitoring geleitet.
- Alle MCP-Server sind inventarisiert, freigegeben, in der Version festgelegt und netzwerkseitig begrenzt.
- Tests mit Prompt Injection über Werkzeugergebnisse und Dokumente wurden durchgeführt (Prüfmethoden: Testing und Red Teaming).
- Änderungen an Modell, Systemprompt, Werkzeugen und Rechten laufen über den Änderungsprozess.
- Der Vorfallprozess kennt Agenten: Rollen, Meldeweg, Beweissicherung der Läufe (siehe Monitoring und Incident Response).
Die 4T2 Solutions GmbH, Herausgeberin von STOP.LI, unterstützt bei der Absicherung von Agenten und MCP-Anbindungen. Ausgangspunkt ist eine konkrete Entscheidung oder ein kontrollierter Pilot.
- OWASP Top 10 for Agentic Applications 2026 (OWASP GenAI Security Project, Dezember 2025)
- Agent Control Standard (ACS) (OWASP GenAI Security Project, 01.09.2026)
- CSA Research Note: OWASP GenAI Top 10 2026 und Agent Control Standard (Cloud Security Alliance, 04.09.2026)
- Agentic AI Threats and Mitigations (OWASP GenAI Security Project, 17.02.2025)
- OWASP Top 10 for LLM Applications 2026 (OWASP, Version 2026, August 2026)
- MCP Security Best Practices (Model Context Protocol, Entwurfsfassung)
- Agentic AI Threat Modeling Framework: MAESTRO (Cloud Security Alliance, 06.02.2025)
- Control Overlays for Securing AI Systems, COSAIS (NIST, laufend)
- Verordnung (EU) 2024/1689 (AI Act), Art. 2, 12, 14 (EU, 13.06.2024)
- MITRE ATLAS (MITRE)
Zitierte Fremdinhalte unterliegen der Lizenz ihrer Herausgeber. Die Seite ist eine Orientierung, keine Rechtsberatung.
© 2026 4T2 Solutions GmbH. Text und eigene Diagramme stehen unter CC BY 4.0.