Skip to main content
TrustLens supports all four Azure AI agent infrastructure models under a single integration:
  • Azure AI Foundry Agents (v2) — agents built with the Azure AI Foundry Agents SDK, hosted in AI Services accounts (kind=AIServices)
  • AI Hub projects — enterprise AI Foundry setups created before late 2024, backed by Microsoft.MachineLearningServices/workspaces with kind=Project
  • Azure OpenAI Classic Assistants (v1) — assistants built with the Azure OpenAI Assistants API (kind=OpenAI)
  • Legacy ML Workspaces — pre-AI-Foundry Azure ML Studio workspaces (kind=Default) that can host Promptflow-based agents
A single integration discovers all four types automatically from your subscription.
How to identify your infrastructure model: In the Azure Portal, navigate to your AI Foundry project. If the URL shows ai.azure.com and the resource is under a Microsoft.CognitiveServices account, you are on the AI Services model (v2). If your project lives under a Microsoft.MachineLearningServices Hub, you are on the AI Hub model.You can also check from the CLI: az resource list --resource-type Microsoft.MachineLearningServices/workspaces --query "[].{name:name, kind:kind}"

What TrustLens discovers

Azure AI Foundry agents (v2)

AI Hub projects (ML Workspace-backed)

RAI policies and content filters are not available for AI Hub projects. These fields will show as unavailable for hub-backed agents.

Azure OpenAI Classic assistants (v1)

Content filters and guardrails are not exposed via the Azure OpenAI Assistants (v1) API. These fields will show as unavailable for Classic assistants.

Legacy ML Workspaces

Legacy ML Workspaces may not expose the full Agents API surface. TrustLens will discover what is available and skip unsupported endpoints gracefully.

Required permissions

The required roles depend on which infrastructure model your agents use. If you are unsure, assign all applicable roles — unused roles do not cause errors.

Azure AI Foundry (v2) — AI Services model

Assign Azure AI User to the service principal at the subscription level: Why this role: Azure AI User includes both Microsoft.CognitiveServices/*/read (management plane — enumerate accounts, read RAI policies, read diagnostic settings) and Microsoft.CognitiveServices/* (data plane — access agents, models, datasets). Assigning it at subscription level means it applies to all AI Services resources in the subscription automatically.

Granular setup — two roles (least-privilege alternative)

If your security policy requires strictly minimal permissions, you can use two more targeted roles instead:
With the granular approach, you must assign Cognitive Services OpenAI User on each AI Services resource individually. Using Azure AI User at subscription level is simpler and equally secure for read-only access.

AI Hub projects — ML Workspace-backed model

If your agents were created via an AI Foundry Hub (enterprise setup before late 2024), they live under Microsoft.MachineLearningServices/workspaces resources. The roles required are different from the AI Services model:
Azure AI Developer grants access to Microsoft.MachineLearningServices/workspaces/*/read and the data plane actions needed to list agents. Assign it at the Hub or Project workspace scope, or at the subscription level if you have multiple hubs.
Azure AI Developer does not include Microsoft.CognitiveServices/*/read. If you have a mix of AI Services (v2) and AI Hub projects, you need both Azure AI User (for AI Services) and Azure AI Developer (for AI Hub). Reader at subscription level covers resource enumeration for both.

Legacy ML Workspaces — pre-AI-Foundry Azure ML Studio

For older workspaces created before AI Foundry existed (Azure ML Studio / kind=Default): If you have a mix of infrastructure models, or simply want a zero-friction setup that covers everything without tracking which roles apply to which resources, assign all roles at subscription level. Azure RBAC cascades automatically to all child resources.

Core roles (always required)

Conditional roles (add only what applies to you)

Reader and Azure AI User are always required. Neither can replace the other: Reader handles broad ARM control-plane enumeration (ML Workspaces, App Insights, etc.) while Azure AI User adds the Cognitive Services data plane. Azure AI User does not include Microsoft.MachineLearningServices or Microsoft.Insights read permissions.

One-command setup


Optional — telemetry (usage metrics)

TrustLens collects two distinct types of telemetry depending on your infrastructure model:
  • AI Foundry v2 (AI Services): Usage metrics, token counts, latency, error rates, and tool call breakdowns are collected from Application Insights via a linked Log Analytics workspace.
  • AI Hub (ML Workspace-backed): Agent-level metrics (AgentRuns, AgentTokens, AgentThreads, AgentToolCalls, AgentMessages) are collected from Azure Monitor Metrics on the Hub resource.
Both roles can be assigned at subscription level to cascade automatically to all workspaces and resources in the subscription, eliminating the need for per-resource assignments.
What you lose without these: Usage statistics and tool call metrics will be unavailable for the corresponding infrastructure type. v1 Classic usage is collected directly via the Assistants API and does not require either role. What you gain: Per-agent usage metrics, conversation-level telemetry signals (used for aggregation, not enumeration), per-tool call breakdown by type (code interpreter, file search, custom functions), token consumption, latency, and Hub-level run and thread counts.

Prerequisites

Before configuring the integration, ensure you have:
  • An Azure subscription containing AI Services, Azure OpenAI, ML Workspace, or AI Hub resources
  • Permission to create app registrations and assign RBAC roles (User Access Administrator or Owner on the subscription)
  • For v2 telemetry: an Application Insights resource connected to your AI Foundry project, linked to a Log Analytics workspace (see Enabling telemetry)

Step-by-step setup

1

Create a service principal

Save the output — you will need appId (client ID), password (client secret), and tenant (tenant ID).
2

Assign the Azure AI User role

3

(Optional) Assign telemetry roles

Skip this step if you do not need usage metrics. Two roles cover different telemetry sources:
  • Log Analytics Reader — required for v2 (AI Services) usage metrics via Application Insights
  • Monitoring Reader — required for Hub-backed agent metrics via Azure Monitor
Assigning at subscription level cascades to all workspaces and Hub resources automatically:
4

Configure the integration in TrustLens

Provide the following credentials when creating the Azure integration:

Enabling telemetry

TrustLens retrieves v2 usage metrics from Application Insights via a linked Log Analytics workspace. Azure AI Foundry automatically writes server-side OpenTelemetry traces (gen_ai.* semantic conventions) to the AppDependencies table when a Foundry project is connected to Application Insights. TrustLens queries this table to produce per-agent usage, token counts, latency, and tool call breakdowns.
Classic (v1) assistants do not require this setup. Usage for v1 assistants is collected directly from the Assistants API (Threads and Run Steps) and is always available once the core RBAC role is in place.
1

Connect Application Insights to your AI Foundry project

  1. Open Azure AI Foundry and navigate to your project
  2. Go to SettingsTracing
  3. Select or create an Application Insights resource
  4. Save — Azure will begin writing traces automatically; no SDK instrumentation is required
2

Grant Log Analytics Reader on the linked workspace

Application Insights stores trace data in a linked Log Analytics workspace. Find the workspace and grant access:
Traces may take a few minutes to appear after the first agent invocations.

Telemetry source summary


Feature availability by permission level

Azure AI Foundry (v2) — AI Services model

AI Hub — ML Workspace-backed model

Azure OpenAI Classic (v1)


Known limitations


Security considerations

  • The service principal has read-only access. TrustLens cannot modify, delete, or create any Azure resources.
  • Azure AI User at subscription level includes listkeys/action (the ability to read API keys for Cognitive Services accounts). If your policy prohibits this, use the granular setup (Reader + Cognitive Services OpenAI User), which does not include key listing.
  • Client secrets should be rotated regularly. Update the integration in TrustLens when you rotate the secret.
  • All credentials are encrypted at rest.

Troubleshooting

  • Verify the service principal has Azure AI User at the subscription level (not at a resource group or resource level only).
  • Confirm your AI agents are deployed in AI Services accounts with kind=AIServices or kind=OpenAI. If they are in a different resource type, contact support.
  • Check that the Subscription ID entered in the integration matches the subscription where your agents are deployed.
  • Verify that Application Insights is connected to your AI Foundry project (Foundry Portal → Settings → Tracing).
  • Verify the service principal has Log Analytics Reader on the Log Analytics workspace linked to Application Insights (found under App Insights → Settings → Linked workspace).
  • Traces appear within minutes of the first agent invocation. If no invocations have occurred, usage metrics will correctly show zero.
  • Hub agent metrics are collected from Azure Monitor Metrics, not Application Insights.
  • Verify the service principal has Monitoring Reader on the AI Foundry Hub resource (or at subscription level).
  • If no agent runs have occurred, metrics will correctly show zero.
  • Classic usage is collected via the Assistants API (Threads and Run Steps) — no Log Analytics configuration is needed.
  • Verify the service principal has data plane access (Azure AI User or Cognitive Services OpenAI User) on the Azure OpenAI resource.
  • If no threads or runs exist for an assistant, usage will correctly show zero.
Content filter data is only available for Azure AI Foundry (v2) agents. Classic (v1) assistants do not expose this via API — this is an Azure limitation, not a configuration issue.
  • The service principal may not have the role assigned at the correct scope. Verify the role assignment is at subscription level, not resource group or resource level only.
  • Role assignments can take a few minutes to propagate after being created.
Classic assistants require the service principal to have data plane access to the Azure OpenAI resource. With Azure AI User at subscription level this is covered automatically. With the granular setup, verify that Cognitive Services OpenAI User is assigned on the specific OpenAI resource.