Belegt: Ja
Eine aktuelle Primärquelle stützt den positiven Wert für den angegebenen Scope. Quelle, Scope und Prüfdatum bleiben am Feld gebunden.
AgentenTrust 2.0
Trust-Evidence sichtbar machen – ohne aus Lücken Bewertungen zu bauen.
Direktantwort: AgentenTrust 2.0 ist der feldgenaue Evidence-Layer von AgentenCode für Datenschutz, Security, menschliche Kontrolle und Nachvollziehbarkeit. Das System vergibt keinen Compliance-Score. Es zeigt, was eine Primärquelle tatsächlich belegt, für welchen Scope die Aussage gilt und was Unknown bleibt.
Aktuelle Evidence-Basis
36 normalisierte Controls, 802 dokumentierte Trust-Signale.
Die Abdeckung wird über 130 Agentenprofile geführt. 115 Profile enthalten derzeit mindestens ein Trust-Signal. Ein fehlendes Signal bleibt Unknown; es wird niemals stillschweigend in „Nein“ umgewandelt.
36Trust-Controls
802dokumentierte Signale
130Agentenprofile
115Profile mit ≥1 Signal
Abdeckung, kein Score.
Wenn ein Profil bei „Menschliche Kontrolle“ 0 von 10 dokumentiert zeigt, bedeutet das: Für diese zehn Controls liegt im aktuellen Datensatz kein feldgenauer öffentlicher Beleg vor. Es bedeutet nicht, dass das Produkt keine Mechanismen für menschliche Kontrolle besitzt.
Vier Evidence-Säulen
Was AgentenTrust tatsächlich misst.
Datenschutz & Daten
Data Residency, Kundendaten-Training, Retention, DPA, Subprocessors und Processing Scope. Diese Felder strukturieren die DSGVO-Prüfung, ohne aus einem Einzelmerkmal eine Compliance-Aussage abzuleiten.
Security & Zugriff
Verschlüsselung, SSO, SCIM, RBAC, Custom Roles, Customer-Managed Keys, SOC-2-Evidence und Credential Handling. Enterprise-only bleibt Enterprise-only.
Menschliche Kontrolle
Human Approval, Oversight, Tool- und Action-Permissions, Policy Controls, Delegationsgrenzen, Kill Switch und Rollback. Dokumentiert wird die Produktmechanik, nicht die Eignung eines konkreten Einsatzes.
Audit & Nachvollziehbarkeit
Audit Logs, APIs, SIEM-Export, Observability, Tracing, Action-Level Records und Activity History. Entscheidend ist neben dem Vorhandensein auch der konkrete Scope.
Evidence-Zustände
Drei Zustände verhindern einen typischen Vergleichsfehler.
Belegt: Nein
Ein negativer Wert wird nur gespeichert, wenn eine belastbare Primärquelle Nichtverfügbarkeit, eine Einschränkung oder einen anderen negativen Zustand ausdrücklich dokumentiert.
Unknown
Für das Feld liegt keine ausreichend spezifische öffentliche Evidence vor. Unknown ist eine Beleglücke und keine Produktbewertung. Daraus sollte eine Due-Diligence-Frage entstehen, kein Minuspunkt.
Dokumentierter Wert
Manche Controls tragen einen konkreten Wert statt Ja/Nein, etwa eine Region oder Aufbewahrungsdauer. Der Wert bleibt an die Quelle und den dokumentierten Scope gebunden.
Scope vor Sicherheit
Tarif, Region, Deployment und Produktsurface können die Antwort verändern.
Eine Trust-Aussage ist nur so belastbar wie ihr Scope. Ein Enterprise-Control aus einer gehosteten Cloud-Session darf nicht automatisch auf einen lokalen Client, einen anderen Tarif oder ein anderes Produkt desselben Anbieters übertragen werden. Deshalb führt AgentenTrust Scope-Informationen direkt am Wert.
Beispiel: Enterprise-Evidence
Ist SAML SSO nur für einen Enterprise-Tarif dokumentiert, kann das Profil diesen Control für genau diesen Enterprise-Scope belegen. AgentenCode behauptet daraus nicht automatisch dieselbe Funktion für Free-, Personal- oder Developer-Oberflächen.
Beispiel: Data Residency
Eine regionale Hosting-Aussage beweist allein weder DSGVO-Konformität noch zulässige Datentransfers oder den Standort jedes Subprocessors. Sie ist ein Evidence-Feld innerhalb einer größeren Prüfung.
So entsteht Trust-Evidence
Primärquelle → Feld → Scope → Prüfdatum → Historie.
- Primärquelle finden. Bevorzugt werden offizielle Produkt-, Technik-, Security-, Datenschutz- und Supportdokumentationen.
- Aussage an ein Feld binden. Evidence wird einem normalisierten Control zugeordnet statt in einen pauschalen Produkt-Score einzufließen.
- Scope erhalten. Tarif, Region, Hosting-Modus und Produktsurface bleiben Teil der Aussage.
- Prüfdatum speichern. Leser sehen, wann die Quelle zuletzt fachlich geprüft wurde.
- Änderungen historisieren. Bestätigte Feldänderungen können append-only in die Trust-History eingehen, statt frühere Zustände zu überschreiben.
EU-Kontext
EU AI Act und DSGVO sind Mapping-Kontexte, keine Badges.
EU AI Act
Controls können Themen wie Logging, Human Oversight, Transparenz, Robustheit und Cybersecurity zugeordnet werden. Das Mapping hilft, relevante Evidence zu finden. Es entscheidet nicht, ob eine konkrete gesetzliche Pflicht auf einen bestimmten Einsatz anwendbar ist.
DSGVO
Privacy-Controls strukturieren Fragen zu Processing Scope, Residency, Retention, DPA, Subprocessors und technischer Sicherheit. Kein einzelnes Feld stellt DSGVO-Konformität oder die Zulässigkeit eines konkreten Transfers fest.
Entscheidungsworkflow
Trust-Evidence soll bessere Procurement- und Security-Fragen erzeugen.
1. Anforderungen festlegen
Mit den Controls beginnen, die für den Prozess wirklich relevant sind: etwa SSO, Audit Logs, Human Approval, Data Residency oder DPA.
2. Evidence prüfen
AgentenCheck oder das einzelne Profil zeigt, welche Anforderungen belegt, explizit negativ oder Unknown sind.
3. Scope verifizieren
Prüfen, ob Tarif, Region und Deployment-Modell der dokumentierten Evidence mit der geplanten Beschaffung übereinstimmen.
4. Unknowns schließen
Unknown-Felder werden zu Anbieterfragen, Vertragschecks oder Pilot-Tests – nicht zu automatischen Negativpunkten.
Maschinenlesbarer Layer
Dasselbe Trust-Modell ist als strukturierter Datensatz verfügbar.
AgentenCode veröffentlicht die normalisierten Control-Definitionen und den aktuellen öffentlichen Governance-Datensatz. Entwickler und KI-Systeme können damit dieselben Felder auflösen, die im Interface sichtbar sind.
Control-Schema
Definiert Control-Pfade, Labels, Werttypen, Suchbegriffe und Legal-Context-Mappings.
Aktuelle Signale
Enthält die aktuellen dokumentierten Signale je Agent mit Wert, Scope, Prüfdatum und Primärquellenreferenz.
36-Control-Katalog
Alle Trust-Controls im Überblick.
Der Katalog zeigt die normalisierten Felder, die AgentenCode über Anbieter und Agenten hinweg vergleichbar macht. Ein Eintrag im Katalog bedeutet nicht, dass für jeden Agenten ein Wert dokumentiert ist.
Datenschutz & Daten
Data Residency
privacy.residency.availableOb der Anbieter für den relevanten Produkt-/Tarif-Scope Datenresidenz öffentlich dokumentiert.
Rechtskontext: DSGVO Art. 5Region auswählbar
privacy.residency.customer_region_selectableOb Kunden eine dokumentierte Region für den relevanten Scope auswählen können.
Rechtskontext: DSGVO Art. 5Dokumentierte Region
privacy.residency.regionWelche Region oder Regionen die Primärquelle konkret nennt.
Rechtskontext: DSGVO Art. 5Kundendaten für Training
privacy.training.customer_dataOb die Primärquelle die Nutzung von Kundendaten für Modelltraining bejaht oder verneint.
Rechtskontext: DSGVO Art. 5Datenaufbewahrung / Retention
privacy.retention.policyDokumentierte Aufbewahrungs- oder Löschlogik für relevante Kunden- bzw. Produktdaten im angegebenen Scope.
Rechtskontext: DSGVO Art. 5DPA / Auftragsverarbeitung
privacy.dpa.availableOb ein Data Processing Agreement bzw. eine Vereinbarung zur Auftragsverarbeitung für den relevanten Scope öffentlich dokumentiert ist.
Rechtskontext: DSGVO Art. 28Subprocessor-Liste
privacy.subprocessors.list_availableOb der Anbieter eine aktuelle Liste eingesetzter Unterauftragsverarbeiter für den relevanten Scope öffentlich dokumentiert.
Rechtskontext: DSGVO Art. 28Datenverarbeitung / Deployment Scope
privacy.processing.scopeDokumentierter Produkt-, Tarif-, Region- oder Deployment-Scope, für den eine Datenschutz- oder Verarbeitungsaussage tatsächlich gilt.
Rechtskontext: DSGVO Art. 5, DSGVO Art. 28Security & Zugriff
Verschlüsselung at rest
security.encryption.at_restDokumentierte Verschlüsselung gespeicherter Daten im relevanten Scope.
Rechtskontext: EU AI Act Art. 15, DSGVO Art. 32Verschlüsselung in transit
security.encryption.in_transitDokumentierte Verschlüsselung bei der Übertragung.
Rechtskontext: EU AI Act Art. 15, DSGVO Art. 32Customer-Managed Keys
security.customer_managed_keyOb kundenseitig verwaltete Schlüssel bzw. BYOK dokumentiert sind.
Rechtskontext: EU AI Act Art. 15, DSGVO Art. 32SOC 2 Type 2
security.soc2_type2Ob der Anbieter SOC 2 Type 2 für den relevanten Produkt-Scope dokumentiert.
Rechtskontext: EU AI Act Art. 15, DSGVO Art. 32SAML SSO
governance.sso.samlDokumentierte SAML-SSO-Unterstützung.
Rechtskontext: EU AI Act Art. 15, DSGVO Art. 32OIDC SSO
governance.sso.oidcDokumentierte OIDC-SSO-Unterstützung.
Rechtskontext: EU AI Act Art. 15, DSGVO Art. 32SCIM
governance.scimDokumentierte SCIM-Provisionierung.
Rechtskontext: EU AI Act Art. 15, DSGVO Art. 32RBAC
governance.rbacDokumentierte rollenbasierte Zugriffskontrolle.
Rechtskontext: EU AI Act Art. 15, DSGVO Art. 32Custom Roles
governance.custom_rolesDokumentierte benutzerdefinierte Rollen oder granulare Rollenmodelle.
Rechtskontext: EU AI Act Art. 15, DSGVO Art. 32Secrets / Credential Handling
security.secrets.credential_handlingDokumentierte Handhabung von Secrets, Tokens oder Zugangsdaten im relevanten Agenten-/Plattform-Scope.
Rechtskontext: EU AI Act Art. 15, DSGVO Art. 32Menschliche Kontrolle
Human Approval
governance.human_approvalDokumentierte menschliche Freigabe in agentischen Abläufen.
Rechtskontext: EU AI Act Art. 14Pre-Action Approval
governance.approval.pre_actionDokumentierte Freigabe vor einer risikorelevanten Aktion.
Rechtskontext: EU AI Act Art. 14Human Oversight
governance.human_oversightDokumentierte Mechanismen für menschliche Aufsicht.
Rechtskontext: EU AI Act Art. 14Permission Controls
governance.permission_controlsDokumentierte Berechtigungskontrollen für Agenten oder Workflows.
Rechtskontext: EU AI Act Art. 14Policy Controls
governance.policy_controlsDokumentierte Richtlinien-/Policy-Kontrollen für Agenten oder Aktionen.
Rechtskontext: EU AI Act Art. 14Tool Permissions
governance.tool_permissionsDokumentierte Steuerung, welche Tools ein Agent nutzen darf.
Rechtskontext: EU AI Act Art. 14Action Permissions
governance.action_permissionsDokumentierte Steuerung zulässiger Aktionen.
Rechtskontext: EU AI Act Art. 14Delegation Controls
governance.delegation_controlsDokumentierte Grenzen für Delegation an andere Agenten/Komponenten.
Rechtskontext: EU AI Act Art. 14Kill Switch
governance.kill_switchDokumentierte Möglichkeit, agentische Ausführung zu stoppen/deaktivieren.
Rechtskontext: EU AI Act Art. 14Rollback
governance.rollbackDokumentierte Rücknahme oder Wiederherstellung nach Aktionen.
Rechtskontext: EU AI Act Art. 14Audit & Nachvollziehbarkeit
Audit Logs
governance.audit_logs.availableOb Audit-/Compliance-Logs öffentlich dokumentiert sind.
Rechtskontext: EU AI Act Art. 12Audit-Log-Aufbewahrung
governance.audit_logs.retention_daysDokumentierte Aufbewahrungsdauer von Audit-/Compliance-Logs.
Rechtskontext: EU AI Act Art. 12Audit Log API
governance.audit_logs.apiOb Audit-/Compliance-Logs programmgesteuert abrufbar sind.
Rechtskontext: EU AI Act Art. 12SIEM Export
governance.audit_logs.siem_exportOb Export/Integration in SIEM-Systeme dokumentiert ist.
Rechtskontext: EU AI Act Art. 12Observability
observability.availableOb Observability-/Monitoring-Funktionen dokumentiert sind.
Rechtskontext: EU AI Act Art. 12Tracing
observability.tracingOb Ablauf-/Trace-Daten für agentische Ausführung dokumentiert sind.
Rechtskontext: EU AI Act Art. 12Action-Level Audit
governance.audit_logs.action_levelOb einzelne Agentenaktionen auf Audit-Ebene nachvollziehbar sind.
Rechtskontext: EU AI Act Art. 12Activity History
governance.activity_history.availableOb eine nachvollziehbare Aktivitäts- oder Ausführungshistorie für relevante Agentenaktionen öffentlich dokumentiert ist.
Rechtskontext: EU AI Act Art. 12Coverage richtig lesen
Drei Profile können dieselbe Gesamtzahl haben und trotzdem völlig andere Evidence-Schwerpunkte.
Die Zahl dokumentierter Controls ist deshalb kein Ranking. Entscheidend ist, welche Felder für den geplanten Einsatz belegt sind. Claude Code hat beispielsweise aktuell 9 von 36 Controls dokumentiert; die gespeicherte Abdeckung liegt vor allem bei Security & Zugriff sowie Audit & Nachvollziehbarkeit. Microsoft Copilot Studio kommt ebenfalls auf 9 von 36, verteilt die dokumentierte Evidence aber anders auf Privacy, Security, Human Control und Trace. Salesforce Agentforce liegt ebenfalls bei 9 von 36, wiederum mit einer anderen Verteilung. Die gleiche Gesamtzahl beschreibt also drei unterschiedliche Evidence-Profile.
Claude Code
9 von 36 Controls dokumentiert: 0 Privacy, 6 Security, 0 Human Control, 3 Trace. Daraus folgt keine Aussage, dass Privacy oder Human Control fehlen. Es zeigt nur, wo AgentenCode aktuell feldgenaue öffentliche Evidence gespeichert hat.
Trust-Evidence ansehen →Microsoft Copilot Studio
9 von 36 Controls dokumentiert: 2 Privacy, 4 Security, 1 Human Control, 2 Trace. Für Procurement ist diese Verteilung oft informativer als eine einzige Gesamtzahl.
Trust-Evidence ansehen →Salesforce Agentforce
9 von 36 Controls dokumentiert: 2 Privacy, 4 Security, 2 Human Control, 1 Trace. Auch hier bleibt jeder Wert an Scope, Prüfdatum und Primärquelle gebunden.
Trust-Evidence ansehen →Grenzen des Modells
Was AgentenTrust bewusst nicht leisten soll.
AgentenTrust ist kein Security-Audit, kein Penetrationstest, keine Rechtsberatung und keine Zertifizierung. Öffentliche Dokumentation kann unvollständig sein, Anbieter können Funktionen kurzfristig ändern und Enterprise-Verträge können zusätzliche Eigenschaften enthalten, die öffentlich nicht beschrieben werden. Deshalb ist ein dokumentiertes Feld ein belastbarer Startpunkt für eine Prüfung – nicht das Ende der Prüfung.
Auch „Belegt: Ja“ bedeutet nicht automatisch, dass ein Control für jeden Einsatz ausreichend umgesetzt ist. Ein Audit Log kann beispielsweise vorhanden sein, aber seine Aufbewahrungsdauer, Granularität oder Exportmöglichkeit können für einen konkreten Prozess unzureichend sein. Ein Human-Approval-Mechanismus kann dokumentiert sein, aber nur für bestimmte Tool-Aufrufe oder Oberflächen gelten. Der konkrete Scope bleibt deshalb Teil jeder Entscheidung.
Die stärkste Nutzung von AgentenTrust ist eine Kombination aus öffentlicher Evidence und eigener Due Diligence: Anforderungen definieren, dokumentierte Werte prüfen, Unknowns als Fragen formulieren, Verträge und Tarifdetails verifizieren und anschließend mit realistischen Testfällen überprüfen, wie sich der Agent im eigenen Berechtigungs- und Datenkontext verhält.
Häufige Fragen
Ist AgentenTrust ein Compliance-Score?
Nein. AgentenTrust zeigt feldgenaue öffentliche Evidence. Die rechtliche Einordnung hängt vom konkreten Einsatz, der Organisation, Verträgen und dem Deployment-Kontext ab.
Was bedeutet 0 von 10 dokumentiert?
Es bedeutet, dass für diese zehn Controls im aktuellen Datensatz keine feldgenaue öffentliche Evidence gespeichert ist. Es bedeutet nicht, dass das Produkt alle zehn Funktionen nicht besitzt.
Warum verwendet AgentenCode Unknown?
Weil fehlende öffentliche Dokumentation kein Beleg für Nichtverfügbarkeit ist. Unknown hält die Beleglücke sichtbar.
Kann AgentenTrust für Vendor Due Diligence genutzt werden?
Ja, als strukturierter Ausgangspunkt. Primärquellen, exakter Tarif, Region, Verträge und Deployment-Konfiguration müssen weiterhin konkret geprüft werden.