Protect AI Workloads with Purview, Agent ID and Foundry

AI security is an implementation domain in SC-500

Microsoft SC-500 explicitly includes protecting AI workloads, not merely knowing how a chatbot produces text. The current Secure compute domain covers SharePoint data overexposure, Microsoft Purview Data Security Posture Management, Microsoft Copilot Studio agent protection, Entra Agent ID access, Defender XDR, API Management AI Gateway, Foundry guardrails and Defender for AI. These features operate at different trust boundaries and should not be represented as one universal product switch.

Consider a fictional employee-support agent grounded in SharePoint, invoking an internal API and running behind Microsoft Foundry. The solution can disclose confidential documents even when the model’s response is fluent, while a compromised agent identity could invoke tools outside an intended business process. Start with the data classification, human and nonhuman identities, model and tool access, and the concrete side effects of an agent action.

Discover data overexposure with Microsoft Purview

Microsoft Purview Data Security Posture Management helps organizations discover and investigate sensitive data risks across supported applications and AI workloads. Review the supported sources and licensed capabilities for a specific tenant rather than treating every AI service as fully covered. A finding of overshared data must be tied to an actual source permission or sharing configuration that an authorized owner can change.

SharePoint access is an immediate example. An agent grounded on a broadly shared site may faithfully retrieve content that should have been restricted before the AI system existed. Correct the site, library, document and sharing permissions first; prompt filtering cannot repair a mistaken source ACL. Validate the user and agent contexts separately because apparently identical conversations can carry different data rights.

For a SharePoint-grounded agent, map source libraries to sensitivity, access groups and data owners before testing model responses. An employee who belongs to an overly broad group may retrieve confidential content through an agent without any malicious prompt. Review the underlying permission and sharing configuration rather than assuming the assistant is responsible for that exposure. Confirm a legitimate authorized search can still return the expected policy while a separate lower-privilege test identity cannot retrieve payroll or legal records. Purview DSPM observations can help prioritize suspicious overexposure, but an exposure finding is not proof that a specific user accessed a file. Record the source identity, owner and actual permission state before closing remediation.

Give each agent a governed identity

Microsoft Entra Agent ID introduces agent-specific identity constructs and blueprints. Its architecture separates the agent’s identity from a human account and supports agent access controls that depend on authorization context. An agent should not run indefinitely under an employee’s shared password, nor should every tool inherit a tenant-wide administrative grant merely because the agent is part of a trusted platform.

Implement Conditional Access for supported agent identity flows with realistic report-only and denial testing where available. Check who sponsors the identity, which blueprints can acquire access tokens, what the token’s audience allows and how rights are withdrawn at retirement. Distinguish an autonomous agent using app permissions from an interactive agent acting on behalf of a user; both need governed authority and audited behavior.

Create a lifecycle record for every deployed agent: owner, business process, identity, token audience, permitted APIs, tools, access duration and method of revocation. A support agent might read a knowledge base and draft a ticket but should lack permission to update an employee’s pay or remove security logs. Enforce this in the target service rather than relying on a natural-language instruction to “never do that.” Validate an authorized call and a deliberately prohibited call with the same agent principal, checking the actual API response. Review whether a specific Entra Agent ID Conditional Access capability and licensing apply to that deployment; a Conditional Access policy for interactive people is not automatically enforced for every autonomous agent identity.

Understand agent blast radius in Defender XDR

An agent that can read mail, post to collaboration channels and modify service tickets has a broader potential blast radius than an assistant limited to search. The SC-500 blueprint names analyzing Entra Agent ID security risks using Defender XDR. Such analysis should connect the agent principal, target services, effective permissions and detected anomalous behavior rather than treating all nonhuman identities as equally dangerous.

If an agent’s tool token is suspected compromised, the response plan should identify how to disable the agent, revoke or restrict permissions, stop dependent workflows, preserve relevant logs and verify that the unauthorized path is closed. Review what the agent actually could change, not only how many times it signed in. The autonomous-agent trust-boundary guide provides adjacent architect-level reasoning without replacing hands-on security control validation.

A compromised agent can cause more damage than a mistaken chatbot response if it can open cases, modify records or invoke other agents. Trace all effective permissions, including inherited grants and identities used by connected tools. Imagine a malicious instruction embedded in a retrieved document asking the agent to export a confidential record: the test should fail because the downstream API denies that operation, not merely because the model chose friendly wording. Preserve correlation between the agent identity, tool call and target response for investigation. If containment is needed, stop the runtime, revoke relevant credentials and grants, and verify subsequent calls fail. Defender observations must be interpreted alongside authoritative identity and application logs.

Use API Management AI Gateway to govern calls

The Azure API Management AI gateway supports model or agent API protection, token limits, quotas, observability and relevant authorization controls. An enterprise team can use it to mediate requests between calling applications and AI backends, but exact features and tier requirements vary. Some Foundry portal integration paths carry preview labels and should not be promised universally as mature capabilities.

Plan request authentication, backend authorization, rate limits, safe logging, failure behavior and access to tool APIs. A token quota can prevent one application from exhausting capacity; it cannot on its own determine whether an agent is entitled to disclose a customer’s invoice. Test both maliciously large requests and legitimate business transactions, then verify the gateway actually enforced the intended rules.

Suppose two business applications share one Foundry deployment, but only one is authorized to process confidential case information. An AI gateway should distinguish callers, apply supported authentication and quota policies, and avoid treating a shared model endpoint as universal data authorization. Test authorized and unauthorized callers separately, record the policy that denies the latter and confirm telemetry attributes activity to the right application. A token quota protects cost and capacity; it does not automatically prevent disclosure of secret model context or unauthorized tool invocation. Limit sensitive prompt and completion logging by data classification, and define how overload or backend failures affect users. Check tier, region and preview status before claiming every advanced gateway feature is available.

Apply Foundry guardrails and Defender for AI protection

Foundry guardrails and Microsoft Defender for AI each contribute to AI workload security, but their roles differ. A guardrail can constrain or assess content and tool interactions under supported configurations. Defender for AI services can add cloud workload threat signals where the plan supports the deployed resource. The Microsoft onboarding documentation describes subscription-level prerequisites and supported protection scope.

Do not treat a good safety score as proof that a backend secret is protected or a tool has least privilege. Validate network restrictions, API identity, model response policy, logging and downstream authorization independently. If a provider or region does not support a desired detection, document a compensating control and an accountable owner rather than describing the protection as already active.

Construct a three-layer test: a harmless allowed user question, an instruction containing prohibited sensitive data access, and a request that attempts an unauthorized action through a connected tool. A content guardrail can identify inappropriate text but cannot replace the tool’s access-control check. Likewise, a Defender for AI alert indicates a supported detection, not proof every attack pattern was prevented. Record the exact deployed resource, protection plan, applicable safety policy and what event should appear after the test. If a plan or region lacks a detector, document compensating constraints rather than marking it covered. The acceptance decision should distinguish response quality, source-data access, workload threat monitoring and irreversible side effects.

Manage the agent inventory and owners

SC-500 also references managing agents in the Microsoft 365 admin center. A large organization may have agents from Copilot Studio, Microsoft 365, Azure and third-party builders. Security teams need to know which identities exist, who sponsors each one, its enabled tools and data sources, security policy state, retention expectations, and the evidence required to review or retire it.

A useful review discovers an agent with broad SharePoint access but no current accountable owner, traces its data source and permissions, then disables the risky path without disrupting unrelated workloads. Compare owner inventory with agent identity and protection telemetry. Agent lifecycle management should close access when the business process disappears, not preserve powerful dormant tool connections for convenience.

Validate a complete AI security scenario

Define an expected behavior for a read-only HR-policy agent: an authorized employee can retrieve current policy, an unauthorized user cannot view payroll records, a deliberately malicious source paragraph cannot trigger external tool use, and a policy breach produces an attributable alert where supported. Test the action boundary, identity, sensitive data and logs separately. An answer that refuses a prohibited request is a successful security result.

SC-500 practice scenarios may reveal gaps in the role-based model, but they are not official live Microsoft questions. This guide is based on first-party documentation and fictional architecture scenarios; no actual Microsoft 365 tenant, Copilot Studio agent, Foundry gateway or Defender for AI plan was configured or tested.