heygrc
Für ki-sicherheitsingenieure

Die Architektur hat sich geändert. Das Verantwortungsmodell nicht.

Für KI-Sicherheitsingenieure, die damit beauftragt sind, Agenten und die von ihnen genutzten Systeme abzusichern. Die Arbeit umfasst AppSec, IAM, Daten und Governance. Der Code ist der Ort, an dem diese Pflichten aufeinandertreffen.

Cloud-Sicherheit wurde früher als zusätzliche Aufgabe für das bestehende Team behandelt. Dann änderte sich die Architektur so stark, dass das alte Verantwortungsmodell nicht mehr skalierbar war, und die Rolle wurde zu einer eigenen Funktion. Bei KI ist dieser Punkt erreicht.

Ein Agent kann Daten analysieren, ein Tool auswählen, Berechtigungen erben und eine Aktion in einem anderen System ausführen. Agentenidentität, Prompt-Pfade, RAG- und MCP-Verkabelung, Sandboxing und Runtime-Containment tauchen nun in Stellenbeschreibungen von Unternehmen auf, die dies früher in AppSec integriert haben. Die organisatorische Lücke, die diese Rollen füllen, ist die Verantwortung für die gesamte Kette. Die Lücke bei Code-Reviews ist enger: Die Berechtigungen, Protokolle und menschlichen Überwachungspfade, die die Kette real machen, werden in Pull Requests festgelegt.

Die Kette ist organisatorisch. Der Diff ist immer noch eine Kontrolle.

Runtime-Tools beobachten den Agenten. heygrc liest die Änderung, die ihm die Berechtigung erteilt hat. Linters und SAST sind nicht dafür gebaut, zu wissen, welche Frameworks Sie verwenden. Ein Prompt-Injection-Test erkennt nicht, dass der letzte PR den Override-Pfad gelöscht oder die Tool-Calling-Rolle erweitert hat. heygrc ist darauf ausgelegt, jeden Pull Request gegen die von Ihnen ausgewählten Frameworks zu prüfen und die Kontrolle zu zitieren, die eine Änderung betrifft: Agentenidentität und -zugriff, Protokollierung des Systembetriebs, die Möglichkeit des Menschen, einzugreifen.

Art. 12 und Art. 14 sind Pflichten des Hochrisiko-Regimes. heygrc stuft das Risikoniveau Ihres Systems nicht ein und führt Ihre Konformitätsbewertung nicht durch. Ob diese Artikel gelten, ist Ihre eigene Einschätzung. Es sandboxed den Agenten nicht, testet nicht auf Prompt-Injection oder begrenzt einen außer Kontrolle geratenen Tool-Aufruf zur Laufzeit. Es prüft die Code-Änderung gegen die von Ihnen ausgewählten Frameworks und zitiert die Kontrolle. Sie bleiben der Richter darüber, was blockiert und was freigegeben wird.

Was es für dich erkennt

Änderungen, die wie normaler Code aussehen.

Einige der kontrollrelevanten Änderungen, die heygrc für diesen Fall markieren soll, jeweils mit Verweis auf die betroffene Klausel.

  • Ein Agent oder eine Tool-Calling-Rolle wird auf einen Wildcard erweitert

    SOC 2 CC6.1
  • Die menschliche Eingriffsmöglichkeit wird aus der Agent-Reviewer-Konsole entfernt

    EU AI Act Art. 14
  • Die Inferenz-Protokollierung wird von einem entscheidungsfähigen Agenten entfernt

    EU AI Act Art. 12
Mehr erfahren

Die Frameworks, die hier am wichtigsten sind.

Anleitung: EU AI Act für Entwickler

heygrc markiert kontrollrelevante Änderungen und zitiert die Klausel, sodass das Problem im Pull Request behandelt werden kann. Es zertifiziert dich nicht, führt dein Audit nicht durch und ersetzt nicht dein eigenes Urteil.