Documented: Yes
A current primary source explicitly supports the positive value for the stated scope. The source, scope and verification date stay attached to the field.
AgentenTrust 2.0
Trust evidence that separates documentation from assumptions.
Direct answer: AgentenTrust 2.0 is AgentenCode’s field-level evidence layer for privacy, security, human control and auditability. It does not award compliance scores. It shows what a primary source actually documents, for which scope, and what remains Unknown.
Current evidence base
36 normalized controls, 802 documented trust signals.
Coverage is measured across 130 agent profiles. 115 profiles currently contain at least one trust signal. A missing signal remains Unknown; it is never silently converted into “No”.
36trust controls
802documented signals
130agent profiles
115profiles with ≥1 signal
Coverage, not a score.
If a profile shows “0 of 10 documented” for human control, it means AgentenCode has no field-level public evidence for those ten controls in the current dataset. It does not mean the product has no human-control features.
Four evidence pillars
What AgentenTrust actually measures.
Privacy & data
Data residency, customer-data training, retention, DPA availability, subprocessors and processing scope. These fields help structure GDPR due diligence without turning one feature into a compliance claim.
Security & access
Encryption, SSO, SCIM, RBAC, custom roles, customer-managed keys, SOC 2 evidence and credential handling. Scope matters: enterprise-only controls remain enterprise-only.
Human control
Human approval, oversight, action and tool permissions, policy controls, delegation limits, kill switch and rollback. These controls describe documented product mechanisms, not the adequacy of a specific deployment.
Auditability
Audit logs, APIs, SIEM export, observability, tracing, action-level records and activity history. A documented log is only useful when its scope and retention fit the real workflow.
Evidence states
Three states prevent a common comparison error.
Documented: No
A negative value is stored only when a reliable primary source explicitly documents non-availability, a prohibition or another negative state. Absence of documentation is not enough.
Unknown
No sufficiently specific public evidence is stored for the field. Unknown is an evidence gap, not a product judgment. It should trigger a due-diligence question, not a negative score.
Documented value
Some controls use a value instead of yes/no, such as a region or retention period. The value remains bound to the exact source and scope in which it was documented.
Scope before certainty
Plan, region, deployment mode and product surface can change the answer.
A trust statement is only as useful as its scope. An enterprise control documented for a hosted cloud session cannot automatically be inherited by a local client, a different plan or another product from the same vendor. AgentenTrust therefore stores scope strings next to the value and source.
Example: enterprise evidence
If SAML SSO is documented only for an Enterprise plan, the profile may show that control as documented for the enterprise scope. AgentenCode does not silently claim the same control for every free, personal or developer surface.
Example: data residency
A regional hosting statement does not by itself prove GDPR compliance, lawful transfer mechanisms or the location of every subprocess. It is one evidence field in a wider assessment.
How evidence enters the system
Primary source → field → scope → verification date → history.
- Find the primary source. Official product, technical, security, privacy and support documentation is preferred.
- Bind the statement to one field. Evidence is attached to a normalized control instead of being copied into a broad product score.
- Keep the scope. Plan, region, hosting mode and product surface remain part of the statement.
- Store the verification date. Readers can see when the source was last checked.
- Track later changes. Confirmed field-level changes can be appended to the trust history instead of rewriting the past.
EU context
EU AI Act and GDPR are mapping contexts, not badges.
EU AI Act
Controls can be mapped to topics such as logging, human oversight, transparency, robustness and cybersecurity. The mapping helps teams identify relevant evidence. It does not determine whether a legal obligation applies to a specific organization or use case.
GDPR
Privacy controls structure questions around processing scope, residency, retention, DPAs, subprocessors and technical security. No single field establishes GDPR compliance or the legality of a particular transfer.
Decision workflow
Use trust evidence to ask better procurement and security questions.
1. Define requirements
Start with the controls that matter for the workflow: for example SSO, audit logs, human approval, data residency or a DPA.
2. Check evidence
Use Agent Check or an individual profile to see which requirements are documented, explicitly negative or Unknown.
3. Verify the scope
Confirm that the documented plan, region and deployment model match the system you actually intend to buy or deploy.
4. Close Unknowns
Turn Unknown fields into vendor questions, contract checks or pilot tests instead of treating them as failures.
Machine-readable layer
The same trust model is available as structured data.
AgentenCode publishes the normalized control definitions and the current public governance dataset so developers and AI systems can resolve the same fields shown in the interface.
Control schema
Defines control paths, labels, value types, search terms and legal-context mappings.
Current public signals
Contains the current documented signals per agent with value, scope, verification date and primary-source reference.
36-control catalog
All trust controls at a glance.
The catalog lists the normalized fields AgentenCode uses consistently across providers and agents. A control existing in the schema does not mean that every agent has a documented value for it.
Privacy & data
Data Residency
privacy.residency.availableWhether the provider publicly documents data residency for the relevant product or plan scope.
Legal context: GDPR Art. 5Region auswählbar
privacy.residency.customer_region_selectableWhether customers can select a documented processing or hosting region for the relevant scope.
Legal context: GDPR Art. 5Dokumentierte Region
privacy.residency.regionWhich region or regions are explicitly named by the primary source.
Legal context: GDPR Art. 5Kundendaten für Training
privacy.training.customer_dataWhether the primary source explicitly says customer data is or is not used for model training.
Legal context: GDPR Art. 5Datenaufbewahrung / Retention
privacy.retention.policyDocumented retention or deletion logic for relevant customer or product data.
Legal context: GDPR Art. 5DPA / Auftragsverarbeitung
privacy.dpa.availableWhether a Data Processing Agreement is publicly documented for the relevant scope.
Legal context: GDPR Art. 28Subprocessor-Liste
privacy.subprocessors.list_availableWhether the provider publishes a current list of subprocessors for the relevant scope.
Legal context: GDPR Art. 28Datenverarbeitung / Deployment Scope
privacy.processing.scopeThe product, plan, region or deployment scope to which a privacy or processing statement actually applies.
Legal context: GDPR Art. 5, GDPR Art. 28Security & access
Verschlüsselung at rest
security.encryption.at_restDocumented encryption of stored data within the stated product scope.
Legal context: EU AI Act Art. 15, GDPR Art. 32Verschlüsselung in transit
security.encryption.in_transitDocumented encryption for data in transit.
Legal context: EU AI Act Art. 15, GDPR Art. 32Customer-Managed Keys
security.customer_managed_keyWhether customer-managed encryption keys or BYOK are documented.
Legal context: EU AI Act Art. 15, GDPR Art. 32SOC 2 Type 2
security.soc2_type2Whether SOC 2 Type II coverage is publicly documented for the relevant product scope.
Legal context: EU AI Act Art. 15, GDPR Art. 32SAML SSO
governance.sso.samlDocumented support for SAML single sign-on.
Legal context: EU AI Act Art. 15, GDPR Art. 32OIDC SSO
governance.sso.oidcDocumented support for OIDC single sign-on.
Legal context: EU AI Act Art. 15, GDPR Art. 32SCIM
governance.scimDocumented support for SCIM provisioning.
Legal context: EU AI Act Art. 15, GDPR Art. 32RBAC
governance.rbacDocumented role-based access control.
Legal context: EU AI Act Art. 15, GDPR Art. 32Custom Roles
governance.custom_rolesDocumented custom or granular administrative roles.
Legal context: EU AI Act Art. 15, GDPR Art. 32Secrets / Credential Handling
security.secrets.credential_handlingDocumented handling of secrets, tokens or credentials in the relevant agent or platform scope.
Legal context: EU AI Act Art. 15, GDPR Art. 32Human control
Human Approval
governance.human_approvalDocumented human approval inside an agentic workflow.
Legal context: EU AI Act Art. 14Pre-Action Approval
governance.approval.pre_actionDocumented approval before a consequential or sensitive action is executed.
Legal context: EU AI Act Art. 14Human Oversight
governance.human_oversightDocumented mechanisms for human oversight of agent behavior.
Legal context: EU AI Act Art. 14Permission Controls
governance.permission_controlsDocumented permission controls for agents or workflows.
Legal context: EU AI Act Art. 14Policy Controls
governance.policy_controlsDocumented policy controls that constrain agents or actions.
Legal context: EU AI Act Art. 14Tool Permissions
governance.tool_permissionsDocumented controls over which tools an agent may use.
Legal context: EU AI Act Art. 14Action Permissions
governance.action_permissionsDocumented controls over which external actions an agent may execute.
Legal context: EU AI Act Art. 14Delegation Controls
governance.delegation_controlsDocumented limits on delegation to other agents or components.
Legal context: EU AI Act Art. 14Kill Switch
governance.kill_switchDocumented ability to stop or disable agentic execution.
Legal context: EU AI Act Art. 14Rollback
governance.rollbackDocumented rollback or recovery after agent actions.
Legal context: EU AI Act Art. 14Auditability & traceability
Audit Logs
governance.audit_logs.availableWhether audit or compliance logs are publicly documented.
Legal context: EU AI Act Art. 12Audit-Log-Aufbewahrung
governance.audit_logs.retention_daysDocumented retention period for audit or compliance logs.
Legal context: EU AI Act Art. 12Audit Log API
governance.audit_logs.apiWhether audit logs can be retrieved programmatically through an API.
Legal context: EU AI Act Art. 12SIEM Export
governance.audit_logs.siem_exportWhether export or integration with SIEM systems is documented.
Legal context: EU AI Act Art. 12Observability
observability.availableWhether observability or monitoring capabilities are documented.
Legal context: EU AI Act Art. 12Tracing
observability.tracingWhether execution traces are documented for agentic runs.
Legal context: EU AI Act Art. 12Action-Level Audit
governance.audit_logs.action_levelWhether individual agent actions can be traced at audit level.
Legal context: EU AI Act Art. 12Activity History
governance.activity_history.availableWhether an activity or execution history is documented for relevant agent actions.
Legal context: EU AI Act Art. 12Reading coverage correctly
Three profiles can have the same total coverage and still represent very different evidence patterns.
The number of documented controls is therefore not a ranking. What matters is which fields are evidenced for the intended deployment. Claude Code currently has 9 of 36 controls documented, concentrated in Security & access and Auditability. Microsoft Copilot Studio also has 9 of 36, but the evidence is distributed across privacy, security, human control and traceability. Salesforce Agentforce also has 9 of 36 with yet another distribution. The same total can therefore describe three different trust-evidence profiles.
Claude Code
9 of 36 documented: 0 privacy, 6 security, 0 human control, 3 trace. This does not mean privacy or human-control mechanisms are absent; it shows where AgentenCode currently stores field-level public evidence.
Review trust evidence →Microsoft Copilot Studio
9 of 36 documented: 2 privacy, 4 security, 1 human control, 2 trace. For procurement, this distribution is often more informative than one aggregate number.
Review trust evidence →Salesforce Agentforce
9 of 36 documented: 2 privacy, 4 security, 2 human control, 1 trace. Every value remains bound to scope, verification date and primary source.
Review trust evidence →Model limitations
What AgentenTrust deliberately does not try to be.
AgentenTrust is not a security audit, penetration test, legal opinion or certification. Public documentation can be incomplete, providers can change features quickly and enterprise contracts may include controls that are not publicly described. A documented field is therefore a reliable starting point for diligence, not the end of the diligence process.
Even “Documented: Yes” does not automatically mean a control is sufficient for every deployment. Audit logs may exist while their retention, granularity or export options remain unsuitable for a particular process. Human approval can be documented while applying only to selected tool calls or interfaces. Scope therefore remains part of every decision.
The strongest use of AgentenTrust combines public evidence with internal diligence: define requirements, inspect documented values, turn Unknowns into vendor questions, verify contracts and plan details, then test realistic workflows inside the organization’s actual permission and data environment.
Frequently asked questions
Is AgentenTrust a compliance score?
No. AgentenTrust shows field-level public evidence. Legal compliance depends on the concrete use, organization, contracts and deployment context.
What does 0 of 10 documented mean?
It means no field-level public evidence is stored for those ten controls in the current dataset. It does not mean the product lacks all ten capabilities.
Why does AgentenCode use Unknown?
Because missing public documentation is not evidence of non-availability. Unknown keeps the evidence gap visible.
Can I use AgentenTrust for vendor due diligence?
Yes, as a structured starting point. The linked primary sources, exact plan, region, contracts and deployment configuration still need to be verified.