OWASP Agent Control Standard (ACS): KI-Agenten zur Laufzeit kontrollieren

Vom Antwortgenerator zum Akteur

Klassische LLM-Anwendungen erzeugen Text, den ein Mensch liest, bevor etwas passiert. KI-Agenten planen dagegen selbstständig, rufen Tools auf, schreiben in ein Langzeitgedächtnis und starten Subagenten. Jeder dieser Schritte kann Daten verändern oder nach außen tragen. Die Kontrollfrage lautet deshalb: „Darf genau diese Aktion mit genau diesen Argumenten in dieser Session jetzt stattfinden?“ Beantworten lässt sie sich nur zur Laufzeit — zwischen der Entscheidung des Modells und der Ausführung durch das Framework.

System-Prompts sind keine Kontrollen

Viele Deployments verlassen sich auf Anweisungen im System-Prompt wie „keine Produktionsdaten löschen“. Solche Sätze sind Bitten an ein probabilistisches System, keine durchgesetzten Regeln. Die ACS-Projektseite beginnt ihre Begründung damit: System-Prompts sind keine Kontrollen, bessere Modelle decken Randfälle und adversariale Eingaben nicht ab, proprietäre Guardrails schaffen Anbieterabhängigkeit.

Hersteller und Forschung bestätigen das. OpenAI schreibt am 22.12.2025, Prompt Injection sei „unlikely to ever be fully 'solved'“. In der Studie „The Attacker Moves Second“ (arXiv, 10.10.2025) überwanden adaptive Angriffe zwölf aktuelle Abwehrverfahren, meist mit Erfolgsraten über 90 Prozent — obwohl die meisten ursprünglich Werte nahe null gemeldet hatten. Modellrobustheit senkt das Risiko, beseitigt es aber nicht. Es braucht eine unabhängige Prüfinstanz außerhalb des Modells.

Lethal trifecta und Agents Rule of Two

Simon Willison beschrieb am 16.06.2025 die „lethal trifecta“: Ein Agent, der Zugriff auf private Daten hat, nicht vertrauenswürdigen Inhalten ausgesetzt ist und nach außen kommunizieren kann, lässt sich per Prompt Injection zur Datenexfiltration bringen. Meta erweiterte das am 31.10.2025 zur „Agents Rule of Two“: Innerhalb einer Session soll ein Agent höchstens zwei von drei Eigenschaften kombinieren: nicht vertrauenswürdige Eingaben verarbeiten; auf sensible Systeme oder private Daten zugreifen; Zustand ändern oder extern kommunizieren. Braucht er alle drei, ist mindestens Aufsicht nötig, etwa per menschlicher Freigabe. Meta betont, dass die Regel Least Privilege ergänzt und nicht ersetzt.

VamiSec-Einschätzung: Beide Modelle beschreiben Eigenschaften einer Session, nicht eines Modells. Durchsetzen lassen sie sich nur, wenn eine Instanz jede Aktion und den bisherigen Sessionverlauf sieht. Diesen Kontrollpunkt standardisiert der OWASP Agent Control Standard (ACS). Um nicht vertrauenswürdige Eingaben zu erkennen, braucht es das optionale Profil acs-provenance; ACS-Core allein liefert keine Herkunftsangaben.

Belegte Vorfälle — und was Runtime-Kontrolle begrenzt hätte

Warum die Kontrolle zur Laufzeit sitzen muss

Modellauswahl, Prompt-Härtung und Red Teaming vor dem Go-live bleiben notwendig, sagen aber nicht, was ein Agent in einer konkreten Session tut. Runtime-Kontrolle ergänzt sie: Sie greift vor der Aktion, bewertet den Kontext der ganzen Session und hinterlässt einen rekonstruierbaren Audit-Trail. Die OWASP Top 10 for Agentic Applications 2026 empfehlen für ASI02 (Tool Misuse and Exploitation) eine vorgelagerte Policy-Enforcement-Middleware, ein „Intent Gate“, das Absicht und Argumente vor der Ausführung prüft. ACS wird dort nicht genannt, liefert aber (VamiSec-Einschätzung) einen offenen Wire-Vertrag für genau diesen Kontrollpunkt. Die Policies bleiben Ihre Aufgabe.

Präziser: Der Agent Control Standard (ACS) ist eine Spezifikation des OWASP GenAI Security Project, die festlegt, an welchen Kontrollpunkten (Hooks) ein KI-Agent einer externen Policy-Instanz seine Schritte vorlegt und wie diese mit einer Entscheidung (Disposition) antwortet. Das Format ist JSON-RPC 2.0 mit einem eigenen Feld acs_version, transportiert über HTTP(S) oder stdio. Aktueller Stand ist die Spezifikation v0.1.0, veröffentlicht als Release 0.1.2 (Tag vom 21.09.2026). ACS definiert den Vertrag zwischen Agent und Guardian, nicht die Policies: Was erlaubt ist, entscheidet weiterhin Ihre Organisation.

Die Parteien

Ein Designprinzip trägt die Architektur: Das Sprachmodell darf von den Hooks nichts wissen. Das Framework feuert sie, und Herkunftsangaben (Provenance) werden außerhalb des Ausgabepfads des Modells gesetzt. Nach unserer Lesart soll ein manipuliertes Modell den Kontrollpunkt so weder sehen noch beeinflussen können.

Drei Pillars: Instrument, Trace, Inspect

ACS-Core und sieben Profile

Konformität ist modular aufgebaut. ACS-Core ist die Pflichtbasis, darauf setzen sechs optionale Profile auf, die ein Deployment im Handshake deklariert. Nummerierte Level gibt es nicht — nur Profilnamen, die sich unabhängig kombinieren lassen. Die einzige Abhängigkeit: acs-inspect-dynamic erweitert acs-inspect.

Was ACS-Core garantiert, formuliert die Spezifikation nüchtern: Der Kanal ist authentifiziert, und der Observed Agent befolgt die Entscheidungen. Nicht garantiert ist, dass die Policies streng sind — ein großzügiger Guardian ist konform, nur eben großzügig. Manipulationsevidenz der Audit-Kette auch gegenüber einem kompromittierten Guardian liefern erst acs-crypto und acs-audit, weil die HMAC-Basis ein symmetrisches Verfahren ist. Die Beispielkombinationen der Spezifikation reichen von einer minimalen IDE-Integration mit nur acs-core bis zu einem High-Assurance-Deployment mit allen sieben Profilen.

Das Tier-Modell der Projektseite: Architekturschichten, keine Stufen

1. 1
   Tier 1 · Platform layer

   Agent-Frameworks stellen standardisierte Middleware-Hooks bereit — hier entsteht der Kontrollpunkt.

2. 2
   Tier 2 · Enforcement layer

   Eine Open-Source-Komponente liest deklarative Policies und liefert über diese Hooks Entscheidungen zurück.

3. 3
   Tier 3 · Enterprise layer

   Eigene Klassifikatoren und domänenspezifische Logik docken hinter derselben Schnittstelle an.

Dieses Bild beschreibt, wer welchen Teil beiträgt, nicht, wie konform ein Deployment ist. Für Konformitätsaussagen zählen ausschließlich die Profile. Für Ihre Architekturplanung ist es dennoch nützlich: Es trennt die Frage, welche Plattform die Hooks liefert, von der Frage, wer die Policies betreibt und pflegt.

Von der Beobachtung zur Kontrolle

Die Arbeit begann am 11.05.2025 als „Agent Observability Standard“ (AOS) im GitHub-Umfeld von Zenity und wechselte im Juni 2025 in die OWASP-Organisation, wo AOS als „OWASP other project“ geführt wurde. Die Protokollschicht hieß im Mai und Juni 2025 zwischenzeitlich „ASOP“ (Agent Security & Observability Protocol), bevor sie wieder unter AOS lief. Nach einer Phase mit nur vereinzelten Commits ab Mitte 2025 folgte am 10.04.2026 das Rebranding zum Agent Control Standard. Der neue Name markiert den inhaltlichen Schritt: von der reinen Beobachtung zur Durchsetzung. Danach lief ACS kurz als eigenständiges Projekt außerhalb von OWASP und kehrte im September 2026 zurück — diesmal in das OWASP GenAI Security Project.

Status: Incubator und public preview

ACS ist ein Projekt des OWASP GenAI Security Project und dort der Agentic Security Initiative zugeordnet. In seinen eigenen OWASP-Nest-Metadaten deklariert es Level 2, im Nest-Schema die Stufe „Incubator“; eine Einstufung durch ein OWASP-Gremium ist damit nicht belegt. Der Project Lead bezeichnet den Stand öffentlich als „public preview“ und rät Implementierern ausdrücklich zur Vorsicht. ACS ist kein ISO-, IETF- oder W3C-Standard und keine harmonisierte Norm. Auch formal zeigt sich das frühe Stadium: GitHub-Releases gibt es keine, nur Tags; Spezifikationsprosa und Schemas haben sich zwischen v0.1.1 und v0.1.2 geändert, ohne dass die Spezifikationsversion v0.1.0 hochgezählt wurde.

Wer steuert das Projekt?

Laut GOVERNANCE.md haben Michael Bargury und Ory Segal ACS geschaffen; beide bleiben Projektleiter. Project Lead ist Rock Lambros. Zur Transparenz: Bargury ist CTO und Mitgründer von Zenity, Lambros wird von Zenity als „Director of AI Standards and Governance“ geführt, und die frühen AOS-Commits stammen überwiegend aus dem Zenity-Umfeld. Die Workstreams — Coding Agents, Development (SDK), Identity, Outreach und Spec — leiten Personen aus mehreren Organisationen. Die Projektseite beschreibt ACS als herstellerneutral und gemeinschaftlich gesteuert; das ist eine Selbstbeschreibung. Unsere Einordnung: ein OWASP-Projekt mit starker Zenity-Prägung in Gründung und Leitung.

Entscheidungen laufen über ein Akzeptanz-Gate. Nur Issues mit dem Label status:accepted gelangen ins Backlog; Änderungen an Verhalten, normativem Text oder Code brauchen ein akzeptiertes Issue, Spezifikationsänderungen beginnen als GitHub Discussion, Commits erfordern einen DCO-Sign-off. Entwickelt wird auf dem Branch integration. Erst wenn der Project Lead nach main promotet, werden Site und Schema-URIs neu veröffentlicht. Stand 03.10.2026 wurde main seit dem 10.09.2026 nicht mehr promotet — Änderungen auf integration sind also noch nicht publiziert.

Lizenz: was Sie übernehmen dürfen

Roadmap: was belegt ist

Das nächste Spezifikations-Release v0.2.0 zielt auf März 2027; ein Datum für v1.0 ist nicht festgelegt. Für v0.2 vorgemerkt sind unter anderem Streaming und Interruption, rekursives ASK und Quorum, Multi-Tenant-Isolation, das Cedar-Binding, AgBOM-Föderation über A2A-Peers und das A2A-Wrapping. Das laufende Ziel seit dem Kick-off am 10.09.2026: innerhalb von 90 Tagen eine lauffähige Guardian-Referenzimplementierung, auf Interoperabilität mit Microsofts Agent Governance Toolkit gebenchmarkt, in den Händen externer Evaluatoren. Ob das bis Anfang Dezember 2026 gelingt, ist offen. Ebenfalls offen ist PR #21, der den Pflichtumfang von ACS-Core neu ziehen will. Abweichende Versionsskizzen in Blogbeiträgen sind keine offizielle Roadmap.

Auf dem Wire tragen Hooks das Präfix steps/, etwa steps/toolCallRequest. Daneben gibt es Methoden, die keine nativen steps/*-Hooks sind: agbom/snapshot und agbom/changed für das Inventar, die Liveness-Probe system/ping, den Handshake handshake/hello und den Namespace protocols/MCP/* für gewrappte MCP-Nachrichten. Die Hooks-Seite der Spezifikation zählt 19 Hooks plus zwei AgBOM-Methoden plus Ping als 22 Methoden; das Schema-Paket umfasst insgesamt 44 JSON-Schemas. Einzelne Projekttexte (README, docs/acs.md) nennen noch 16 Lifecycle-Hooks — das ist die Zählung ohne die drei Skill-Hooks.

Das Core-Minimum: sechs Hooks

ACS-Core verlangt mindestens sechs Hooks: sessionStart, userMessage oder agentTrigger, toolCallRequest, toolCallResult, agentResponse und sessionEnd. Alle übrigen soll ein Framework implementieren, sofern es das jeweilige Ereignis beobachten kann; sie werden im Handshake ausgehandelt. Für Ihre Produktbewertung heißt das: Die Aussage „unterstützt ACS“ verrät noch nicht, ob Memory-Schreibvorgänge, Subagenten oder Skills den Guardian überhaupt erreichen.

Die methods_evaluated-Falle

Im Handshake meldet der Observed Agent, welche Methoden er implementiert (methods_implemented). Der Guardian antwortet mit der Liste der Methoden, die er tatsächlich bewertet (methods_evaluated). Sendet der Agent einen Hook, der dort fehlt, muss er ihn als ALLOW-by-default behandeln — der Schritt wird bestenfalls protokolliert, aber nicht geprüft. Die einzige Referenzimplementierung bewertet beispielsweise nur steps/toolCallRequest und steps/toolCallResult, also zwei von 19 Hooks.

toolCallRequest: der zentrale Durchsetzungspunkt

steps/toolCallRequest ist der einzige Hook, für den die Spezifikation ausdrücklich alle fünf Dispositions vorsieht; hier setzen auch die Kontrollparadigmen an. Zentral ist eine MUST-Regel: Frameworks müssen toolCallRequest für jede Aktion feuern, die den Reasoning-Kontext des Agenten verlässt — auch wenn das Framework sie intern nicht als Tool führt. Das umfasst Lese- und Schreibzugriffe auf das Dateisystem, Netzwerkabrufe, Prozessstarts und Shell-Befehle. Was an diesem Hook vorbeiläuft, sieht keine Policy.

Pflicht im Payload sind tool.name und arguments, wobei jeder Argumentwert eine eigene Provenance tragen kann. Optional kommen eine abstrakte capability wie filesystem.delete oder network.egress, das raw_command und ein intent hinzu. Policies können so bewerten, was eine Aktion bewirkt, statt welches Programm sie ausführt.

Hooks mit besonderer Schutzwirkung

• memoryStore ist die Standard-Senke für Einfluss über Sessions hinweg und laut Spezifikation der Ansatzpunkt gegen Memory Poisoning (vgl. ASI06: Memory & Context Poisoning).
• preCompact und postCompact sichern die Verdichtung ab: Die Zusammenfassung muss origin agent_generated tragen und die Herkunft aller verdichteten Einträge erben, damit nicht vertrauenswürdige Inhalte nicht reingewaschen werden.
• subagentStart erlaubt dem Guardian, den Start eines Subagenten zu verweigern; jeder Subagent erhält eine eigene session_id und eine eigene Audit-Kette.
• skillRegister und skillLoad binden Skills an einen Digest: Geladen werden darf nur, was zuvor mit identischer skill_id und identischem Digest genehmigt wurde; nicht zuordenbare Ladevorgänge sollen abgelehnt werden.

Auf dem Wire stehen die Dispositions kleingeschrieben im Feld decision; die Spezifikationsprosa schreibt sie groß (ALLOW, DENY …). Jede Antwort hat in v0.1 den Typ final — Zwischenstände (progress) und Unterbrechungen (interruption) sind erst für v0.2 vorgesehen. Pflicht in jeder Antwort sind type, acs_version, request_id und decision; die request_id spiegelt die des Requests.

MODIFY: zwei Formen, die sich ausschließen

Das Objekt modifications kennt zwei Formen. Entweder ersetzt modified_content den gesamten Payload — dann sind keine weiteren Edits erlaubt. Oder der Guardian schickt strukturierte Edits: redactions (JSON-Pointer-Pfad plus Ersatztext, Standard „[REDACTED]“) und/oder parameter_overrides (Argumentname plus neuer Wert). Beide dürfen gemeinsam auftreten, ihre Ziele müssen aber disjunkt sein: Kein Redaktionspfad darf dasselbe Feld wie ein Override treffen, auch kein über- oder untergeordnetes. Die Spezifikation begründet das so: Eine feste Anwendungsreihenfolge würde Konflikte still auflösen und je nach Reihenfolge geschwärzte Werte wieder freilegen oder bereinigte Werte überschreiben. Verletzt ein Guardian diese Regeln, muss der Observed Agent die Antwort wie ein deny behandeln.

Ein Beispiel: Ein Agent will eine Kundentabelle vollständig abfragen. Der Guardian antwortet mit modify und einem Eintrag in parameter_overrides, der die Abfrage auf 500 Zeilen begrenzt — wie im Simulator-Szenario „Unbegrenzte Datenbankabfrage“. Override-Werte stehen dabei als roher Wert im Objekt, nicht in einer value-Hülle.

ASK: Freigabe mit klaren Regeln

• ask_details verlangt einen approver mit type (human, agent oder service) und id, eine question und timeout_seconds (mindestens 1).
• Läuft die Frist ab, greift timeout_disposition; der Standardwert ist deny.
• Der Guardian muss die Identität des Approvers gegen die Policy prüfen — Approver-Authentifizierung ist Pflicht.
• Nur ein Hop: Approver dürfen selbst kein ask zurückgeben. Quorum und rekursive Freigaben sind auf v0.2 verschoben.
• Kann ein Client ASK nicht auflösen, darf der Guardian kein ask senden. Er weicht auf defer mit timeout_decision deny oder auf deny mit dem Reason-Code approver_unavailable aus — ein stilles allow ist ausgeschlossen.
• Über intent_extension kann eine Freigabe die erlaubten Capabilities für this_request oder die ganze session erweitern. Laut Spezifikation ist das der einzige konforme Weg, den festgelegten Intent nachträglich zu verändern.

Wichtig für die Regulatorik: ASK ist nicht automatisch menschliche Aufsicht. Der Approver kann ein Agent oder ein Service sein, und timeout_disposition lässt sich auf allow stellen. Menschliche Aufsicht nach EU AI Act Art. 14 ist für Hochrisiko-Systeme ab 02.12.2027 (Anhang III) bzw. 02.08.2028 (Anhang I) anzuwenden; KI-Agenten sind nicht per se Hochrisiko. Wer ASK dafür als Baustein nutzt, braucht nach VamiSec-Einschätzung eine Policy mit approver.type human und timeout_disposition deny sowie einen Freigabeprozess, der Entscheidungsmüdigkeit vermeidet. ASK unterstützt dann die Nachweisführung, erfüllt Art. 14 aber nicht allein: Einen Stop-Button kennt v0.1 nicht, nur das schrittweise deny.

DEFER: Entscheidung vertagen, aber begrenzt

defer_details verlangt einen reason (insufficient_context, conflicting_policies, low_confidence oder pending_dependency), eine resolution_method (additional_context, human_approval oder timeout) und resolution_timeout_ms. Für den Fristablauf kennt timeout_decision nur deny oder ask — kein allow — und steht standardmäßig auf deny. Die Prosa fordert das Feld, das Schema führt es nicht als Pflicht; setzen Sie es deshalb immer explizit. Kaskadierende Deferrals müssen je Session begrenzt sein. Achten Sie auf die Einheiten: ASK rechnet in Sekunden (timeout_seconds), DEFER in Millisekunden (resolution_timeout_ms).

Jede Session beginnt mit handshake/hello. Der ClientHello steckt im payload eines normalen Request-Envelopes, der ServerHello kommt als result zurück — ohne decision. Die ausgehandelte Version muss in der Hauptversion mit dem Client übereinstimmen; unbekannte Felder sind zu ignorieren.

Failure Posture: fail-open ist der Default

Der Observed Agent muss für jeden gemeldeten Schritt auf die Entscheidung warten — bis zum ausgehandelten Timeout — und sie anwenden. Ein Framework, das Hooks sendet, das Verdikt aber ignoriert, ist nicht konform. Kommt keine verwertbare Entscheidung an, spricht die Spezifikation von einem decision failure: Der Guardian schweigt, der Transport bricht ab (abgelehnte Verbindung, TLS-Fehler, fehlerhafte Antwort) oder der Guardian liefert einen Fehler statt einer Entscheidung. In allen drei Fällen greift on_decision_failure, und der Standardwert ist proceed: Die Aktion läuft ungeprüft weiter. Fail-closed (deny) muss ein Deployment ausdrücklich konfigurieren.

Die Spezifikation benennt den Preis offen: Wer den Kanal stören kann, macht aus Kontrolle bloße Protokollierung. Als Gegengewicht gilt eine harte Pflicht — jeder Schritt, der ohne Entscheidung weiterläuft, muss als Audit-Event erfasst werden. Trifft eine Entscheidung doch noch innerhalb der Frist ein, muss der Agent sie befolgen, unabhängig von der Posture.

Startup-Posture: wenn schon der Handshake scheitert

Ist der Guardian beim Sessionstart nicht erreichbar oder antwortet er ohne ServerHello, gilt eine außerhalb des Protokolls konfigurierte Startup-Posture: proceed (die Session startet ungeschützt) oder refuse. Auch hier ist proceed der Default, damit ein Guardian-Ausfall keine neuen Sessions blockiert. Eine ungeschützt gestartete Session muss im eigenen Audit-Log des Deployments stehen. Eine ausdrückliche Ablehnung durch den Guardian, etwa SESSION_REFUSED, gilt dagegen als Entscheidung und nicht als Ausfall.

Timeouts: kein Default in der Spezifikation

Einen numerischen Standard-Timeout legt die Spezifikation nicht fest. timeout_config.default_ms ist im ServerHello Pflicht, der Wert aber Sache des Deployments; per_method_ms erlaubt abweichende Werte je Methode. Das Handshake-Schema erinnert daran, dass jede Millisekunde Timeout im ungünstigsten Fall Latenz für den Schritt bedeutet, und empfiehlt, Fristen je Methode an der Latenztoleranz auszurichten statt an einem großzügigen Pauschalwert. Die Referenzimplementierung nutzt 5000 ms — ein Implementierungswert, keine Vorgabe. Ein sensitivitätsbasiertes Timeout-Modell ist für v0.2 vorgesehen. Zur Begriffsklärung: ACS_ON_DECISION_FAILURE ist eine Umgebungsvariable des Referenz-Guardians, die den Wert von on_decision_failure setzt — kein Feld der Spezifikation.

Ping beweist keine Durchsetzung

system/ping ist eine reine Liveness-Probe: Der Guardian muss immer allow antworten, der Ping braucht keine Signatur und wird nicht in die Audit-Kette geschrieben. Ein Guardian kann also Pings beantworten und zugleich jeden signierten Hook ablehnen. Die Spezifikation empfiehlt deshalb, Decision Failures auf dem Hook-Pfad direkt zu überwachen.

Zwei Schichten, feste Reihenfolge

Die deterministische Schicht bewertet jeden Hook zuerst. Sie entscheidet selbst oder delegiert an die Agent-Schicht — laut Spezifikation gesteuert über eine Chain-Konfiguration mit den Modi „*“, on_ask oder musterbasiert. Ein Format für diese Konfiguration definiert v0.1 allerdings nicht. Die Agent-Schicht erhält dieselben Eingaben plus das Zwischenergebnis der deterministischen Schicht, aber niemals den Policy-Code. Ihre Antwort muss auf dem Rückweg erneut die deterministische Schicht passieren.

1. 1
   Hook trifft ein

   Request-Envelope, SessionContext, Intent und, falls vorhanden, Provenance gehen an die Policy-Engine.

2. 2
   Deterministische Bewertung

   Policy-as-Code — in v0.1 mit OPA/Rego als Startreferenz — liefert allow, deny, modify, ask oder defer oder delegiert.

3. 3
   Optionale LLM-Schicht

   Bewertet Fälle, die deterministisch nicht entscheidbar sind; behandelt nicht vertrauenswürdige Felder als Daten und sieht keinen Policy-Code.

4. 4
   Rückprüfung und Antwort

   Das Ergebnis passiert erneut die deterministische Schicht; metadata.evaluator weist deterministic, agent oder composite aus.

5. 5
   Protokollierung

   Jede Entscheidung wird mit Begründung, Modellkennung und, sofern verfügbar, Konfidenz geloggt.

Policy-Engine: Schnittstelle statt Produkt

ACS definiert die Schnittstelle zur deterministischen Engine, nicht die Engine selbst. Die Eingabe besteht aus Request-Envelope, SessionContext, Intent und Provenance, die Ausgabe aus einem Entscheidungs-Envelope, optional mit einer Delegation an die Agent-Schicht (delegate_to). Zusätzlich setzt ACS Konventionen, darunter: keine externen HTTP-Aufrufe in kanonischen Policies. Das stützt Determinismus und Latenz.

Pflichten der LLM-Schicht

• Nicht vertrauenswürdige Daten sind Daten, keine Anweisungen; die betreffenden Felder müssen im Prompt umhüllt oder gequotet werden.
• Kein Zugriff auf den Policy-Code der deterministischen Schicht.
• Jede Entscheidung mit Begründung, Modellkennung und Konfidenz (wenn verfügbar) protokollieren; bei evaluator agent oder composite ist model_id anzugeben.
• Fristen folgen dem im Handshake ausgehandelten timeout_config.
• Die gesamte Schicht ist in v0.1.0 optional: Rein deterministische Deployments sind voll konform.

Kontrollparadigmen ohne eigene Wire-Erweiterung

Die Spezifikation nennt vier Paradigmen als Ziele für v0.1. Ein Guardian drückt sie über dieselben Felder aus — reason_codes, policy_references, policy_data und cited_provenance_ids. Kombiniert ein Deployment mehrere Paradigmen, darf eine einzige Entscheidung alle zitieren.

FIDES, CaMeL und AARM-artige Regeln brauchen Herkunftsangaben und setzen deshalb das Profil acs-provenance voraus; reines IBAC nicht. ACS implementiert keines dieser Verfahren selbst, es liefert die Felder, über die ein Guardian sie anwendet und begründet. ACS verhindert also keine Prompt Injection — es schafft den Kontrollpunkt, an dem Policies gegen deren Folgen greifen.

Betrieb: Latenz und Verfügbarkeit (VamiSec-Einschätzung)

• Latenz: Jede Prüfung liegt im kritischen Pfad des Agenten. Halten Sie die deterministische Schicht lokal und ohne externe Aufrufe, reservieren Sie die LLM-Schicht für wenige unklare Fälle und messen Sie evaluation_duration_ms je Methode.
• Verfügbarkeit: Mit fail-closed wird der Guardian betriebskritisch. Betreiben Sie ihn nah am Agenten und redundant. Die Referenzimplementierung dokumentiert das Risiko selbst: Sie schreibt Logs synchron im Entscheidungspfad, sodass eine langsame Festplatte jede laufende Entscheidung blockiert.
• Policy-Lifecycle: Versionieren Sie Policies und geben Sie policy_version in jeder Entscheidung zurück; die Spezifikation sieht das für die Rekonstruktion historischer Policy-Stände vor.
• Abgrenzung: Der Guardian ersetzt weder Sandbox noch IAM, Secrets-Management oder Egress-Firewall. Aktionen, die toolCallRequest umgehen, bleiben für ihn unsichtbar.

Die einzige Referenzimplementierung betreibt Microsofts Agent Governance Toolkit unverändert hinter dem ACS-Wire. Sie ist ausdrücklich ein Proof of Concept: zwei von 19 Hooks live, keine HMAC-Signatur, Default fail-open. Sie demonstriert das Muster für zwei Clients (Claude Code und OpenCode), ist aber nicht für den Produktivbetrieb gedacht.

Zwischen Observed Agent und Guardian Agent laufen Entscheidungen, die Aktionen freigeben oder blockieren. Wer diesen Kanal manipulieren kann, verwandelt ein deny in ein allow oder spielt eine alte Freigabe erneut ein. Der OWASP Agent Control Standard (ACS) behandelt die Kanalsicherheit daher als Teil der Pflicht-Baseline ACS-Core, nicht als optionales Profil.

Baseline-Signatur: HMAC-SHA256 mit Session-Schlüssel

ACS-Core verlangt auf jedem Request und jeder Response eine Signatur über das kanonische Envelope. Die Baseline, die diese Pflicht erfüllt, ist HMAC-SHA256. Der Schlüssel wird pro Session per HKDF abgeleitet — aus Schlüsselmaterial des Deployments (ein Pre-Shared Secret oder eine Kanalbindung wie ein TLS-Exporter) zusammen mit der session_id. Einen Schlüsselaustausch im Protokoll definiert v0.1 nicht. Signiert wird die RFC-8785-Kanonisierung (JCS) des Envelopes ohne das Feld signature; der Empfänger berechnet diese Form neu und weist eine nicht passende Signatur zurück. TLS allein genügt ausdrücklich nicht, weil es keine einzelne Nachricht für das Audit bindet. Ausgenommen von der Signaturpflicht ist nur die Liveness-Methode system/ping.

Zwei Details sind für die Architektur relevant. Im JSON-Schema ist signature optional, normativ in ACS-Core aber Pflicht — eine reine Schema-Validierung erkennt fehlende Signaturen also nicht. Und die Spezifikation legt Salt, Info-String, Hash-Funktion und Schlüssellänge für HKDF nicht fest; zwei Implementierungen können daher unterschiedliche Schlüssel ableiten. Nach unserer Einschätzung gehören diese Parameter in die Schnittstellenvereinbarung zwischen Plattform- und Guardian-Betrieb.

Replay-Schutz

Jeder Request trägt eine request_id (UUID), einen timestamp und optional eine nonce. Der Guardian muss Requests ablehnen, deren Zeitstempel außerhalb des ausgehandelten Fensters skew_window_ms liegt (empfohlener Default 300 000 ms, also fünf Minuten), und doppelte request_id-Werte innerhalb einer Session zurückweisen; doppelte Nonces sollte er ablehnen. Daraus folgt eine leicht übersehene Betriebsanforderung: synchronisierte Uhren auf beiden Seiten.

Audit-Chain: Hash-Kette mit veröffentlichtem Kopf

Der Guardian führt pro Session einen SessionContext, eine append-only-Kette von ContextEntries. Jeder Eintrag erhält einen entry_hash: SHA-256 über die JCS-kanonisierte Entry ohne Hash-Felder, verkettet mit dem Hash des Vorgängers; der erste Eintrag hat previous_hash null. Andere Kanonisierungen sind in v0.1 nicht zulässig. Entscheidend ist die Veröffentlichung: Für jeden content-bearing Step muss der Guardian den aktuellen chain_hash in seiner Response mitliefern, gedeckt durch die Response-Signatur. Die Spezifikation nennt den Grund offen: Hielte der Guardian den Kettenkopf privat, könnte er etwa ein deny streichen, die Kette ab dieser Stelle neu berechnen und später eine bereinigte Historie vorlegen. Wer den Verkehr mitschneidet, erkennt eine nachträglich umgeschriebene Kette.

Was die Kette belegt — und was nicht

• Pflichtfelder eines ContextEntry sind nur entry_id, step_id, step_type und entry_hash. Der request_hash über den Request-Inhalt ist in ACS-Core nur empfohlen (SHOULD) und erst im Profil acs-audit Pflicht. Ohne ihn belegt die Kette, dass ein Schritt stattfand, aber nicht, was angefragt wurde.
• Das ContextEntry-Schema kennt kein Feld für Disposition, Begründung oder Approver. Entscheidungen hält ACS normativ als Trace-Events fest (Profil acs-trace, Kapitel 9); nur eine Intent-Erweiterung schreibt einen eigenen Eintrag mit der Approver-Identität (Kapitel 11).
• HMAC ist symmetrisch: Der Guardian hält den Schlüssel und könnte einen umgeschriebenen Kettenkopf neu signieren. Geschützt ist der Kanal gegen Manipulation im Netz, nicht gegen einen kompromittierten Guardian.
• Nichtabstreitbarkeit gegenüber Dritten entsteht erst mit acs-crypto: mindestens ML-DSA-65 (MUST), SLH-DSA-128s (SHOULD), Hybridverfahren optional.
• Einen Abgleich zwischen mehreren Guardians gibt es in v0.1 nicht (Issue #18, zurückgestellt).

Der normative Beitrag von Trace ist das Vokabular: Span-Namen, Attribut-Schlüssel, Event-Klassen und die Zuordnung von Dispositions zu Schweregraden. Übertragen wird per OTLP (gRPC oder HTTP) an bestehende Backends; der Wire-Namensraum trace/* ist in v0.1.0 nur reserviert. Erklärtes Ziel ist, dass ACS-Events ohne Spezialparser in SIEM-Pipelines passen. Die OTel- und die OCSF-Erweiterung tragen im Repository den Status „Working draft“. Trace ist das optionale Profil acs-trace. Wer es beansprucht, muss für jeden unterstützten Step mindestens eines der beiden Formate mit Pflichtattributen ausgeben, jede Entscheidung mit Disposition, Evaluator und — falls vorhanden — Begründung festhalten und Provenance-Fakten aus dem Hook auf das Event übertragen.

OpenTelemetry: Spans pro Hook, Entscheidungen als Span-Event

Die Span-Hierarchie ist deterministisch: ein Root-Span acs.session pro Session, darunter acs.turn je Turn und ein Step-Span je Hook. Entscheidungen sind keine eigenen Spans, sondern ein Span-Event acs.decision am Step-Span; Verdikt und gesteuerte Aktion teilen so denselben Elternkontext. Pflichtattribute des Events sind acs.decision und acs.evaluator (deterministic, agent oder composite). Für Tool-Aufrufe verwendet ACS die Span-Namen gen_ai.tool.call und gen_ai.tool.result. Achtung: In den OpenTelemetry-GenAI-Konventionen (Stand Oktober 2026 im Status „Development“) ist gen_ai.tool.call nur ein Attribut-Präfix, der empfohlene Span-Name lautet dort execute_tool {gen_ai.tool.name}. Auf diese Konventionen ausgerichtete Dashboards und Abfragen passen daher nicht ohne Anpassung zu ACS-Tool-Spans.

SIEM-Use-Cases für Agenten

Grenzen, die Sie einplanen sollten

• Best effort: Trace darf die Durchsetzung nie blockieren. Fällt die Senke aus, geht die Entscheidung trotzdem an den Observed Agent — Telemetrie kann also lückenhaft sein.
• Selbstauskunft: Trace-Events entstehen in der beobachteten Umgebung und werden erst durch Attestierung einer externen Partei zu Evidenz.
• Skill-Lücke: Die Mappings decken 16 der 19 nativen Hooks plus die beiden agbom-Methoden ab. skillRegister, skillLoad und skillUnload haben weder ein OTel- noch ein OCSF-Mapping.
• Doku-Drift: Die Provenance-Ablage in OCSF ist widersprüchlich (enrichments im normativen Mapping, unmapped.acs.provenance im Leitfaden). Die Beispielseite mit Splunk- und Elastic-Abfragen nutzt noch den Altnamen ASOP und OCSF 1.0.
• Datenschutz: Spans können Prompts und Tool-Argumente enthalten. Die Spezifikation empfiehlt Redaction schon beim Emittieren; nach unserer Einschätzung gehört das verbindlich in das Logging-Konzept.

Die AgBOM ist laut Spezifikation ein abfragbares, dynamisches Inventar der Komponenten, die ein Observed Agent nutzt. Die Begründung ist präzise: Jede Policy, die davon abhängt, was ein Agent ist — welches Modell, welche Tools —, wird ohne Inventar unüberprüfbar. Hängt eine Guardian-Policy vom Inventar ab, etwa beim Bann eines Modells oder Tools, muss das Deployment das Profil acs-inspect umsetzen. Die kanonische AgBOM ist ein Komponentengraph, abgelegt als flache Liste mit Referenzen per ID, damit sich Stände per Diff vergleichen lassen.

Acht Komponententypen

snapshot und changed: zwei Wire-Methoden

agbom/snapshot sendet der Observed Agent einmal pro Session nach sessionStart und vor dem ersten content-bearing Hook; die Nachricht enthält die vollständige AgBOM. agbom/changed meldet Mutationen — hinzugefügte, entfernte oder geänderte Komponenten als Diff oder als vollständigen Snapshot — und kann eine Ursache tragen, etwa component_upgraded, discovery oder user_action. Beide Ereignisse gehen in die Audit-Chain. Der Guardian darf per deny eine Session mit gebannter Komponente ablehnen oder einen Hot-Swap blockieren.

Für die Profilwahl wichtig: Wer nur acs-inspect beansprucht, liefert genau einen Snapshot pro Session und verfolgt keine Änderungen. Laufzeitänderungen werden erst mit acs-inspect-dynamic sichtbar. Die Snapshot-Auslöser renegotiation und policy_request verweisen auf Mechanismen, die erst mit v0.2 spezifiziert werden sollen — in v0.1 ist praktisch nur session_start belastbar. Jede Komponente soll außerdem eine registration_provenance tragen (unter acs-provenance Pflicht). Damit lässt sich unterscheiden, ob eine Komponente aus der Konfiguration stammt oder zur Laufzeit hinzukam.

Serialisierungen: CycloneDX, SPDX, SWID

Auf dem Wire geht immer die kanonische Form; der Guardian rendert Serialisierungen auf Anfrage für nachgelagerte Werkzeuge. Ein acs-inspect-Deployment muss mindestens eine davon anbieten: CycloneDX 1.6, SPDX 3.0 oder SWID (ISO/IEC 19770-2). Alle drei Mappings haben den Status „Working draft“; die Abbildungen auf CycloneDX und SPDX sind teils nicht schema-valide. Das CycloneDX-Mapping nutzt Typnamen wie ai-model oder service als Komponententyp, die CycloneDX 1.6 so nicht kennt; das SPDX-Mapping verwendet Klassen und Beziehungen, die es in SPDX 3.0.1 nicht gibt. Planen Sie Exporte deshalb mit eigener Validierung. CycloneDX selbst liegt seit Oktober 2025 in Version 1.7 vor.

Abgrenzung: AgBOM, AI-SBOM, CRA-SBOM

Feld-Provenance: Fakten statt Vertrauenslabel

Provenance beantwortet, woher ein Datenelement kam und wie es an seinen Ort gelangte. Ein Provenance-Objekt trägt eine provenance_id, ein origin mit einem von sieben Werten — user_input, system, tool_output, retrieved, agent_generated, a2a_inbound, external — sowie optional source_id (etwa Tool-Name, URL oder Pfad) und derived_from als Liste der Vorgänger. Die Angaben hängen an datentragenden Feldern, bei toolCallRequest sogar an jedem einzelnen Argument. Eine Policy kann so einen konkreten Datenfluss treffen statt den ganzen Aufruf.

• Framework-gesetzt: origin, source_id und derived_from vergibt deterministischer Code außerhalb des LLM-Ausgabepfads. Das LLM anzuweisen, Provenance zu erzeugen, ist nicht konform.
• Transitive Lineage: Abgeleitete Daten erben die Herkunft ihrer Eingaben, auch über Zusammenfassung und Compaction hinweg. Eine Zusammenfassung fremder Tool-Ausgaben bleibt damit als solche erkennbar.
• Kein Trust-Feld: Ein trust-Wert ist in v0.1 nur reserviert, nicht schematisiert. Der Guardian leitet Vertrauen aus origin und source_id gegen seine Policy ab; durch LLM-Verarbeitung wird nicht vertrauenswürdiges Material nie vertrauenswürdig (Monotonie-Regel).
• Alles oder nichts: Mit provenance_producer: deterministic muss jedes datentragende Feld Provenance tragen; Teilbefüllung ist nicht konform. Meldet der Client provenance_producer: none, obwohl die Policy Provenance verlangt, lehnt der Guardian die Session schon im Handshake mit PROVENANCE_REQUIRED ab.

Provenance gehört nicht zu ACS-Core, sondern zum Profil acs-provenance. Es ist Voraussetzung für Durchsetzungsparadigmen wie FIDES, CaMeL und AARM, nicht aber für reines intent-basiertes Autorisieren (IBAC). ACS verhindert keine Prompt Injection. Es schafft den Kontrollpunkt, an dem eine Policy die Folgen begrenzen kann — etwa indem sie eine E-Mail blockiert, deren Empfänger und Inhalt aus einem nicht vertrauenswürdigen Retrieval-Ergebnis stammen. Sensitivitäts- oder IFC-Labels sind nicht Teil des Standards; sie liegen beim Guardian oder Deployment.

Session Intent: der festgeschriebene Zweck

Intent ist in ACS kein Wire-Format, sondern ein Governance-Konzept: Er bindet Aktionen an einen autorisierten Zweck, und zwar bevor nicht vertrauenswürdige Daten Einfluss nehmen können. Intent.parsed, die für die Session autorisierte Capability-Menge, wird bei sessionStart oder beim ersten agentTrigger festgelegt. Danach dürfen weder das LLM noch Tool-Ausgaben noch Daten aus nicht vertrauenswürdigen Kanälen sie ändern; ist der Intent bei sessionStart gesetzt, muss ein späterer agentTrigger mit abweichendem Intent abgelehnt werden.

Der einzige konforme Weg zur Erweiterung ist eine intent_extension, die ein Approver über den ask-Ablauf zurückgibt — mit Pflichtangaben zu Capabilities und Scope. Bei scope this_request gilt die Erweiterung nur für die laufende Anfrage. Bei scope session hängt der Guardian die Capabilities an, schreibt einen ContextEntry vom Typ intent_extension mit der Approver-Identität und führt die Provenance der Erweiterung getrennt von der des ursprünglichen Intent. Unter scope_mode strict darf er keine Erweiterung honorieren, die die Policy im strikten Modus verbietet. Für CISOs ist das nach unserer Einschätzung der Hebel gegen schleichende Rechteausweitung: Jede Ausweitung braucht eine authentisierte Freigabe.

Identity: normativ schlank, vieles in Arbeit

Die Signatur von ACS-Core authentisiert den Kanal zwischen Observed Agent und Guardian symmetrisch. Sie ist weder eine Authentifizierung des Principals noch Nichtabstreitbarkeit — beides sollten Sie in Architektur und Nachweisen nicht vermischen.

MCP-Wrapping: spezifiziert, mit offener Pflichtfrage

Der Namespace protocols/MCP/* ist der kanonische Weg, MCP-Nachrichten zum Guardian zu tragen, etwa protocols/MCP/tools/call. Die MCP-Nachricht bleibt dabei unverändert; ACS legt Envelope, Entscheidungsvertrag und Audit-Chain-Regeln darüber. Der Ablauf ist zweistufig: Der Agent legt die gewrappte Anfrage dem Guardian vor, setzt dessen Entscheidung durch, leitet die Nachricht laut Ablaufbeschreibung nach einem allow an den MCP-Server weiter und lässt auch dessen Antwort prüfen, bevor er sie verarbeitet.

MCP-Tool-Aufrufe (tools/call) darf ein Deployment in die generischen Hooks steps/toolCallRequest und steps/toolCallResult zusammenführen, wenn Policies auf Tool-Ebene genügen. Das Wrapping soll zum Einsatz kommen, wenn die Policy MCP-spezifische Unterschiede braucht: Capability-Aushandlung bei initialize, serverseitige Prompt-Vorlagen (prompts/get), Ressourcenzugriffe (resources/read) und Benachrichtigungen (notifications/*). Unabhängig davon gilt: Frameworks müssen toolCallRequest für jede Aktion feuern, die den Reasoning-Kontext verlässt — auch für eingebaute Datei-, Netzwerk- oder Shell-Operationen.

MCP 2026-07-28: die Spec-Prosa hinkt hinterher

Seit dem 28.07.2026 ist die MCP-Revision 2026-07-28 aktuell (Stand Oktober 2026). Sie macht den Protokollkern zustandslos, schafft den initialize-Handshake ab und erklärt unter anderem Sampling und Roots für veraltet. Der ACS-Namespace protocols/MCP/* ist versionsneutral; die Revision 2025-06-18 erscheint in der Spezifikation nur als Beispiel. Die Prosa setzt aber noch die ältere Semantik voraus und nennt die initialize-Aushandlung ausdrücklich als zu steuernden Punkt. Ob das die Wrapper praktisch beeinträchtigt, lässt die Spezifikation offen; eine belastbare Analyse liegt uns nicht vor. Nach unserer Einschätzung sollten MCP-lastige Architekturen die generischen Tool-Hooks als primären Kontrollpunkt einplanen.

A2A: reserviert für v0.2

Der Namespace protocols/A2A/* ist in v0.1 nur reserviert; normative Wrapping-Semantik ist für v0.2 vorgesehen (Zielmarke für v0.2.0: März 2027). Die A2A-Seiten im Repository stammen aus der AOS-Zeit 2025 und sind nicht schema-kompatibel. Sichtbar werden A2A-Beziehungen heute nur indirekt: über agentTrigger mit trigger_type a2a_inbound und über a2a_peer-Komponenten in der AgBOM. In-Process-Subagenten deckt ACS dagegen mit subagentStart und subagentStop ab; jeder Subagent erhält eine eigene Session mit eigener Audit-Chain, die der Parent über den final_chain_hash referenziert, ohne die Ketten zu verschmelzen.

Skill-Lebenszyklus: register, load, unload

Der Digest deckt das vollständige ladbare Artefakt ab, einschließlich gebündelter Modellgewichte oder Adapter; in der AgBOM persistiert werden nur Referenz und Digest, nicht der Inhalt. Auf ein vom Framework gemeldetes digest_verified soll sich der Guardian nicht verlassen, sondern selbst gegen seine Freigabe vergleichen. Die Grenze benennt das Design-Proposal zum Skill-Lebenszyklus im Repository offen: Der Digest bindet das registrierte Artefakt, nicht Code, den ein Skill später nachlädt — solches Nachladen läuft als network.egress oder process.execute über die regulären Tool-Hooks. Marketplace-Scanning vor der Veröffentlichung ist nicht Teil von ACS, und für die drei Skill-Hooks fehlt noch ein Trace-Mapping (Kapitel 9).

ACS ist ein Projekt des OWASP GenAI Security Project und laut eigenen OWASP-Nest-Metadaten auf Level 2 (Incubator) eingestuft; der Project Lead bezeichnet den Stand als „public preview“. ACS ist weder ein ISO-, IETF- noch W3C-Standard und auch keine harmonisierte Norm.

Was v0.1 bereits leistet

Trotz des frühen Stadiums liefert v0.1 Substanz: ein gemeinsames Vokabular aus 19 Hooks und fünf Dispositions, 44 veröffentlichte JSON-Schemas, eine klar beschriebene Failure Posture mit Auditpflicht für jeden Bypass und eine Spezifikation, die ihre eigenen Lücken offen benennt. Nach unserer Einschätzung reicht das, um Anbieter an einem offenen, gemeinsamen Maßstab zu messen und eigene Kontrollpunkte so zu schneiden, dass sie an spätere Versionen anschlussfähig bleiben — nicht aber, um sich auf Konformitätsetiketten zu verlassen.

Konformität ist Selbstdeklaration

Im Handshake erklärt der Observed Agent, welche Profile er unterstützt (profiles_supported), und der Guardian, welche er akzeptiert (profiles_accepted). Es gibt genau sieben Profile: acs-core als Pflicht sowie acs-trace, acs-inspect, acs-inspect-dynamic, acs-provenance, acs-crypto und acs-audit. Stufen oder Level existieren nicht. Wer Konformitätsansprüche prüft, beantwortet die Spezifikation selbst: in v0.1.0 niemand. Es gibt keine Testsuite, kein Register konformer Implementierungen und keine Stelle, die strittige Ansprüche klärt (Issue #19, offen, Priorität P1). ACS-Core garantiert zudem nur zweierlei — einen authentisierten Kanal und dass der Observed Agent die Entscheidungen des Guardians befolgt. Strenge Policies garantiert es nicht: Auch ein großzügiger Guardian ist konform.

Referenzimplementierung: der ehrliche Ist-Stand

Die einzige Referenzimplementierung ist ausdrücklich ein Proof of Concept. Sie betreibt Microsofts Agent Governance Toolkit (AGT) unverändert als Policy-Engine hinter dem ACS-Wire, mit Host-Anbindungen für Claude Code und OpenCode. Sie beansprucht acs-core nur eingeschränkt („qualified“) und keines der sechs optionalen Profile. Ein Interoperabilitäts-Benchmark mit AGT liegt nicht vor; er ist das Ziel des 90-Tage-Fensters seit dem Kick-off am 10.09.2026. Eine Unterstützung von ACS durch Microsoft lässt sich daraus nicht ableiten. Achtung Namensgleichheit: In der AGT-Dokumentation steht „ACS“ für Microsofts eigene „Agent Control Specification“ (02.06.2026), die Policy-Sprache von AGT — nicht für den OWASP-Standard.

Offene Spec-Lücken mit Praxisrelevanz

• Default fail-open: on_decision_failure und Startup-Posture stehen auf proceed; fail-closed (deny bzw. refuse) müssen Sie bewusst konfigurieren.
• Kein Stopp-Mechanismus: v0.1 kennt keinen Kill-Switch; Unterbrechung (interruption) und Streaming sind für v0.2 vorgesehen. In v0.1 stoppt man einen Agenten nur schrittweise per deny.
• Pflichtumfang in Bewegung: Ein offener Vorschlag (PR #21) würde modify und system/ping auf SHOULD herabstufen.
• Interop-Lücken (eigene Analyse): HKDF-Parameter, die Signatur des Handshakes und die Eingabe für request_hash sind unterbestimmt.
• Doku-Drift: Einzelne Seiten nennen noch 16 statt 19 Hooks oder nur drei Dispositions. Normativ sind Spezifikation und Schemas.

Vorweg drei Einordnungen. Erstens begründet ACS keine Konformitätsvermutung; der Spezifikationstext enthält keine Zuordnung zu AI Act, NIS2, DORA, CRA oder ISO/IEC 42001 — alle Zuordnungen unten sind VamiSec-Ableitungen. Zweitens sind KI-Agenten nicht per se Hochrisiko-Systeme. Die Hochrisiko-Pflichten aus Kapitel III Abschnitte 1–3 der VO (EU) 2024/1689 gelten nach dem Digital Omnibus (VO (EU) 2026/1744) ab 02.12.2027 für Anhang III und ab 02.08.2028 für Anhang I; Art. 50 gilt seit 02.08.2026. Drittens hängt jede Argumentation an den Profilen: ACS-Core allein enthält weder Trace noch AgBOM noch request_hash.

Einstieg in fünf Schritten

1. 1
   InventarAgenten erfassen und einstufen

   Erfassen Sie Agenten, Modelle, Tools, MCP-Server und Skills und klären Sie je Einsatz die Einstufung nach AI Act. Ergebnis: ein Agenten-Register mit Risikoklasse, Verantwortlichen und Datenzugriffen.

2. 2
   ArchitekturKontrollpunkte und Profile festlegen

   Prüfen Sie, welche Hooks Ihre Plattform tatsächlich feuert und welche der Guardian im Handshake unter methods_evaluated bestätigt: Alles andere gilt als allow-by-default und ist ungeschützt. Wählen Sie Profile nach Nachweisbedarf, etwa acs-core plus acs-trace und acs-audit für Logging-Pflichten.

3. 3
   PolicyPolicies als Code formulieren

   Die deterministische Schicht läuft zuerst (v0.1-Referenz: OPA/Rego). Formulieren Sie Regeln für destruktive Befehle, Egress und Zahlungen, verlangen Sie für konsequenzreiche Aktionen ask mit menschlichem Approver und timeout_disposition deny und referenzieren Sie Policy-Versionen in policy_references.

4. 4
   BetriebFailure Posture entscheiden und testen

   Setzen Sie für Agenten mit hohem Schadenspotenzial on_decision_failure deny und die Startup-Posture refuse. Testen Sie Guardian-Ausfall, Replay und Signaturfehler und überwachen Sie Decision-Failures direkt, denn ein erfolgreicher Ping beweist keine gesunde Durchsetzung.

5. 5
   NachweisTrace anbinden und Nachweise führen

   Exportieren Sie OCSF oder OpenTelemetry ins SIEM, setzen Sie die Use-Cases aus Kapitel 9 um und legen Sie Aufbewahrungsfristen fest. Sichern Sie den Kettenkopf extern und prüfen Sie Konformitätsangaben von Anbietern durch eigene Tests.

Eine Vertiefung mit 100-Tage-Programm, Rollenmodell, Kennzahlen und Prüffragen an Agent-Plattformen bietet das CISO-Whitepaper „Agent Control für CISOs“, das Sie weiter unten auf dieser Seite anfordern können. VamiSec begleitet Bewertung, Architektur, Policy-Design und Tests als unabhängige Beratung; VamiSec ist nicht Teil des ACS-Projekts.