Identify the actor before assigning a security policy

The first question in an agent threat model is not which model family is used. It is which identity will request access and what authority that identity represents. Some agents act through a signed-in user. Others use an agent identity for application-only access, while another pattern uses an agent user account with mailbox or collaboration rights. These patterns are related but not interchangeable. A control that correctly restricts a human user may not cover an agent service principal or an agent user account.

Microsoft Entra Agent ID introduces concepts such as agent identities, agent identity blueprints and agent user accounts. A blueprint supports creation and management workflows; it should not be confused with the agent identity executing a task. Engineers need to record the owner, business purpose, sponsoring workflow, connected tools and expected resource audiences for each deployed agent. The official Agent ID documentation provides the identity and lifecycle model, but implementation depends on tenant configuration and available licensed capabilities.

Build an inventory that distinguishes production agents from experiments and disabled prototypes. Keep the business sponsor separate from the technical service owner where necessary. A missing owner makes it difficult to approve access, investigate misuse or retire an agent when its project ends. A declared agent name is not enough; track the actual application and principal identifiers that appear in authorization and audit records.

Follow tokens, subjects and audiences through delegated access

Access tokens express authorization to a target resource rather than general approval for an agent to do anything useful. A token has a subject and an audience. In delegated access the subject represents the user while the calling application or agent is also identified. In application-only access the agent identity is the subject; with an agent-user account, that account is the subject. The resource is responsible for validating the token claims and enforcing its own permissions.

This distinction becomes concrete when the same assistant retrieves a SharePoint file, then invokes an API hosted in Azure. The token issued for one resource is not universal permission for the other. The implementation should obtain the proper audience-specific token and make its scopes or application roles explicit. Avoid designing a service that accepts one broad identity and then silently performs many privileged actions on behalf of callers. Authorization must survive the transition between conversation, retrieval and tool execution.

The relationship with ordinary Azure RBAC roles and scope is fundamental: a workload identity can be well authenticated yet still overprivileged. Review both the permissions granted at the target service and the identity that can issue or use the token. A secure agent cannot compensate for a backend API that ignores claims or performs writes under a shared unrestricted account.

Apply Conditional Access to the right agent access pattern

Conditional Access for agents extends the Entra policy engine to agent access. It evaluates applicable conditions when a token is issued or refreshed, taking account of user and agent context, network and device signals and risk information where supported. It is not a blanket network firewall for everything an AI agent might contact. Policies must target the relevant token subject and the tenant must meet the applicable prerequisites. Microsoft currently documents two licensing paths for Conditional Access for agents: Microsoft 365 E7, which includes Agent 365 and the Entra Suite, or a Microsoft Agent 365 license paired with at least Microsoft Entra ID P1 or Microsoft 365 E3. This distinction matters when a project is piloted in one tenant and deployed in another with different entitlements. Some agent-specific device and network policy options also depend on the supported agent runtime and endpoint configuration; a named feature should not be assumed available merely because ordinary human Conditional Access policies are already enabled. The organization should check feature availability and its exact entitlement rather than assuming every agent control is enabled.

Microsoft distinguishes three relevant token subjects: in delegated on-behalf-of access, the subject is the signed-in user; in application-only access, the agent identity is the subject; and for an agent using its own user account, that account is the subject. Conditional Access must be evaluated against the actual subject and resource audience: delegated flows rely on policies targeting the user or group, app-only flows can target agent identities, and agent-user-account flows require policies covering those user accounts. Review sign-in evidence for each path rather than assuming one policy covers all three. Microsoft documents agent-user-specific Conditional Access targeting as a preview capability, so verify tenant eligibility, supported assignment scope, and production rollout before relying on it for critical access decisions. Test the decision in a controlled environment, and document necessary exclusions with an expiry and owner.

Another boundary is even more basic: Conditional Access protects requests involving resources secured by Microsoft Entra ID. An agent using a static API key to reach an external service bypasses that token-issuance evaluation. The Microsoft agent Conditional Access specification calls out this limitation. Map every tool credential, including API keys and downstream service accounts, before concluding that an Entra policy governs the whole workflow.

Reduce data overexposure before the agent retrieves anything

An agent can create a new disclosure route without creating the original permission problem. If many SharePoint sites and files are already overshared, an assistant that searches across them may make sensitive content easier to discover at conversational speed. The right first response is to understand where access is already too broad, which data is sensitive, and whether inherited permissions match actual business need. A model instruction not to reveal confidential data is not a substitute for source-level access enforcement.

Microsoft Purview Data Security Posture Management addresses discovery and policy insight for AI interactions in supported applications. Protecting Copilot data with Purview also requires source permissions, sensitivity labels, and policy enforcement beyond a conversational prompt. Exact capabilities depend on the app, tenant, licensing and configuration, so teams must confirm the service description and onboarding requirements. Use findings to prioritize changes in SharePoint permissions, sensitivity labels, DLP coverage or agent deployment patterns. Treat AI-security dashboards as signals about exposure and usage, not proof that every downstream tool call enforces the same rule.

The broader issue also appears in protecting retrieval from poisoned data: even when an identity is authorized, the content retrieved can be inaccurate, malicious or intentionally manipulative. Keep source integrity and authorization as separate checks. Restricted access does not make a retrieved instruction trustworthy.

Constrain tool actions and the policy enforcement path

For agent security, define a boundary between generating an action proposal and executing a transaction. A model may decide that an update to a service ticket is useful, but an independent policy should validate the caller, target record, permitted fields and approval threshold. The agent should not manufacture its own authorization simply by including a convincing reason in natural language. High-consequence actions need observable confirmation and a controlled mechanism for stopping or reversing work.

For Microsoft Foundry and API Management integrations, the SC-500 study guide includes AI Gateway and guardrail configurations. Engineers should distinguish gateway controls that govern access, traffic or policy from application logic that validates a business operation. Confirm current product support and rollout stages in the target tenant; do not infer that every guardrail exists or is enabled across all agent types. Use test records to demonstrate what is denied, what requires review and what remains reachable under failure.

Where an AI agent accesses secrets or private services, combine the workflow policy with workload identity and network isolation. The approved private networking for Azure AI coverage illustrates why a trusted prompt does not remove the need for a controlled endpoint path. Access policy, network reachability and content filtering each solve different problems.

Correlate agent misuse with Defender and Purview evidence

AI agents introduce investigative questions that ordinary interactive logons may not answer. Which principal acquired the token? Was the resource request delegated to a user or made by an agent identity? Which tool action followed the retrieval? Was sensitive material accessed beyond the intended task? To reconstruct an incident, preserve the identifiers and relationships that connect identity events, application logs, tool execution and data access.

The official SC-500 blueprint identifies risks around Entra Agent ID and Defender XDR, Microsoft Purview DSPM, Defender for AI Service, and data-and-AI security posture. Those products provide different windows into exposure and activity. Do not collapse them into one perfect audit trail. Some actions may be visible only in the application or API logs, and data security controls can vary by supported integration. Agent-level discovery and posture for Microsoft Foundry and third-party cloud agents moved to Microsoft Agent 365 licensing in July 2026; seeing the Foundry resource in Defender CSPM is not proof that agent inventory and assessment are licensed. An investigation plan must document missing telemetry as clearly as collected evidence.

When an agent has multiple tools, correlate the resource identifier and the transaction ID rather than relying only on a conversational transcript. A transcript may explain what the assistant appeared to intend, but it cannot prove what a service committed. Security engineers need authoritative result records from the target system, especially when an agent retries after a timeout or error.

Treat lifecycle controls as part of least privilege

Provisioning is only one step in managing an agent. Organizations should know who can create blueprints, approve a new agent identity, grant consent, change its tool integrations, and disable it. Remove idle or ownerless agents before they become standing pathways into sensitive applications. Use environment and data-sensitivity attributes where supported to group agents under explicit controls, but do not rely on labels as enforcement unless policies actually reference them.

When a project is retired, revoke permissions, remove keys or secret access, disable scheduled invocations and preserve records required by retention policy. A deleted chat interface does not necessarily remove the agent identity or backend service credentials. During an emergency, responders need a quick way to block the principal or remove a target role assignment without simultaneously destroying logs needed for forensic review.

These are the same lifecycle concerns that apply to service principals and managed identities; what changes with agents is the volume and variety of delegated tasks. The Cloud and AI Security Engineer Associate scope expects the engineer to connect identity governance, data controls and running workloads into one operational responsibility.

Prove the design with negative tests and escalation cases

Test an agent that asks for data a user can legitimately access, then a different user who should receive a denial. Test a direct API call by the agent identity, then a call using an ungoverned API key to confirm the limit of Entra-specific policy. Run a scenario in which a document contains an instruction to change a system setting; the retrieved text must remain untrusted task data. For high-impact writes, require an independent authorization record and confirm that a failed approval leaves the target unchanged.

Add cases for a revoked principal, expired token, unavailable data store, rotated secret, misclassified document and incomplete tool response. Verify that retry behavior does not duplicate writes. Observe the identity and transaction IDs in logs and make sure the support team can correlate them across service boundaries. Record which safeguards fail closed and which need compensating operational controls.

SC-500 requires practical understanding of how identity, cloud protection and AI controls interact. A sound answer to an AI-agent security scenario is not simply to enable every named Microsoft feature. It is to choose the correct controls for each access pattern, prove that they cover the actual path, and document the gaps that remain when the agent communicates with services outside those boundaries.