Control statuses
Every control emits one of four values:
Alongside the score, every resource reports a data completeness metric — the ratio of assessed (non-UNKNOWN) controls to total controls. A resource with many UNKNOWN results should be investigated at the integration level before trusting the score.
Risk levels
The 0–100 score is bucketed by exact thresholds:Control category weights
Controls belong to a category; each category carries a base weight that feeds the score. Cloud resources (agents, models, datasets) and endpoint resources (IDEs, extensions, CLIs, MCP servers on devices) use different weight tables because their risk topologies differ.
Endpoint scoring shifts weight toward supply-chain (known CVEs in installed AI tools) and away from prompt-injection / content-safety, which apply less to a managed IDE than to a production agent.
Controls by resource type
Every control carries anid, human-readable name, a category, a weight, a list of mapped compliance frameworks, a description of why the risk exists, and remediation steps. Below is the full catalog.
Agents
Applies to Azure AI Foundry agents, Mistral agents, GCP Vertex AI Reasoning Engines, and M365 Copilot / Copilot Studio agents.Models
Applies to foundation models in Azure Cognitive Services, Azure ML Workspaces, GCP Vertex AI Model Registry, and Mistral.Datasets
Applies to vector stores, document libraries, and training datasets.MCP servers
Applies to MCP server declarations discovered in source repos (github) and on managed devices (Endpoint Discovery).
MCP servers discovered on endpoints also inherit the endpoint-tool controls below.
Endpoint tools (IDEs, extensions, CLIs, browsers)
Applies to AI-assisted IDEs, browser extensions, agent CLIs, browsers, and AI runtimes installed on managed devices (reported by the Endpoint Discovery script).Shadow AI (SaaS)
Applies to AI SaaS usage observed by the Runtime browser extension.Compliance framework mapping
Every control carries its mapped framework references so a failing control can be traced back to the obligation it supports. The frameworks that appear across the catalog:- AI frameworks — NIST AI RMF, EU AI Act, ISO/IEC 42001, OWASP LLM Top 10 (2025), OWASP MCP Top 10
- General security — SOC 2 (CC6.7, CC8.1), NIST SP 800-53 (CM-7, RA-5, SI-4, AU-6, SC-28), CIS Controls 2.1 / 7.1
- Privacy — GDPR (Art. 5, Art. 32), CCPA, HIPAA, PCI-DSS, SOX
- Vulnerability — CVSSv3, CWE-74, CWE-306, CWE-319, CWE-494, CWE-798
- OWASP Web — A06:2021
What a finding contains
When a control fails or warns, the resulting finding carries:
Findings are sorted FAIL → WARNING → UNKNOWN → PASS on each resource page so actionable items surface first.
UNKNOWN findings and integration health
UNKNOWN indicates missing data, not missing risk. Every UNKNOWN control ships a generic severity rationale and remediation:“This control could not be evaluated because the required configuration data was not available from the provider API. The actual risk is indeterminate until the data becomes accessible.” “Verify that the integration has the required API permissions to retrieve the configuration data this control needs. Re-sync the resource after fixing permissions — the control will be re-evaluated automatically.”Controls may override this with a provider-specific message (for example, the Mistral
version_history_stability control points users at the specific API endpoint and permissions that would unblock evaluation).
Pair with Runtime
TrustLens identifies what needs protection. Agent Runtime by TrustGate enforces how it is protected at runtime. A common pattern: a TrustLens FAIL onguardrails_configured becomes the trigger to put that agent behind a Gateway with a prompt-security policy attached. Once the Gateway is in front, the control will pass on the next sync with a reference back to the runtime policy.