Token Security führt vier Annahmen an, die den Zugriffskriterien von SOC 2 zugrunde liegen und bei menschlichen Akteuren so selbstverständlich waren, dass sie nie ausgeschrieben wurden.
Erstens: Jemand genehmigt ein Konto, bevor es entsteht. SOC 2 verlangt die Registrierung und Freigabe eines Nutzers, bevor Anmeldemöglichkeiten erteilt werden. Agenten entstehen dagegen als Nebenwirkung einer anderen Handlung – ein Entwickler klickt auf einem OAuth-Dialog auf „Erlauben", ein API-Schlüssel wandert in eine Konfigurationsdatei, ein MCP-Server wird einer JSON-Datei hinzugefügt. Niemand wurde um Zustimmung gebeten.
Zweitens: Jedes Konto hat einen bekannten Eigentümer. Bei Agenten fehlt ein benannter Verantwortlicher häufig; er lässt sich nur nachträglich aus Indizien rekonstruieren, etwa aus Schlüsseln und Repositories, die mit Menschen verknüpft sind. In der Breite ist die Eigentümerschaft eine begründete Vermutung statt eines belastbaren Eintrags – und im Prüfprotokoll sieht ein geratener Eigentümer aus wie ein dokumentierter.
Drittens: Der Name im Protokoll benennt den Handelnden. Agenten arbeiten oft mit geborgten Zugangsdaten: einer angemeldeten Sitzung, einem Entwicklertoken, einem Dienstkonto. Eine Studie, die gemeinsam mit der Cloud Security Alliance entstand, ergab laut Token Security, dass mehr als zwei Drittel der Organisationen Aktionen von KI-Agenten nicht klar von menschlichen unterscheiden können.
Viertens: Was ein Konto darf, verrät, wofür es da ist. Das Prinzip der geringsten Rechte unterstellt eine dauerhafte Aufgabe. Bei Agenten begrenzen Rechte lediglich den Wirkungsradius; was der Agent tatsächlich tun soll, hängt von Anweisungen, aufgenommenem Kontext und eigenen Entscheidungen ab.
Aus diesen Verschiebungen leitet Token Security drei ausgehöhlte Kontrollen ab. Beim Offboarding greifen bei Menschen HR-System, Identitätsanbieter und SaaS-Dienste ineinander, der Nachweis entsteht quasi von selbst. Für Agenten existiert keine Personalabteilung und keine Instanz, die autorisiert festlegt, dass ein bestimmter Agent stoppen soll. Verlässt ein Mitarbeiter das Unternehmen, können in seinem Namen eingerichtete Agenten über OAuth-Berechtigungen oder API-Schlüssel weiterlaufen.
Beim Lieferantenmanagement ist ein MCP-Server in jeder relevanten Hinsicht ein Dienstleister: Er erhält Daten, handelt im Namen des Unternehmens und führt Code aus, den niemand im Haus liest. Statt über Bestellung und Datenvereinbarung kommt er über eine Konfigurationsdatei – oft steht am anderen Ende gar kein Unternehmen. Etwa drei von zehn Namen in der eigenen Registry lassen sich laut Token Security keiner existierenden Firma zuordnen; von einem namenlosen Anbieter lässt sich kein SOC-2-Bericht einholen. Werden Agenten auf Mitarbeiterrechnern gefunden, ist nur ein Teil gefahrlos blockierbar, weil Programmnamen mit selbst gebauter Software kollidieren können.
Beim Änderungsmanagement schließlich verlangt die Funktionstrennung üblicherweise, dass Autor und Freigeber verschiedene Personen sind. Prüft ein Agent die Änderung eines anderen Agenten, ist die Trennung nur nominell, auch wenn zwei Identitäten beteiligt waren. Die eigentliche Autorisierung wandert zudem aus dem Prüfumfang heraus: Die Entscheidung fällt in einem Prompt, in einem Werkzeug, das in der Systembeschreibung nicht auftaucht – als Nachweis bleibt ein Pull Request.
In den Kriterien selbst steht nirgends „Mensch": CC6.2 spricht von „internen und externen Nutzern", CC6.1 von „geschützten Informationswerten". Maschinenkonten als Nutzer zu behandeln, Agenten in Systembeschreibungen aufzuführen und zu testen, ist also möglich. Weil Agenten jedoch nicht ausdrücklich genannt werden, verhandeln Unternehmen und Prüfer den Umfang untereinander – und beide Seiten haben ein Interesse an einem leicht belegbaren Rahmen.
So lässt sich nach dieser Darstellung ein uneingeschränkter Typ-2-Bericht halten und am Ausstellungstag dennoch vier Fragen zur eigenen Produktionsumgebung nicht beantworten: Was läuft dort (CC6.2)? Wer hat es autorisiert (CC8.1)? Wessen Zugangsdaten trägt es (CC6.1)? Wer könnte es abschalten (CC6.3)? Token Security nennt den eigenen Ansatz „absichtsbasierte Sicherheit": festlegen, wozu ein Agent da ist, und den Zugriff daran ausrichten. Der Beitrag ist von Token Security gesponsert und verfasst.