Plan and manage an Azure AI solution 1.4 Implement responsible AI across generative AI and agentic systems

A Foundry admin turned on the 'Powered by Microsoft Purview' toggle for the subscription…

Study guide skill: Implement auditing through trace logging, provenance metadata, and approval workflows

Question B4-013

A Foundry admin turned on the 'Powered by Microsoft Purview' toggle for the subscription, and pay-as-you-go billing for Purview data security policies is set up. Interactions from a backend app appear in Purview Audit, but the data security policies are enforced only for apps that sign users in, not for this app, which calls /chat/completions with its own service principal. What explains this?

Select one answer.

  • A The toggle must also be turned on separately in each Foundry project
  • B The app must switch from Microsoft Entra ID to API key authentication for policies to apply
  • C Purview data security policies apply only to interactions that use Microsoft Entra ID user-context authentication; other interactions are visible in Audit and DSPM for AI but aren't enforced ✓ Correct answer
  • D Purview data security policies are enforced only for agents, not for model inference endpoints

Answer: C

Purview data security policies apply to interactions that use Microsoft Entra ID user-context authentication against Foundry's managed inference endpoint; for all other authentication scenarios, interactions are visible in Purview Audit and DSPM for AI but policies aren't enforced. The toggle works at the subscription level, so AI interaction data from all applications and agents in that subscription is covered. The stem rules out the billing caveat (without pay-as-you-go billing or an Agent 365 subscription, only Purview Audit is supported).

Deep dive

How it works

When a Foundry admin turns on Powered by Microsoft Purview (selected per Azure subscription in the compliance workspace), AI interaction data from all applications and agents in that subscription flows into Purview. That enables Purview Audit, sensitive information type classification, DSPM for AI and more.

Whether data security policies are actually enforced depends on how the caller authenticates:

  • They apply to interactions that use Microsoft Entra ID user-context authentication against Foundry's managed inference endpoint (/chat/completions).
  • For all other authentication scenarios, interactions are visible in Purview Audit and the DSPM for AI activity explorer, but aren't enforced by data security policies.

A backend app calling with its own service principal has no user context, so its traffic shows up in Audit while the policies don't act on it. To get enforcement, the app has to pass the signed-in user's context (see AzureUserSecurityContext).

Billing is the other prerequisite: policy enforcement needs pay-as-you-go meters or an Agent 365 subscription. Without either, only Purview Audit is supported. The stem says billing is set up, so that's not the cause.

The other options, and when you'd use them

  • Turn the toggle on per project: The toggle is set for a subscription, and covers all applications and agents in it.
  • Switch to API keys: Policies need Entra ID user-context tokens, and an API key isn't one.
  • Agents only: The policies apply to the model inference endpoint (/chat/completions) itself, as long as the caller uses user-context authentication.

Exam tip

Purview policies enforce only with Entra ID user-context tokens. App identity or keys = visible in Audit and DSPM, not enforced.

References

Last reviewed:

Ready to test yourself? The quiz asks this and every other AI-103 question, with instant feedback. Practice this in a quiz →

All Plan and manage questions · AI-103 study guide

Thanks for your feedback!