This is not an official U.S. federal government website. The Federal Modernization Workbook is independent technical analysis. It does not represent the position of, and has not been reviewed or endorsed by, any federal agency.

Federal Modernization Workbook · Book 17 · What

Chapter 06 — Credentials, Least Privilege and Access Policy for AI

How AI systems and agents authenticate without stored secrets (managed identities, workload identity federation and certificates on the agent identity blueprint), how to keep Microsoft Graph and API permissions least-privileged, how admin consent and CISA’s SCuBA consent baseline apply to agents, which Conditional Access and ID Protection policies reach workload and agent identities, why AI identities hold no standing privileged roles, and how to bound the tools and data an agent can call, with the release stage and government-cloud availability of each feature.

An agent can’t be asked for a second factor, so everything it may do has to be decided before it asks: which credential it proves itself with, which permissions it holds, which policy can stop it, and which tools it can reach.

NoteIn this chapter

The order of preference for an AI identity’s credential, and why the agent identity blueprint is the credential boundary. How to choose between delegated and application permissions, what Microsoft blocks for agents and what it doesn’t, and how admin consent and CISA’s consent baseline apply. Which Conditional Access and risk policies reach agents and workload identities, and what they can and can’t do, with a check of an earlier chapter’s status note. Why the program gives AI identities no standing privileged role, and how it bounds the tools and data an agent can call. A table at the end records each feature’s release stage and government-cloud availability.

A person signing in proves something they have and something they are, and Conditional Access can stop them and ask for more. An AI agent can do neither. Microsoft says it directly: agent identities don’t authenticate with passwords, SMS, passkeys or authenticator apps, so multifactor authentication doesn’t apply to them, and they are governed with Conditional Access instead.¹ Workload identities have the same property; Microsoft lists their inability to perform multifactor authentication, their frequent lack of a formal lifecycle and their need to store credentials somewhere as the reasons they are harder to manage and at higher risk.²

So the controls that matter for an AI identity are all decided in advance. Book 04, Chapter 05 sets them for applications in general: the credential order, consent, ownership, app management policies and Conditional Access for workload identities. This chapter applies them to AI systems and agents and adds what is specific to Microsoft Entra Agent ID. Chapter 04 describes the identity types; Chapter 05 covers who answers for them.

Figure 1: The credential order for an AI identity: a managed identity federated to the blueprint where the agent runs on Azure, workload identity federation from the agent’s own platform elsewhere, a certificate in a key vault only where neither applies, and a client secret only outside production.

No stored secrets

An agent identity doesn’t hold a credential of its own. The credential lives on the agent identity blueprint, which uses it to obtain tokens for every agent identity created from that blueprint; the agent identity holds the permissions and appears as the client in the token and the logs.³ Supported blueprint credentials are federated identity credentials, certificates and cryptographic keys, and client secrets.⁴ Two consequences follow, both in Microsoft’s words: blueprint credentials are shared by every agent identity created from the blueprint, so each blueprint is a credential boundary and should group only identities that can safely share credentials and inherited permissions;⁵ and a compromise of the blueprint’s credentials affects every agent identity under it.⁶

Microsoft’s order of preference for the blueprint credential matches the order Book 04, Chapter 05 sets for applications:

1. A managed identity as a federated identity credential. Microsoft recommends it for production blueprints because it obtains Entra tokens without any credential to manage; it requires the code to run on an Azure service.⁷ It is a credential on the blueprint, not a replacement for the agent identity.⁸
2. Workload identity federation for agents running outside Azure. Microsoft documents two integration patterns for agents built on other platforms such as Amazon Bedrock and n8n: the Microsoft Entra ID Auth SDK running as a sidecar, and federation.⁹ The sidecar is a container beside the agent that acquires and caches its tokens, through client credentials or federated credentials for autonomous calls and the on-behalf-of exchange for calls in a user’s context, and it exposes no host port.¹⁰ Federation moves trust to the external issuer, so approving a federated credential is approving every workload that issuer will vouch for under that subject (Book 04, Chapter 05).
3. A certificate, with the private key in Azure Key Vault or a hardware security module, kept within the program’s 180-day certificate cap (below) even though blueprints allow long-lived credentials.¹¹
4. A client secret only for development and test. Microsoft supports secrets on blueprints but says they aren’t recommended for production, and its best practices say to rotate them out before going live.¹²¹³

Microsoft also says to isolate credentials per blueprint and per environment, using separate blueprints or environment-specific federated credentials for development, test and production, and to review sign-in logs to confirm agents use the intended credential type.¹⁴

Enforcing the order

A blueprint is an application object, and Microsoft notes that a tenant’s credential lifecycle policies can restrict the lifetime of secrets added to it.¹⁵ The program’s application management policy from Book 04, Chapter 05, blocking new client secrets and capping certificate lifetime at 180 days for applications created after its effective date, therefore covers blueprints too. Production blueprints get no exception; a secret on a production blueprint is a finding.

CISA’s SCuBA baseline for Entra ID is moving the same way. ScubaGear 2.0.0, released October 22, 2026, adds three policies under section 5, all marked SHOULD and last modified in April 2026: application password addition should be blocked (MS.AAD.5.5v1), application password lifetime should be restricted to 180 days or less (MS.AAD.5.6v1), and application certificate lifetime should be restricted to 365 days or less (MS.AAD.5.7v1).¹⁶¹⁷ The previous release, 1.8.0, had only the three consent and registration policies in section 5. The new three carry no BOD 25-01 requirement indicator and aren’t BOD 25-01 required configurations.¹⁸¹⁹ The program’s 180-day certificate cap is stricter than the 365-day policy and meets it.

The same release adds the first SCuBA policy written for agents: MS.AAD.9.1v1, “Risky AI agents SHALL be blocked.” Its implementation is a single Conditional Access policy that targets all agent identities and all resources, sets the agent risk condition to High and blocks access. It needs a Microsoft Entra ID P2 license and either Microsoft Agent 365 or Microsoft 365 E7, and it doesn’t apply to GCC High or DoD tenants.²⁰²¹ ScubaGear marks it as a BOD 25-01 requirement, but CISA’s Required Configurations page didn’t list it on October 26, 2026, and until the page changes, the page governs (Book 11, Chapter 04).²² The program treats it as notice of what is coming. The policy rests on the agent risk condition, which is in preview, and on licensing a GCC tenant may not hold (Chapter 04), so the program records the policy’s ScubaGear result for each tenant now and puts the block in place when the condition is generally available in the agency’s cloud.

When the agent reaches something Entra doesn’t protect

Credentials are not only the agent’s own. Many agent tools call services with API keys. Microsoft’s Conditional Access documentation is explicit about the effect: an agent that accesses a resource with an API key bypasses Entra ID authentication and token issuance entirely, and Conditional Access doesn’t apply.²³ A tool reached that way is outside the identity program, and the agent’s identity, policy and logs say nothing about it. The program’s rule is that agent tools use Entra-issued tokens wherever the service accepts them; where a key is unavoidable, it lives in a key vault the agent’s identity can read, it has a named owner and a rotation date, and it is recorded in the identity record as an exception.

For comparison, other clouds have built the same pattern. Amazon Bedrock AgentCore Identity implements agent identities as workload identities and provides credential management for agents and tools that call AWS resources and third-party services.²⁴ The principle doesn’t change with the vendor: the agent proves itself with a credential the platform manages, and secrets for downstream services are held by a governed store, not by the agent’s code.

Least privilege for Microsoft Graph and APIs

NIST SP 800-53 AC-6 applies least privilege to “users (or processes acting on behalf of users).”²⁵ An agent is such a process, and it can use its access at a speed and scale no person can.

Choose the access mode first

Microsoft describes three ways an agent runs, and the choice decides which permissions it needs and who the token represents.²⁶

Agent access modes. Source: Microsoft Learn, Agent 365 identity.

Mode	Who the agent acts as	Permission type	Token subject
On-behalf-of	A signed-in user	Delegated	The user; the agent identity is the actor
Service-to-service (app-only)	Its own agent identity	Application	The agent identity
Agent user	Its own agent’s user account	User-style access; licenses for Microsoft 365 resources	The agent’s user account

Microsoft’s guidance is to use the on-behalf-of flow for interactive agents so that the user’s access policies and consent apply, to use app-only access only for autonomous agents with only the permissions they need, and to avoid application permissions where delegated ones would do.²⁷ Those are the three modes Microsoft’s protocol reference describes for agents: on behalf of a user, autonomously through the agent identity’s own service principal, and through an agent’s user account.²⁸ With delegated access the agent can’t exceed what the user could do; with application permissions, the grant is tenant-wide and an administrator must consent to it explicitly.²⁹ The program’s design follows that order: on-behalf-of first; app-only only when no user is present and the identity record states why; an agent’s user account only when the agent genuinely needs a mailbox, Teams presence or a user-only API, which Microsoft says is the only time to create one.³⁰ Agents’ user accounts are also preview-only, available to tenants in the Frontier preview program.³¹

What Microsoft blocks, and what it doesn’t

Microsoft Entra limits what agent identities can be granted. Many highly privileged directory roles can’t be assigned to agents (Global Administrator, Privileged Role Administrator and User Administrator among them), agent identities can’t be members of role-assignable groups, and a set of high-risk Microsoft Graph permissions can’t be granted even by an administrator. Microsoft’s examples of blocked permissions are Application.ReadWrite.All, RoleManagement.ReadWrite.All, User.ReadWrite.All and Directory.AccessAsUser.All, and it says the lists of allowed roles and permissions will change over time.³² An agent’s user account likewise can’t hold privileged administrator roles or be added to role-assignable groups, though it can hold custom roles.³³

That is a floor, not least privilege. Microsoft’s list of roles that can be assigned to agent identities includes Exchange Administrator, SharePoint Administrator, Teams Administrator, Power Platform Administrator, Compliance Administrator and Global Reader,³⁴ each of which is a privileged role in an agency tenant. The published permission examples are examples, so the absence of a permission from them isn’t evidence that an agent may safely hold it. The program applies its own permission risk classification from Book 04, Chapter 05 to agents unchanged, and treats “not blocked by Microsoft” as irrelevant to approval.

Inherited permissions

Blueprints can declare inheritable permissions: delegated scopes and application roles that every agent identity created from the blueprint receives without a separate consent prompt. Each resource can be configured to inherit all available scopes or roles (allAllowed), which automatically includes anything later granted to the blueprint principal, or none; a blueprint can list up to 50 resource applications. Microsoft recommends reviewing the configuration regularly, removing unused inherited permissions and recording why each one is inheritable and who approved it.³⁵ Declaring a permission on a blueprint doesn’t grant it; an administrator still has to consent, on the blueprint principal or on individual agent identities.³⁶ Inherited permissions also don’t show on the agent identity in the admin center or through Microsoft Graph; they are visible only in the token at runtime,³⁷ so the identity record, not the portal, is where the program keeps the list.

The program’s design keeps inheritance narrow. Inherited permissions carry only the shared baseline every agent of that kind needs. allAllowed is never used for application roles, because it turns any future grant to the blueprint into a grant to every agent. Role-specific access is assigned to individual agent identities through expiring access packages (Chapter 05), so that it comes up for decision.

Azure resources and other APIs

Azure role-based access control follows a different rule: blueprints can’t hold Azure RBAC roles, so roles are assigned directly to each agent identity,³⁸ and Microsoft’s guidance is to scope them to the specific resource, such as Key Vault Reader on one vault.³⁹ Applications that expose their own APIs are reached either by consenting the agent identity to the application’s OAuth scopes or by assigning it an app role. Agents and service principals assigned to app roles aren’t provisioned into applications by Entra’s SCIM provisioning, which supports users and groups only; an application that supports only SAML for users needs an agent’s user account and a helper registration.⁴⁰ Every such assignment is recorded against the agent’s identity record.

Admin consent and the SCuBA consent baseline

CISA’s BOD 25-01 required configurations include three Entra ID policies on applications, each added on December 17, 2024: only administrators shall be allowed to register applications (MS.AAD.5.1v1), only administrators shall be allowed to consent to applications (MS.AAD.5.2v1), and an admin consent workflow shall be configured (MS.AAD.5.3v1).⁴¹ The SCuBA baseline document words MS.AAD.5.2v1 as “User consent to applications SHALL be restricted” and allows it to be met either with no user consent or with user consent only for apps from verified publishers that use permissions an administrator has classified as low risk.⁴² Book 04, Chapter 05 describes the consent settings and the workflow, and Book 15, Chapter 06 explains why consent restriction answers who approves an integration but not whether the service is authorized.

Applied to agents, the baseline means three things in the program’s design.

• Registration. The analog of MS.AAD.5.1v1 for agents is the tenant setting Users can create agent blueprints, which, when set to Yes, lets any user create a blueprint and its principal; otherwise the Agent ID Developer and Agent ID Administrator roles are needed.⁴³ The program sets it to No. Microsoft also tells developers not to represent an agent with an ordinary app registration,⁴⁴ so a new app registration whose purpose is an agent is routed to the blueprint path rather than approved as an application.
• Delegated consent for on-behalf-of agents. An interactive agent acting for a user needs delegated scopes, and users can consent to an agent only within the tenant’s user consent policy. The program’s policy from Book 04, user consent only for verified-publisher and in-tenant apps, and only for permissions classified as low, applies unchanged; anything else goes through the admin consent workflow.
• Application consent for autonomous agents. Application permissions always need admin consent.⁴⁵ Granting Microsoft Graph application permissions to a blueprint takes Privileged Role Administrator, the least-privileged role for that task, while Cloud Application Administrator or Application Administrator can grant delegated Graph permissions.⁴⁶ The program grants those through PIM activation against an approved ticket, as it does for every application (Book 04, Chapter 06).

Tools need consent too. When a developer registers a remote Model Context Protocol (MCP) server with Microsoft Agent 365, an administrator reviews it in the Microsoft 365 admin center (the Requests tab is preview), approves or rejects it, and then consents to the Entra permissions it needs; the server becomes available to agent-building surfaces only after consent. Approving requires both access to the Tools page and the ability to grant tenant-wide consent, which Microsoft says two roles have: AI Administrator and Global Administrator.⁴⁷ The program assigns AI Administrator through PIM for that task and never uses Global Administrator for it.

Conditional Access and risk policies

The token subject decides which policy applies

Conditional Access for agents evaluates whoever is the subject of the token, and an agent can be any of three subjects. Microsoft’s guidance is to create a separate policy for each token subject an agent uses, because a policy targeting one subject doesn’t apply to the others.⁴⁸

Chapter 04’s figure on whose token an AI system presents shows the same three subjects, plus the API key that bypasses all of them. The policy consequences are these.

Conditional Access for agents. Source: Microsoft Learn, Conditional Access for agents, Target agents in Microsoft Entra Conditional Access policies, and Conditional Access: Grant.⁴⁹⁵⁰⁵¹

Agent access pattern	Policy targets	Available controls
On-behalf-of a user	The user, directly or through groups; selecting an agent identity doesn’t cover this flow	The user’s normal controls; the on-behalf-of token exchange is itself evaluated
App-only, as the agent identity	All agent identities, selected agent identities, a blueprint (covering its current and future identities), or custom security attributes	Block only; the only condition is Agent risk (Preview)
As the agent’s user account	All agent users (Preview) or selected agent users; policies scoped to Users, including all users, don’t apply	Block, or grant with Require device to be marked as compliant; device platform, device filter and compliant-network conditions for agents on endpoints

Microsoft documents a set of boundaries the program has to plan around. Conditional Access doesn’t apply when a blueprint obtains a Microsoft Graph token to create agent identities or agents’ user accounts, or when a blueprint or agent identity performs the intermediate exchange at the AAD Token Exchange Endpoint: Public; it doesn’t apply when security defaults are enabled; and it protects only resources secured by Entra ID, so API-key access bypasses it. Policies can’t include or exclude agents’ user accounts by group membership, and a policy targeting agent identities, including one scoped by blueprint, doesn’t reach the agent’s user account.⁵²

The pattern Microsoft recommends for autonomous agents is a policy that includes All agent identities, targets All resources, grants Block, and excludes approved agents, preferably by a custom security attribute such as an approval status, starting in report-only mode.⁵³ The program’s design builds that policy in report-only mode and sets the approval attribute only in the production handshake (Chapter 05), so that the report shows every agent that skipped the handshake. Turning it on is a decision for when the agent targets leave preview in the agency’s cloud (see the status note below). Microsoft’s best practices add that broad user policies, such as one requiring MFA for all users, should be reviewed for unintended effects on agent flows and agents excluded from them where necessary, with dedicated agent policies in their place.⁵⁴

Licensing for these policies is not the same as for users. Conditional Access for agents requires Microsoft 365 E7, or a Microsoft Agent 365 license with at least Entra ID P1 or Microsoft 365 E3, and agent risk-based policies need Entra ID P2 or Microsoft 365 E5 alongside Agent 365.⁵⁵⁵⁶

NoteStatus note: Book 04’s preview statement still holds

Book 04, Chapter 03 records that agent targets in Conditional Access are in preview and that agent identities support only Block. Checked on October 22, 2026, both still hold. The Agent ID platform became generally available in April 2026,⁵⁷ but the policy builder still labels the assignment as Users, agents (Preview) or workload identities, labels the agent-user targets, the Agent risk condition and the Agent execution environments condition as preview, and agent identities still support only Block.⁵⁸⁵⁹ Microsoft’s pages aren’t consistent (the autonomous-agent guide no longer shows the preview label on Agents),⁶⁰ so the program reads the policy builder’s label as the release stage. Since Book 04 was written, Microsoft has added an Agent 365 license requirement and, as a June 2026 public preview, a compliant-device grant for agents’ user accounts.⁶¹ The program keeps all agent policies in report-only mode as watch items until the label is removed.

ID Protection for agents

Microsoft Entra ID Protection evaluates risk for agents that use agent identities. Its detections include confirmed compromise, early-life malicious activity, directory reconnaissance, failed access attempts, threat intelligence matches, sign-in spikes, suspicious credential usage (a new credential added to a blueprint and then used) and unfamiliar resource access; all agent risk detections are currently offline rather than real-time. A learning mode suppresses behavioral alerts for agents without enough activity history while a separate detection still watches early-life behavior. In on-behalf-of flows, risky activity is attributed to the user rather than the agent, so the remediation targets the compromised session. Detections are kept for up to 90 days, and risky agents can be confirmed compromised, confirmed safe, dismissed or disabled from the report.⁶² Agent risk is preview, ID Protection for agents requires Entra ID P2 during the preview, and Microsoft says it will soon require an Agent 365 license.⁶³⁶⁴⁶⁵

The program’s design pairs a Block high-risk agent identities policy (report-only first) with the operational rule that a risky-agent alert goes to the agent’s sponsor as well as to security operations, because the sponsor is the person who can say whether a burst of activity was expected (Chapter 05). The telemetry tables for agent risk are in Book 12, Chapter 03.

Workload identities that aren’t agents

Many AI systems run as ordinary service principals and managed identities, and the controls in Book 04, Chapter 05 apply to them unchanged: Conditional Access for workload identities can block a single-tenant service principal by location, by ID Protection risk or with authentication contexts; Block is the only grant; managed identities and multitenant applications aren’t covered; a service principal must be assigned to the policy directly, not through a group; and creating or changing these policies needs Workload ID Premium.⁶⁶ Microsoft says Workload ID Premium is available to Azure Government customers through their account manager and that its free trial isn’t available in the Azure Government clouds.⁶⁷ A managed identity used by an AI system is therefore governed through its role assignments and reviews, not through Conditional Access.

Privileged roles for AI: none standing

The program’s rule is that no AI identity holds a standing privileged role. That covers Entra directory roles, Azure roles at management-group or subscription scope, and administrative roles inside Microsoft 365 workloads.

The rule needs stating because Microsoft’s block list doesn’t enforce it. As shown above, agents can’t hold Global Administrator or Privileged Role Administrator but can hold Exchange Administrator, SharePoint Administrator and other roles the program classifies as privileged (Book 04, Chapter 04).⁶⁸ An agent with Exchange Administrator around the clock is a standing administrator that can’t be asked for MFA.

Where an AI system genuinely needs privileged access, the program gives it in one of three ways, in this order:

1. Delegated, through a person’s own activated role. An agent that acts on behalf of an administrator uses that administrator’s access, so the person’s PIM activation, approval and MFA still govern it (Book 04, Chapter 08). Microsoft’s Microsoft 365 Admin agent works this way: it honors the administrator’s existing Entra role assignments, so what it can do reflects the administrator’s role.⁶⁹
2. A time-bound assignment through an expiring access package. Access packages can grant Microsoft Entra roles to agent identities, and an agent identity can request a package programmatically, which routes the request to the package’s human approvers and ends the assignment on its end date.⁷⁰ That gives the agent just-in-time access with a human decision in front of it. Entra roles as access package resources are still preview.⁷¹
3. A time-bound active assignment in PIM. PIM assigns roles to users, groups, service principals and managed identities, as eligible or active, with start and end dates.⁷² Activation of an eligible assignment is designed around a person acting (MFA, justification, approval), so for a nonhuman principal the program uses a time-bound active assignment approved through the ticket, never a permanent one.

Every privileged assignment to an AI identity is logged and reviewed under AC-6(7), and its use is logged under AC-6(9).⁷³ If an AI system needs a privileged role permanently, the program treats that as a design defect to be fixed, not an exception to be renewed.

Tool and data access boundaries

An agent’s reach is the sum of the tools it can call. Microsoft describes tools as how agents interact with their environment (web search, database access, APIs, file systems and other software) and says each tool needs careful thought about security and permissions.⁷⁴ The identity program draws the boundary in three layers.

Figure 2: An agent’s reach is bounded three times: by what its identity can obtain a token for, by which tools are registered and approved, and by what data protection lets it touch; in GCC the third layer falls back to scoped permissions.

Layer 1: what the identity can obtain a token for

Each tool that is an Entra-protected resource is its own token audience, and Conditional Access evaluates both the subject and the audience at issuance.⁷⁵ The agent’s consents, app role assignments and access packages are therefore the first list of what it can call. For MCP servers specifically, the protocol’s authorization specification makes a protected MCP server an OAuth 2.1 resource server that must validate that tokens were issued for it as the audience and must not accept or pass through any other tokens. The same specification also makes authorization optional for MCP implementations and says implementations using the local STDIO transport should not follow it and should take credentials from the environment instead.⁷⁶ Microsoft’s guidance for an MCP server protected by Entra ID says the same from the platform side: on every request, before any tool runs, the server validates the token’s signature, issuer, tenant, audience and expiry, then checks the caller’s roles or scopes, using a tested library rather than hand-written checks.⁷⁷ An MCP server that doesn’t implement authorization, or a local server reading a key from an environment variable, sits outside Layer 1 and needs Layers 2 and 3.

Layer 2: which tools are registered and approved

Microsoft Agent 365 keeps a Tools registry in the Microsoft 365 admin center that Microsoft calls the source of truth for MCP servers available in the tenant; custom and third-party servers registered through its bring-your-own process are reviewed, approved and consented centrally.⁷⁸⁷⁹ Agent 365 lists tenant-wide control of which tools, including Microsoft MCP servers, agents can access as available in GCC.⁸⁰ Integration with Azure API Management, which enforces policy inline for MCP traffic and can control individual tools on supported tiers, is preview, as is connecting a tools gateway to the admin center.⁸¹⁸² The program’s design records each agent’s approved tools in its identity record and treats a tool call to an unregistered server as drift (Chapter 07).

Layer 3: what data the agent can touch

Data boundaries for agents (sensitivity labels honored by agents, data loss prevention that blocks agents from sensitive content, insider risk for agents) are Microsoft Purview capabilities in Agent 365, and the service description lists none of them as available in GCC; nor are Entra’s network controls for agent traffic or Defender’s blocking of agent tool invocations.⁸³ For agencies in GCC, the data boundary therefore has to come from the identity layer: narrow delegated scopes, application permissions limited to specific sites or mailboxes where the API allows it (Exchange application access policies, for example, in Book 04, Chapter 05), and resource-scoped Azure roles. Book 12, Chapter 09 covers data protection generally.

The three boundaries on what an agent can call. Program design built on the cited platform features.

Boundary	Mechanism	Program rule
Identity	Consents, app roles, access packages, resource-scoped Azure roles	Every grant in the identity record; nothing standing; Block policy excludes only approved agents
Tool registry	Agent 365 Tools page, approval and consent	Approved tools listed per agent; unregistered server is drift
Data	Purview for agents where available; otherwise scoped permissions	In GCC, scoped permissions are the boundary; record the gap

At the network edge: Global Secure Access for AI traffic

Microsoft Entra Global Secure Access adds controls on the network path between people, agents and AI services. They don’t replace the three boundaries above; they catch what the identity layer can’t see, such as a prompt, or a tool call to a server that doesn’t use Entra ID at all.

• Prompt injection protection. A prompt policy in Entra Internet Access scans prompts sent to generative AI apps and blocks adversarial prompts and jailbreak attempts before they reach the model. It comes preconfigured for a list of public models (ChatGPT, Claude, Gemini and others) and can cover any JSON-based model the agency names by URL and JSON path. It needs the Internet Access license, TLS inspection and the Global Secure Access client on Entra joined or hybrid joined Windows devices, and it handles text prompts only, up to 64,000 characters.⁸⁴
• The MCP firewall (preview). An MCP policy inspects MCP traffic between agents and remote MCP servers and allows or blocks whole servers, individual tools, resources or prompt templates, transports and protocol versions. Microsoft’s own example is a default Block with an allow-list of approved servers, which is the network form of the program’s Layer 2 rule. It also needs TLS inspection; local servers over stdio and JSON-RPC batches aren’t inspected.⁸⁵
• The Secure Web and AI Gateway for Copilot Studio agents. Agent traffic (HTTP nodes, custom connectors, the MCP server connector) is forwarded per Power Platform environment to the same proxy, where web content filtering, threat intelligence filtering and file filtering apply to agents as they do to users. Extending these controls to agents requires Agent 365.⁸⁶

The program’s design uses the MCP firewall’s default-Block posture where it is available, with the allow-list built from the approved tools recorded in each identity record, and treats a block event for an agent as a drift signal for Chapter 07. Where it isn’t available, the identity and tool-registry layers are the whole boundary, and the gap is recorded.

Global Secure Access is available in GCC but not yet supported in GCC High, DoD or other government clouds,⁸⁷ and Agent 365 lists Entra’s network controls for agents as not available in GCC.⁸⁸ In practice, an agency in GCC can use prompt injection protection and the MCP firewall for traffic from its managed devices, but not the agent gateway; an agency in GCC High or DoD can’t use any of the three yet.

The workload-identity controls, applied per agent

Each control in this chapter and the two before it is a workload-identity control Book 04, Chapter 05 already sets for applications, applied to an agent. The table brings them together as one record per agent, so an assessor can see every control for one agent in one place, and adds the one the chapters describe but don’t proceed through: the kill switch. Migrating a service account an AI system already uses onto a managed identity or a federated credential is the service account guide’s Migration C; where AI sits in an application’s architecture is Book 18, Chapter 05.

Authority: Microsoft-recommended for the platform controls (sponsor at creation, credential order, least privilege, Conditional Access, disable before delete), from the Learn pages cited in Chapters 04 to 07, read Oct 21–22 and Nov 11, 2026. Mandated for the fail-safe where M-25-21’s minimum practices apply to a high-impact AI use case, which asks for one “when practicable” (Chapter 02). The two-person record and the tested disable are risk-based recommended, the program’s position; the yearly disable test is its settled position (WD-148). Applies: every AI system with an identity in the tenant. License-dependent: Conditional Access for agents needs Microsoft 365 E7 or Agent 365 with Entra ID P1; Conditional Access for workload identities needs Workload ID Premium (above). Environment-dependent: Agent ID is partly available in GCC and isn’t published as available in GCC High or DoD, where AI systems are governed as workload identities (Chapter 04). There the gates that keep an AI identity from being created outside the program are Book 04’s: administrator-only registration and consent, run as one governed process (Book 04, Chapter 05), and the tenant-creation restriction with its Tenant Creator workflow, which stops an AI system being stood up in a new tenant the program doesn’t govern (Book 04, Chapter 09). Book 04 records the GCC High and DoD availability of both settings as not yet specified.

Control	For an agent identity	For an AI system on a service principal or managed identity	Where it’s set	What the identity record holds
Sponsor	Required at creation; a federal employee mastered in HR	Recorded in the application registry and serviceManagementReference	Chapter 05	Sponsor, matching the directory
Owner	A named technical owner	Two technical owners (Book 04)	Chapter 05; Book 04	Owners
Least privilege	On-behalf-of first; narrow inherited permissions; no standing privileged role	Scoped consent; resource-scoped Azure roles	Above	Every grant, with its approver and end date
Non-secret credential	Managed identity or federated credential on the blueprint; certificate only by exception; no secret in production	Managed identity, then federation, then a certificate under the 180-day cap (Book 07, Chapter 08)	Above	Credential type and, for a certificate, its expiry
Network restriction	Global Secure Access MCP and prompt policies where available	Conditional Access for workload identities by location (Book 04’s CA015)	Above	Allowed tools and egress, or the recorded gap
Monitoring	Agent sign-in logs, ID Protection for agents, drift findings	Service principal sign-ins and workload risk	Chapter 07	Alert routing to the sponsor and security operations
Lifecycle	Expiring access packages; recertification; disable, then delete	Book 04’s governed lifecycle (Book 04)	Chapter 05	Next recertification date
Kill switch	Disable the agent identity, the blueprint, or all agents	Disable the service principal	Below	Who may pull it, and the last test

The kill switch

Microsoft documents three scopes for stopping agent activity. Disabling one agent identity, or one blueprint, keeps the object and its metadata but stops it receiving tokens; three Conditional Access policies block token issuance tenant-wide, to all agent identities, to all agents’ user accounts, or to users signing in to agents, without changing any object; and the two can be combined. Microsoft recommends running the Conditional Access policies in report-only mode first. It also warns that disabling can make running agents fail, can make Microsoft product experiences that assume agent identities fail or fall back, and that disabling a multitenant blueprint in all tenants affects its agents in other tenants.⁸⁹ A sponsor can disable an agent but can’t re-enable it (Chapter 05).

Prerequisites

Agent ID Administrator (through PIM) for the object-scoped disable, or the AgentIdentity.EnableDisable.All permission, which is the least-privileged permission for the update;⁹⁰ Conditional Access Administrator for the tenant-wide policies, which need Entra ID P1.⁹¹ The Microsoft Graph agent identity update is listed for the US Government L4 and L5 (DoD) deployments,⁹² but Agent ID itself isn’t published as available in GCC High or DoD, so there the switch is the service principal disable below.

Pilot

Test on a development agent identity first, then on one production agent with its sponsor present, in a change window.

Report-only phase

Create Microsoft’s three tenant-wide block policies now, in report-only mode, so the hold exists before it’s needed; they show which agents would have been stopped without stopping any. Turn on Policy 1 only for an incident.

Enforcement: pulling the switch

# One agent identity: stop it receiving tokens (keeps the object). Microsoft Graph PowerShell, as Agent ID Administrator through PIM
Connect-MgGraph -Scopes 'AgentIdentity.EnableDisable.All' -NoWelcome
Invoke-MgGraphRequest -Method PATCH -Uri 'https://graph.microsoft.com/v1.0/servicePrincipals/<agent identity object id>/microsoft.graph.agentIdentity' `
    -Body (@{ accountEnabled = $false } | ConvertTo-Json) -ContentType 'application/json'

# An AI system on an ordinary service principal
Connect-MgGraph -Scopes 'Application.ReadWrite.All' -NoWelcome
Update-MgServicePrincipal -ServicePrincipalId '<service principal object id>' -AccountEnabled:$false

For a GCC High or DoD tenant, connect with -Environment USGov or USGovDoD and use the matching Graph host. A blueprint is disabled in the admin center (Entra ID > Agents > Agent blueprints > the blueprint > Disable), and the tenant-wide hold is Microsoft’s Policy 1 switched from report-only to On:⁹³

# Tenant-wide hold on agent identity authentication: switch the existing report-only policy on (Conditional Access Administrator)
Connect-MgGraph -Scopes 'Policy.ReadWrite.ConditionalAccess' -NoWelcome
Update-MgIdentityConditionalAccessPolicy -ConditionalAccessPolicyId '<Policy 1 id>' -State 'enabled'

Disabling stops new tokens; access tokens already issued stay valid until they expire. Removing the agent’s grants or deleting it are separate retirement decisions (Chapter 05).

Rollback

Set accountEnabled back to true with the same call (an owner or Agent ID Administrator; a sponsor can’t), or set the Policy 1 state back to enabledForReportingButNotEnforced. Rollback takes minutes; the decision to roll back is the sponsor’s, after security operations closes the incident.

Exclusions

None for the object-scoped disable. Microsoft’s Policy 1 template excludes nothing; an agent the agency must keep running through a tenant-wide hold is excluded by name, with the sponsor’s and the CISO’s approval recorded, and the exclusion reviewed when the hold ends.

Telemetry

The disable appears in the audit log as an update to the service principal (agent identities are logged under their base identity type, with agentType other than notAgentic on the target), and the agent’s sign-in attempts after it as failures; Policy 1’s report-only results show every agent the hold would stop.⁹⁴ Chapter 07 routes both.

Evidence

Control states.

State	This page	Evidence
Designed	The table above, per agent	The identity record: sponsor, owner, grants, credential, network rule, alert routing, recertification date, kill-switch holder
Configured	Credential, grants, policies, monitoring as set in Chapters 05–07	Graph exports of the agent identity, its sponsors and owners, grants and credential; policy exports
Enforced	App management policy blocking secrets; the agent Block policy when its target leaves preview; workload-identity location policy where licensed	Policy exports in the enforcing state, or the recorded preview status
Evidenced	A tested disable, and an agent that skipped the production handshake shown in Policy 1’s report	Test record (time to disable, failed sign-in after it, re-enable)
Operated	Recertification at each expiry; the inventory check; risk alerts to the sponsor	Recertification records; inventory history; alert history

A finding this page addresses is ready for closure when every applicable state has evidence; the authorizing official or assessor decides.

Evidence checklist

• Configuration: each agent’s identity record, and the Graph export it was checked against (Chapter 05’s read-only check for owners; sponsors through the agent identity’s sponsors relationship)
• Operational: agent sign-in and audit logs, risk detections and drift findings, kept for the program’s log retention
• Test: a disable test per production blueprint, at least yearly and before authorization (expected and observed outcome, date, tester); for a high-impact use case, the tested fail-safe M-25-21 asks for
• Exception: a certificate or secret on a blueprint, an API key a tool needs, and any kill-switch exclusion, each with approver and expiry
• Assessor-ready artifact: the identity records and the disable test, carried into the authorization package as Chapter 10 describes

Day-two ownership

The sponsor is accountable for the agent and holds the right to disable it; the owner keeps the credential and grants current; identity engineering runs the inventory check and the disable test; security operations can pull the tenant-wide hold during an incident under the incident commander’s authority. Drift looks like an agent with no confirmed sponsor, a credential type that changed, a grant outside its access package, or a disable test more than a year old.

NoteAssessment mapping

• Microsoft Zero Trust pillar: Identity (workload and agent identities), with AI as the Zero Trust Assessment’s pillar for agent tests
• CISA ZTMM pillar: Applications and Workloads
• Depends on: Book 04’s workload-identity controls and Conditional Access (Identity); Global Secure Access where available (Networks); Book 12’s telemetry for agent sign-ins (SecOps)
• Attack chain interrupted: Persistence and Privilege Escalation through an agent: a stolen blueprint credential or an over-granted agent used to act at machine speed, stopped by the credential order and, once found, by the kill switch

Release stage and government-cloud availability

Chapter 04 gives the general picture for Agent ID and workload identities, including agents’ user accounts (preview, Frontier program only), the partial GCC subset, no published availability in GCC High or DoD, and Agent 365’s pending FedRAMP High authorization. The table below covers only the features this chapter relies on, as published on October 22, 2026. “Not published” means Microsoft’s documentation states no availability.

Credential and access-policy features for AI identities by release stage and cloud.

Feature	Release stage	GCC	GCC High, DoD
Blueprint credentials: managed identity as federated credential, certificates, secrets	Part of the generally available platform (April 2026);95 admin center wizard preview96	Available with the platform97	Not published
App management policies restricting blueprint secrets and certificate lifetime	Generally available; free Workload ID feature98	Available	Not stated on the pages checked; confirm in the tenant
Conditional Access for agent identities (Block only)	Preview: the policy builder labels the agents assignment as preview99	Listed for agents with delegated access (“extend user policies to agents”)100	Not published
Conditional Access for agents’ user accounts	Preview101	Not published	Not published
Agent risk condition and ID Protection for agents	Preview102103	Listed with Conditional Access for agents with delegated access104	Not published
Conditional Access and ID Protection for workload identities	Generally available; Workload ID Premium105	Available	Workload ID Premium through the account manager106
Tenant-wide control of agent tools; MCP server approval	Documented; the Requests tab is preview107	Available108	Not published
API Management and tools gateway integration	Preview109110	Not published	Not published
Network controls, data loss prevention and labels for agents	See service description	Not available111	Not published
Global Secure Access prompt injection protection	Not labeled preview on its page112	Global Secure Access available in GCC113	Not yet supported114
Global Secure Access MCP firewall	Preview115	As above	Not yet supported
Secure Web and AI Gateway for Copilot Studio agents	Not labeled preview on its page; requires Agent 365116	Network controls for agents not available117	Not yet supported

The Conditional Access rows for GCC need care. Microsoft’s Agent 365 service description lists “Conditional access and identity protection for agents (for agents with delegated access – extend user policies to agents)” as available in GCC.¹¹⁸ It doesn’t separately list policies that target agent identities in app-only flows, so an agency in GCC should confirm that support in its own tenant before relying on the Block-unless-approved policy, and record the result. For GCC High and DoD the Graph endpoints differ, https://graph.microsoft.us and https://dod-graph.microsoft.us with authority https://login.microsoftonline.us, and Microsoft warns that configurable endpoints don’t guarantee the Agent 365 services are available there.¹¹⁹

Honest limits

1. The block lists move. Microsoft says the roles and permissions allowed for agents will change;¹²⁰ the program’s own classification, not Microsoft’s list, is the control, and it has to be re-run when the list changes.
2. Conditional Access can only block an agent identity. There is no grant control to satisfy, so the policy is a gate on approval and risk, not a step-up.
3. API keys and local tools are invisible to identity. Layer 1 can’t see them; only inventory discipline and tool registration can.
4. The data layer isn’t in GCC. Until Purview’s agent capabilities reach the government clouds, scoped permissions are the only data boundary, and they are coarse.
5. The higher clouds are a gap. Agencies in GCC High and DoD govern AI systems as workload identities today, with Workload ID Premium where licensed, and should say so in the authorization package (Chapter 10).

Certificates in this book and the CLM platform

Book 07 gives each class of certificate one issuer and one renewal engine, and makes CyberArk Certificate Manager, Self-Hosted the system of record for every certificate that Intune and the PIV system don’t manage (Chapter 04, Chapter 05). The certificates this book’s systems depend on map to it as follows; Book 07, Appendix C describes the platform itself.

Certificate	Book 07 class	Issued by	Renewed by	What the CLM platform does
Agent blueprint and service principal certificates	Not a Book 07 class	A CA, key in Key Vault or an HSM	The app’s owner or Key Vault	Can provision into Key Vault (inference); doesn’t renew Entra credentials
Global Secure Access TLS inspection	Not a Book 07 class	Not stated	Platform-managed, or not X.509	Not a Book 07 class
Google agent identities (SPIFFE certificates)	Not a Book 07 class	Google	Platform-managed, or not X.509	Nothing: vendor-managed

This book’s certificates and the engine that renews each.

None of this book’s certificates is renewed by the CLM platform. Agent and service-principal certificates aren’t one of Book 07’s classes; the 180-day certificate cap in the program’s application management policy governs them, and the platform at most places the certificate in Key Vault (inference).¹²¹

TipContinue the book

← Previous: Chapter 05 — Owners, Sponsors and the AI Identity Lifecycle · Book index · Next: Chapter 07 — Monitoring, Drift and Shadow AI →

---

1. Microsoft Learn, “Agent 365 identity,” sections Credentials, Agent’s user account, and Permissions and runtime flow, https://learn.microsoft.com/microsoft-agent-365/developer/identity (accessed Oct 22, 2026).

2. Microsoft Learn, “Microsoft Entra Conditional Access for workload identities,” https://learn.microsoft.com/entra/identity/conditional-access/workload-identity (accessed Oct 22, 2026).

3. Microsoft Learn, “Agent identities, service principals, and applications,” Impersonation model, Credential management and Permissions and role assignment, https://learn.microsoft.com/entra/agent-id/agent-service-principals (accessed Oct 22, 2026).

4. Microsoft Learn, “Agent 365 identity,” sections Credentials, Agent’s user account, and Permissions and runtime flow, https://learn.microsoft.com/microsoft-agent-365/developer/identity (accessed Oct 22, 2026).

5. Microsoft Learn, “Agent 365 identity,” sections Credentials, Agent’s user account, and Permissions and runtime flow, https://learn.microsoft.com/microsoft-agent-365/developer/identity (accessed Oct 22, 2026).

6. Microsoft Learn, “Agent identities, service principals, and applications,” Impersonation model, Credential management and Permissions and role assignment, https://learn.microsoft.com/entra/agent-id/agent-service-principals (accessed Oct 22, 2026).

7. Microsoft Learn, “Create an agent identity blueprint,” Prerequisites and Configure credentials for the agent identity blueprint, https://learn.microsoft.com/entra/agent-id/create-blueprint (accessed Oct 22, 2026).

8. Microsoft Learn, “Agent identities, service principals, and applications,” Impersonation model, Credential management and Permissions and role assignment, https://learn.microsoft.com/entra/agent-id/agent-service-principals (accessed Oct 22, 2026).

9. Microsoft Learn, “Integrate third-party agents with Microsoft Entra Agent ID,” https://learn.microsoft.com/entra/agent-id/configure-third-party-agents (accessed Oct 22, 2026).

10. Microsoft Learn, “Authentication with Microsoft Entra ID Auth SDK (sidecar),” How the Microsoft Entra ID Auth SDK (sidecar) works, https://learn.microsoft.com/entra/agent-id/authentication-with-auth-sdk-sidecar (accessed Nov 9, 2026).

11. Microsoft Learn, “Best practices for Microsoft Entra Agent ID,” sections Manage credentials securely, Enforce access controls and Design agent identity blueprints, https://learn.microsoft.com/entra/agent-id/best-practices-agent-id (accessed Oct 22, 2026).

12. Microsoft Learn, “Create an agent identity blueprint,” Prerequisites and Configure credentials for the agent identity blueprint, https://learn.microsoft.com/entra/agent-id/create-blueprint (accessed Oct 22, 2026).

13. Microsoft Learn, “Best practices for Microsoft Entra Agent ID,” sections Manage credentials securely, Enforce access controls and Design agent identity blueprints, https://learn.microsoft.com/entra/agent-id/best-practices-agent-id (accessed Oct 22, 2026).

14. Microsoft Learn, “Best practices for Microsoft Entra Agent ID,” sections Manage credentials securely, Enforce access controls and Design agent identity blueprints, https://learn.microsoft.com/entra/agent-id/best-practices-agent-id (accessed Oct 22, 2026).

15. Microsoft Learn, “Create an agent identity blueprint,” Prerequisites and Configure credentials for the agent identity blueprint, https://learn.microsoft.com/entra/agent-id/create-blueprint (accessed Oct 22, 2026).

16. Cybersecurity and Infrastructure Security Agency, CISA M365 Secure Configuration Baseline for Microsoft Entra ID, ScubaGear release v2.0.0, section 5, Application Registration and Consent (policies MS.AAD.5.1v1–5.3v1 and 5.5v1–5.7v1, and MS.AAD.5.2v1 instructions), and section 9, policy MS.AAD.9.1v1 (last modified March 2026; BOD 25-01 requirement indicator; note on GCC High and DoD; licensing; instructions), https://github.com/cisagov/ScubaGear/blob/v2.0.0/PowerShell/ScubaGear/baselines/aad.md, compared with the same file at tag v1.8.0, https://github.com/cisagov/ScubaGear/blob/v1.8.0/PowerShell/ScubaGear/baselines/aad.md (both accessed Oct 26, 2026).

17. Cybersecurity and Infrastructure Security Agency, ScubaGear release v2.0.0 (published October 22, 2026), release notes: “Add application management baseline policies (MS.AAD.5.5v1, MS.AAD.5.6v1, MS.AAD.5.7v1)” and, under “BOD 25-01 required configuration policy changes,” MS.AAD.9.1v1, https://github.com/cisagov/ScubaGear/releases/tag/v2.0.0 (accessed Oct 26, 2026).

18. Cybersecurity and Infrastructure Security Agency, CISA M365 Secure Configuration Baseline for Microsoft Entra ID, ScubaGear release v2.0.0, section 5, Application Registration and Consent (policies MS.AAD.5.1v1–5.3v1 and 5.5v1–5.7v1, and MS.AAD.5.2v1 instructions), and section 9, policy MS.AAD.9.1v1 (last modified March 2026; BOD 25-01 requirement indicator; note on GCC High and DoD; licensing; instructions), https://github.com/cisagov/ScubaGear/blob/v2.0.0/PowerShell/ScubaGear/baselines/aad.md, compared with the same file at tag v1.8.0, https://github.com/cisagov/ScubaGear/blob/v1.8.0/PowerShell/ScubaGear/baselines/aad.md (both accessed Oct 26, 2026).

19. Cybersecurity and Infrastructure Security Agency, “BOD 25-01: Implementing Secure Practices for Cloud Services Required Configurations,” Microsoft Entra ID, MS.AAD.5.1v1–5.3v1 (MS.AAD.5.5v1–5.7v1 and MS.AAD.9.1v1 not listed), https://www.cisa.gov/resources-tools/services/bod-25-01-implementing-secure-practices-cloud-services-required-configurations (accessed Oct 22 and Oct 26, 2026).

20. Cybersecurity and Infrastructure Security Agency, CISA M365 Secure Configuration Baseline for Microsoft Entra ID, ScubaGear release v2.0.0, section 5, Application Registration and Consent (policies MS.AAD.5.1v1–5.3v1 and 5.5v1–5.7v1, and MS.AAD.5.2v1 instructions), and section 9, policy MS.AAD.9.1v1 (last modified March 2026; BOD 25-01 requirement indicator; note on GCC High and DoD; licensing; instructions), https://github.com/cisagov/ScubaGear/blob/v2.0.0/PowerShell/ScubaGear/baselines/aad.md, compared with the same file at tag v1.8.0, https://github.com/cisagov/ScubaGear/blob/v1.8.0/PowerShell/ScubaGear/baselines/aad.md (both accessed Oct 26, 2026).

21. Cybersecurity and Infrastructure Security Agency, ScubaGear release v2.0.0 (published October 22, 2026), release notes: “Add application management baseline policies (MS.AAD.5.5v1, MS.AAD.5.6v1, MS.AAD.5.7v1)” and, under “BOD 25-01 required configuration policy changes,” MS.AAD.9.1v1, https://github.com/cisagov/ScubaGear/releases/tag/v2.0.0 (accessed Oct 26, 2026).

22. Cybersecurity and Infrastructure Security Agency, “BOD 25-01: Implementing Secure Practices for Cloud Services Required Configurations,” Microsoft Entra ID, MS.AAD.5.1v1–5.3v1 (MS.AAD.5.5v1–5.7v1 and MS.AAD.9.1v1 not listed), https://www.cisa.gov/resources-tools/services/bod-25-01-implementing-secure-practices-cloud-services-required-configurations (accessed Oct 22 and Oct 26, 2026).

23. Microsoft Learn, “Conditional Access for agents,” sections Agent access patterns and Boundaries and limitations, https://learn.microsoft.com/entra/identity/conditional-access/agent-id (accessed Oct 22, 2026).

24. Amazon Web Services, “Provide identity and credential management for agent applications with Amazon Bedrock AgentCore Identity,” Amazon Bedrock AgentCore Developer Guide, https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/identity.html (accessed Oct 22, 2026).

25. National Institute of Standards and Technology, SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations, controls AC-6, AC-6(7) and AC-6(9), statements checked against the release 5.2.0 OSCAL catalog, https://github.com/usnistgov/oscal-content/blob/main/nist.gov/SP800-53/rev5/json/NIST_SP-800-53_rev5_catalog.json (accessed Oct 22, 2026).

26. Microsoft Learn, “Agent 365 identity,” sections Credentials, Agent’s user account, and Permissions and runtime flow, https://learn.microsoft.com/microsoft-agent-365/developer/identity (accessed Oct 22, 2026).

27. Microsoft Learn, “Best practices for Microsoft Entra Agent ID,” sections Manage credentials securely, Enforce access controls and Design agent identity blueprints, https://learn.microsoft.com/entra/agent-id/best-practices-agent-id (accessed Oct 22, 2026).

28. Microsoft Learn, “Authentication protocols in agents,” Core protocol patterns and OAuth protocols, https://learn.microsoft.com/entra/agent-id/agent-oauth-protocols (accessed Nov 9, 2026).

29. Microsoft Learn, “Authorization in Microsoft Entra Agent ID,” sections Microsoft Entra role assignments for agent identities, Microsoft Entra roles allowed for agents, Microsoft Graph permissions for agent IDs and When to use Azure roles, Microsoft Entra roles, or Microsoft Graph permissions, https://learn.microsoft.com/entra/agent-id/authorization-agent-id (accessed Oct 22, 2026).

30. Microsoft Learn, “Best practices for Microsoft Entra Agent ID,” sections Manage credentials securely, Enforce access controls and Design agent identity blueprints, https://learn.microsoft.com/entra/agent-id/best-practices-agent-id (accessed Oct 22, 2026).

31. Microsoft Learn, “Agent 365 identity,” sections Credentials, Agent’s user account, and Permissions and runtime flow, https://learn.microsoft.com/microsoft-agent-365/developer/identity (accessed Oct 22, 2026).

32. Microsoft Learn, “Authorization in Microsoft Entra Agent ID,” sections Microsoft Entra role assignments for agent identities, Microsoft Entra roles allowed for agents, Microsoft Graph permissions for agent IDs and When to use Azure roles, Microsoft Entra roles, or Microsoft Graph permissions, https://learn.microsoft.com/entra/agent-id/authorization-agent-id (accessed Oct 22, 2026).

33. Microsoft Learn, “Learn about the agent’s user account in Microsoft Entra Agent ID,” Capabilities and Security constraints, https://learn.microsoft.com/entra/agent-id/agent-users (accessed Oct 22, 2026).

34. Microsoft Learn, “Authorization in Microsoft Entra Agent ID,” sections Microsoft Entra role assignments for agent identities, Microsoft Entra roles allowed for agents, Microsoft Graph permissions for agent IDs and When to use Azure roles, Microsoft Entra roles, or Microsoft Graph permissions, https://learn.microsoft.com/entra/agent-id/authorization-agent-id (accessed Oct 22, 2026).

35. Microsoft Learn, “Configure inheritable permissions for agent identity blueprints,” https://learn.microsoft.com/entra/agent-id/configure-inheritable-permissions-blueprints (accessed Oct 22, 2026).

36. Microsoft Learn, “Agent 365 identity,” sections Credentials, Agent’s user account, and Permissions and runtime flow, https://learn.microsoft.com/microsoft-agent-365/developer/identity (accessed Oct 22, 2026).

37. Microsoft Learn, “Inheritable permissions and required resource access in Microsoft Entra Agent ID,” Declaration, grant, and inheritance, https://learn.microsoft.com/entra/agent-id/concept-inheritable-permissions (accessed Nov 9, 2026).

38. Microsoft Learn, “Agent identities, service principals, and applications,” Impersonation model, Credential management and Permissions and role assignment, https://learn.microsoft.com/entra/agent-id/agent-service-principals (accessed Oct 22, 2026).

39. Microsoft Learn, “Authorization in Microsoft Entra Agent ID,” sections Microsoft Entra role assignments for agent identities, Microsoft Entra roles allowed for agents, Microsoft Graph permissions for agent IDs and When to use Azure roles, Microsoft Entra roles, or Microsoft Graph permissions, https://learn.microsoft.com/entra/agent-id/authorization-agent-id (accessed Oct 22, 2026).

40. Microsoft Learn, “Manage assignment of agent identities to an application,” https://learn.microsoft.com/entra/identity/enterprise-apps/assign-agent-identities-to-applications (accessed Oct 22, 2026).

41. Cybersecurity and Infrastructure Security Agency, “BOD 25-01: Implementing Secure Practices for Cloud Services Required Configurations,” Microsoft Entra ID, MS.AAD.5.1v1–5.3v1 (MS.AAD.5.5v1–5.7v1 and MS.AAD.9.1v1 not listed), https://www.cisa.gov/resources-tools/services/bod-25-01-implementing-secure-practices-cloud-services-required-configurations (accessed Oct 22 and Oct 26, 2026).

42. Cybersecurity and Infrastructure Security Agency, CISA M365 Secure Configuration Baseline for Microsoft Entra ID, ScubaGear release v2.0.0, section 5, Application Registration and Consent (policies MS.AAD.5.1v1–5.3v1 and 5.5v1–5.7v1, and MS.AAD.5.2v1 instructions), and section 9, policy MS.AAD.9.1v1 (last modified March 2026; BOD 25-01 requirement indicator; note on GCC High and DoD; licensing; instructions), https://github.com/cisagov/ScubaGear/blob/v2.0.0/PowerShell/ScubaGear/baselines/aad.md, compared with the same file at tag v1.8.0, https://github.com/cisagov/ScubaGear/blob/v1.8.0/PowerShell/ScubaGear/baselines/aad.md (both accessed Oct 26, 2026).

43. Microsoft Learn, “Create an agent identity blueprint,” Prerequisites and Configure credentials for the agent identity blueprint, https://learn.microsoft.com/entra/agent-id/create-blueprint (accessed Oct 22, 2026).

44. Microsoft Learn, “Plan your agent identity architecture,” Don’t register an app for your agent, https://learn.microsoft.com/entra/agent-id/how-to-plan-agent-identity-architecture (accessed Oct 22, 2026).

45. Microsoft Learn, “Authorization in Microsoft Entra Agent ID,” sections Microsoft Entra role assignments for agent identities, Microsoft Entra roles allowed for agents, Microsoft Graph permissions for agent IDs and When to use Azure roles, Microsoft Entra roles, or Microsoft Graph permissions, https://learn.microsoft.com/entra/agent-id/authorization-agent-id (accessed Oct 22, 2026).

46. Microsoft Learn, “Create an agent identity blueprint,” Prerequisites and Configure credentials for the agent identity blueprint, https://learn.microsoft.com/entra/agent-id/create-blueprint (accessed Oct 22, 2026).

47. Microsoft Learn, “Manage plugins, skills, and MCP servers,” Review and approve MCP requests, https://learn.microsoft.com/microsoft-365/admin/manage/manage-plugins-skills-mcp-servers (accessed Oct 22, 2026).

48. Microsoft Learn, “Conditional Access for agents,” sections Agent access patterns and Boundaries and limitations, https://learn.microsoft.com/entra/identity/conditional-access/agent-id (accessed Oct 22, 2026).

49. Microsoft Learn, “Conditional Access for agents,” sections Agent access patterns and Boundaries and limitations, https://learn.microsoft.com/entra/identity/conditional-access/agent-id (accessed Oct 22, 2026).

50. Microsoft Learn, “Target agents in Microsoft Entra Conditional Access policies,” Assignments, Conditions and Access controls, https://learn.microsoft.com/entra/identity/conditional-access/howto-target-agent-identities (accessed Oct 22, 2026).

51. Microsoft Learn, “Conditional Access: Grant,” Grant controls for agent users (Preview), https://learn.microsoft.com/entra/identity/conditional-access/concept-conditional-access-grant (accessed Oct 22, 2026).

52. Microsoft Learn, “Conditional Access for agents,” sections Agent access patterns and Boundaries and limitations, https://learn.microsoft.com/entra/identity/conditional-access/agent-id (accessed Oct 22, 2026).

53. Microsoft Learn, “Secure autonomous agents with Conditional Access,” Prerequisites, Allow only specific agents to access resources and Block high-risk agent identities, https://learn.microsoft.com/entra/identity/conditional-access/policy-autonomous-agents (accessed Oct 22, 2026).

54. Microsoft Learn, “Best practices for Microsoft Entra Agent ID,” sections Manage credentials securely, Enforce access controls and Design agent identity blueprints, https://learn.microsoft.com/entra/agent-id/best-practices-agent-id (accessed Oct 22, 2026).

55. Microsoft Learn, “Conditional Access for agents,” sections Agent access patterns and Boundaries and limitations, https://learn.microsoft.com/entra/identity/conditional-access/agent-id (accessed Oct 22, 2026).

56. Microsoft Learn, “Secure autonomous agents with Conditional Access,” Prerequisites, Allow only specific agents to access resources and Block high-risk agent identities, https://learn.microsoft.com/entra/identity/conditional-access/policy-autonomous-agents (accessed Oct 22, 2026).

57. Microsoft Learn, “Microsoft Entra releases and announcements,” April 2026 (General Availability, Microsoft Entra Agent ID platform) and June 2026 (Public Preview, Extended Conditional Access protections for agent’s user accounts), https://learn.microsoft.com/entra/fundamentals/whats-new (accessed Oct 22, 2026).

58. Microsoft Learn, “Target agents in Microsoft Entra Conditional Access policies,” Assignments, Conditions and Access controls, https://learn.microsoft.com/entra/identity/conditional-access/howto-target-agent-identities (accessed Oct 22, 2026).

59. Microsoft Learn, “Conditional Access: Grant,” Grant controls for agent users (Preview), https://learn.microsoft.com/entra/identity/conditional-access/concept-conditional-access-grant (accessed Oct 22, 2026).

60. Microsoft Learn, “Secure autonomous agents with Conditional Access,” Prerequisites, Allow only specific agents to access resources and Block high-risk agent identities, https://learn.microsoft.com/entra/identity/conditional-access/policy-autonomous-agents (accessed Oct 22, 2026).

61. Microsoft Learn, “Microsoft Entra releases and announcements,” April 2026 (General Availability, Microsoft Entra Agent ID platform) and June 2026 (Public Preview, Extended Conditional Access protections for agent’s user accounts), https://learn.microsoft.com/entra/fundamentals/whats-new (accessed Oct 22, 2026).

62. Microsoft Learn, “ID Protection for agents,” https://learn.microsoft.com/entra/id-protection/concept-risky-agents (accessed Oct 22, 2026).

63. Microsoft Learn, “Secure autonomous agents with Conditional Access,” Prerequisites, Allow only specific agents to access resources and Block high-risk agent identities, https://learn.microsoft.com/entra/identity/conditional-access/policy-autonomous-agents (accessed Oct 22, 2026).

64. Microsoft Learn, “Manage agent identities in your organization,” roles table and ID Protection note, https://learn.microsoft.com/entra/agent-id/manage-agent-identities-admin (accessed Oct 22, 2026).

65. Microsoft Learn, “ID Protection for agents,” https://learn.microsoft.com/entra/id-protection/concept-risky-agents (accessed Oct 22, 2026).

66. Microsoft Learn, “Microsoft Entra Conditional Access for workload identities,” https://learn.microsoft.com/entra/identity/conditional-access/workload-identity (accessed Oct 22, 2026).

67. Microsoft Learn, “Frequently asked questions about Microsoft Entra Workload ID,” https://learn.microsoft.com/entra/workload-id/workload-identities-faqs (accessed Oct 22, 2026).

68. Microsoft Learn, “Authorization in Microsoft Entra Agent ID,” sections Microsoft Entra role assignments for agent identities, Microsoft Entra roles allowed for agents, Microsoft Graph permissions for agent IDs and When to use Azure roles, Microsoft Entra roles, or Microsoft Graph permissions, https://learn.microsoft.com/entra/agent-id/authorization-agent-id (accessed Oct 22, 2026).

69. Microsoft Learn, “Use Microsoft 365 Admin agent,” Prerequisites, https://learn.microsoft.com/microsoft-365/copilot/copilot-ai-admin-agent (accessed Oct 22, 2026).

70. Microsoft Learn, “Governing agent identities,” Assigning access to agent identities, https://learn.microsoft.com/entra/id-governance/agent-id-governance-overview (accessed Oct 22, 2026).

71. Microsoft Learn, “Microsoft Entra ID Governance licensing fundamentals,” feature-by-license table, row EM – Microsoft Entra Roles (Preview), https://learn.microsoft.com/entra/id-governance/licensing-fundamentals (accessed Oct 22, 2026).

72. Microsoft Learn, “What is Microsoft Entra Privileged Identity Management?,” Role assignment overview, https://learn.microsoft.com/entra/id-governance/privileged-identity-management/pim-configure (accessed Oct 22, 2026).

73. National Institute of Standards and Technology, SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations, controls AC-6, AC-6(7) and AC-6(9), statements checked against the release 5.2.0 OSCAL catalog, https://github.com/usnistgov/oscal-content/blob/main/nist.gov/SP800-53/rev5/json/NIST_SP-800-53_rev5_catalog.json (accessed Oct 22, 2026).

74. Microsoft Learn, “What are agent identities,” What is an agent, https://learn.microsoft.com/entra/agent-id/what-are-agent-identities (accessed Oct 22, 2026).

75. Microsoft Learn, “Conditional Access for agents,” sections Agent access patterns and Boundaries and limitations, https://learn.microsoft.com/entra/identity/conditional-access/agent-id (accessed Oct 22, 2026).

76. Model Context Protocol, Specification, version 2026-07-28, Basic: Authorization, sections Protocol Requirements, Roles and Token Handling, https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization (accessed Oct 22, 2026).

77. Microsoft Learn, “Secure a Model Context Protocol (MCP) server with Microsoft Entra ID,” How MCP authorization works with Microsoft Entra ID and Validate access tokens in your MCP server, https://learn.microsoft.com/entra/agent-id/secure-mcp-server-with-entra-id (accessed Nov 9, 2026).

78. Microsoft Learn, “Understand MCP server options in Agent 365,” https://learn.microsoft.com/microsoft-agent-365/tooling-servers-overview (accessed Oct 22, 2026).

79. Microsoft Learn, “Manage plugins, skills, and MCP servers,” Review and approve MCP requests, https://learn.microsoft.com/microsoft-365/admin/manage/manage-plugins-skills-mcp-servers (accessed Oct 22, 2026).

80. Microsoft Learn, “Microsoft Agent 365” service description, Feature availability (including the GCC Availability column and the FedRAMP High note), https://learn.microsoft.com/office365/servicedescriptions/microsoft-agent-365/microsoft-agent-365 (accessed Oct 22, 2026).

81. Microsoft Learn, “Govern tools with Microsoft Agent 365 and Azure API Management (preview),” https://learn.microsoft.com/azure/api-management/agent-365 (accessed Oct 22, 2026).

82. Microsoft Learn, “Manage Tools Gateway,” https://learn.microsoft.com/microsoft-365/admin/manage/manage-tools-gateway (accessed Oct 22, 2026).

83. Microsoft Learn, “Microsoft Agent 365” service description, Feature availability (including the GCC Availability column and the FedRAMP High note), https://learn.microsoft.com/office365/servicedescriptions/microsoft-agent-365/microsoft-agent-365 (accessed Oct 22, 2026).

84. Microsoft Learn, “Protect enterprise generative AI applications with prompt injection protection,” Prerequisites, Generative AI models and Known limitations, https://learn.microsoft.com/entra/global-secure-access/how-to-ai-prompt-injection-protection (accessed Nov 9, 2026).

85. Microsoft Learn, “Configure Global Secure Access MCP firewall to secure MCP traffic (preview),” Supported scenarios, Prerequisites, Example 2 and Known limitations, https://learn.microsoft.com/entra/global-secure-access/how-to-configure-mcp-firewall (accessed Nov 9, 2026).

86. Microsoft Learn, “Learn about Secure Web And AI Gateway for Microsoft Copilot Studio agents,” https://learn.microsoft.com/entra/global-secure-access/concept-secure-web-ai-gateway-agents (accessed Nov 9, 2026).

87. Microsoft Learn, “Known limitations for Global Secure Access,” section “Global Secure Access In Government Cloud limitations,” https://learn.microsoft.com/entra/global-secure-access/reference-current-known-limitations (accessed Nov 9, 2026).

88. Microsoft Learn, “Microsoft Agent 365” service description, Feature availability (including the GCC Availability column and the FedRAMP High note), https://learn.microsoft.com/office365/servicedescriptions/microsoft-agent-365/microsoft-agent-365 (accessed Oct 22, 2026).

89. Microsoft Learn, “Disable agent identities in your tenant” (object-scoped disable of an agent identity or blueprint keeps the object and stops token issuance; three Conditional Access block policies for all agent identities, agents’ user accounts and users signing in to agents, report-only first, Entra ID P1; consequences for running agents, Microsoft experiences and multitenant blueprints; audit events logged under the base identity types with agentType), https://learn.microsoft.com/entra/agent-id/disable-agent-identities (accessed Nov 11, 2026).

90. Microsoft Learn, Microsoft Graph, “Update agentIdentity” (PATCH /servicePrincipals/{id}/microsoft.graph.agentIdentity; least-privileged permission AgentIdentity.EnableDisable.All; least-privileged role Agent ID Administrator; national cloud deployments: global service, US Government L4 and US Government L5 (DoD)), https://learn.microsoft.com/graph/api/agentidentity-update?view=graph-rest-1.0, and “agentIdentity resource type” (accountEnabled), https://learn.microsoft.com/graph/api/resources/agentidentity?view=graph-rest-1.0 (both accessed Nov 11, 2026).

91. Microsoft Learn, “Disable agent identities in your tenant” (object-scoped disable of an agent identity or blueprint keeps the object and stops token issuance; three Conditional Access block policies for all agent identities, agents’ user accounts and users signing in to agents, report-only first, Entra ID P1; consequences for running agents, Microsoft experiences and multitenant blueprints; audit events logged under the base identity types with agentType), https://learn.microsoft.com/entra/agent-id/disable-agent-identities (accessed Nov 11, 2026).

92. Microsoft Learn, Microsoft Graph, “Update agentIdentity” (PATCH /servicePrincipals/{id}/microsoft.graph.agentIdentity; least-privileged permission AgentIdentity.EnableDisable.All; least-privileged role Agent ID Administrator; national cloud deployments: global service, US Government L4 and US Government L5 (DoD)), https://learn.microsoft.com/graph/api/agentidentity-update?view=graph-rest-1.0, and “agentIdentity resource type” (accountEnabled), https://learn.microsoft.com/graph/api/resources/agentidentity?view=graph-rest-1.0 (both accessed Nov 11, 2026).

93. Microsoft Learn, “Disable agent identities in your tenant” (object-scoped disable of an agent identity or blueprint keeps the object and stops token issuance; three Conditional Access block policies for all agent identities, agents’ user accounts and users signing in to agents, report-only first, Entra ID P1; consequences for running agents, Microsoft experiences and multitenant blueprints; audit events logged under the base identity types with agentType), https://learn.microsoft.com/entra/agent-id/disable-agent-identities (accessed Nov 11, 2026).

94. Microsoft Learn, “Disable agent identities in your tenant” (object-scoped disable of an agent identity or blueprint keeps the object and stops token issuance; three Conditional Access block policies for all agent identities, agents’ user accounts and users signing in to agents, report-only first, Entra ID P1; consequences for running agents, Microsoft experiences and multitenant blueprints; audit events logged under the base identity types with agentType), https://learn.microsoft.com/entra/agent-id/disable-agent-identities (accessed Nov 11, 2026).

95. Microsoft Learn, “Microsoft Entra releases and announcements,” April 2026 (General Availability, Microsoft Entra Agent ID platform) and June 2026 (Public Preview, Extended Conditional Access protections for agent’s user accounts), https://learn.microsoft.com/entra/fundamentals/whats-new (accessed Oct 22, 2026).

96. Microsoft Learn, “Create an agent identity blueprint,” Prerequisites and Configure credentials for the agent identity blueprint, https://learn.microsoft.com/entra/agent-id/create-blueprint (accessed Oct 22, 2026).

97. Microsoft Learn, “Microsoft Agent 365” service description, Feature availability (including the GCC Availability column and the FedRAMP High note), https://learn.microsoft.com/office365/servicedescriptions/microsoft-agent-365/microsoft-agent-365 (accessed Oct 22, 2026).

98. Microsoft Learn, “Frequently asked questions about Microsoft Entra Workload ID,” https://learn.microsoft.com/entra/workload-id/workload-identities-faqs (accessed Oct 22, 2026).

99. Microsoft Learn, “Target agents in Microsoft Entra Conditional Access policies,” Assignments, Conditions and Access controls, https://learn.microsoft.com/entra/identity/conditional-access/howto-target-agent-identities (accessed Oct 22, 2026).

100. Microsoft Learn, “Microsoft Agent 365” service description, Feature availability (including the GCC Availability column and the FedRAMP High note), https://learn.microsoft.com/office365/servicedescriptions/microsoft-agent-365/microsoft-agent-365 (accessed Oct 22, 2026).

101. Microsoft Learn, “Target agents in Microsoft Entra Conditional Access policies,” Assignments, Conditions and Access controls, https://learn.microsoft.com/entra/identity/conditional-access/howto-target-agent-identities (accessed Oct 22, 2026).

102. Microsoft Learn, “Secure autonomous agents with Conditional Access,” Prerequisites, Allow only specific agents to access resources and Block high-risk agent identities, https://learn.microsoft.com/entra/identity/conditional-access/policy-autonomous-agents (accessed Oct 22, 2026).

103. Microsoft Learn, “Manage agent identities in your organization,” roles table and ID Protection note, https://learn.microsoft.com/entra/agent-id/manage-agent-identities-admin (accessed Oct 22, 2026).

104. Microsoft Learn, “Microsoft Agent 365” service description, Feature availability (including the GCC Availability column and the FedRAMP High note), https://learn.microsoft.com/office365/servicedescriptions/microsoft-agent-365/microsoft-agent-365 (accessed Oct 22, 2026).

105. Microsoft Learn, “Microsoft Entra Conditional Access for workload identities,” https://learn.microsoft.com/entra/identity/conditional-access/workload-identity (accessed Oct 22, 2026).

106. Microsoft Learn, “Frequently asked questions about Microsoft Entra Workload ID,” https://learn.microsoft.com/entra/workload-id/workload-identities-faqs (accessed Oct 22, 2026).

107. Microsoft Learn, “Manage plugins, skills, and MCP servers,” Review and approve MCP requests, https://learn.microsoft.com/microsoft-365/admin/manage/manage-plugins-skills-mcp-servers (accessed Oct 22, 2026).

108. Microsoft Learn, “Microsoft Agent 365” service description, Feature availability (including the GCC Availability column and the FedRAMP High note), https://learn.microsoft.com/office365/servicedescriptions/microsoft-agent-365/microsoft-agent-365 (accessed Oct 22, 2026).

109. Microsoft Learn, “Govern tools with Microsoft Agent 365 and Azure API Management (preview),” https://learn.microsoft.com/azure/api-management/agent-365 (accessed Oct 22, 2026).

110. Microsoft Learn, “Manage Tools Gateway,” https://learn.microsoft.com/microsoft-365/admin/manage/manage-tools-gateway (accessed Oct 22, 2026).

111. Microsoft Learn, “Microsoft Agent 365” service description, Feature availability (including the GCC Availability column and the FedRAMP High note), https://learn.microsoft.com/office365/servicedescriptions/microsoft-agent-365/microsoft-agent-365 (accessed Oct 22, 2026).

112. Microsoft Learn, “Protect enterprise generative AI applications with prompt injection protection,” Prerequisites, Generative AI models and Known limitations, https://learn.microsoft.com/entra/global-secure-access/how-to-ai-prompt-injection-protection (accessed Nov 9, 2026).

113. Microsoft Learn, “Known limitations for Global Secure Access,” section “Global Secure Access In Government Cloud limitations,” https://learn.microsoft.com/entra/global-secure-access/reference-current-known-limitations (accessed Nov 9, 2026).

114. Microsoft Learn, “Known limitations for Global Secure Access,” section “Global Secure Access In Government Cloud limitations,” https://learn.microsoft.com/entra/global-secure-access/reference-current-known-limitations (accessed Nov 9, 2026).

115. Microsoft Learn, “Configure Global Secure Access MCP firewall to secure MCP traffic (preview),” Supported scenarios, Prerequisites, Example 2 and Known limitations, https://learn.microsoft.com/entra/global-secure-access/how-to-configure-mcp-firewall (accessed Nov 9, 2026).

116. Microsoft Learn, “Learn about Secure Web And AI Gateway for Microsoft Copilot Studio agents,” https://learn.microsoft.com/entra/global-secure-access/concept-secure-web-ai-gateway-agents (accessed Nov 9, 2026).

117. Microsoft Learn, “Microsoft Agent 365” service description, Feature availability (including the GCC Availability column and the FedRAMP High note), https://learn.microsoft.com/office365/servicedescriptions/microsoft-agent-365/microsoft-agent-365 (accessed Oct 22, 2026).

118. Microsoft Learn, “Microsoft Agent 365” service description, Feature availability (including the GCC Availability column and the FedRAMP High note), https://learn.microsoft.com/office365/servicedescriptions/microsoft-agent-365/microsoft-agent-365 (accessed Oct 22, 2026).

119. Microsoft Learn, “Configure the Agent 365 CLI for US Government clouds,” https://learn.microsoft.com/microsoft-agent-365/developer/configure-cloud-endpoints (accessed Oct 22, 2026).

120. Microsoft Learn, “Authorization in Microsoft Entra Agent ID,” sections Microsoft Entra role assignments for agent identities, Microsoft Entra roles allowed for agents, Microsoft Graph permissions for agent IDs and When to use Azure roles, Microsoft Entra roles, or Microsoft Graph permissions, https://learn.microsoft.com/entra/agent-id/authorization-agent-id (accessed Oct 22, 2026).

121. CyberArk, 26.1, “System requirements,” supported applications (F5 BIG-IP LTM Advanced, NetScaler, Palo Alto NGFW, Apache/PEM, Java keystores, PKCS#12, Azure Key Vault, AWS and others) and the Server Agent, https://docs.venafi.com/Docs/current/TopNav/Content/Install/r-install-SysReq-ALLVenProducts.php (accessed Oct 23, 2026).