The overdue consolidation of identity, governance, security, and compliance

You have good reasons for running more than one identity provider: acquisitions, incomplete migrations, and applications that still work. Those reasons explain your estate; they do not justify making its fragmentation the security architecture of your AI agents. Your agentic systems need one identity provider, one authoritative policy and governance engine, and a governed gateway approach for the workloads you cannot yet bring into that model.

That is the case for consolidation. Not because a single sign-in experience is more convenient, and not because the next platform promises a better administration portal. The decision is about who has the authority to grant an agent access, under which policy, for how long, and with whose accountability.

You do not need to finish every historical migration before applying that principle. Where a legacy or acquired application exposes a supported API, publish its selected operations as governed Model Context Protocol (MCP) tools behind an AI gateway instead of teaching the agent to authenticate against the application's identity provider. Azure API Management's AI gateway capabilities include exposing existing APIs as MCP servers, making that a concrete integration option rather than another identity exception.

This is not a novel direction disguised as an AI requirement. Microsoft's guidance for the Cybersecurity and Infrastructure Security Agency (CISA) Zero Trust identity pillar already recommends consolidating identity providers, identity stores, and identity management systems. Its discussion of federal requirements has a specific governmental scope; the architectural recommendation here is broader, and it is a position you should choose deliberately rather than mistake for a universal legal mandate.

A working sign-in is not a coherent security strategy

Consider a hypothetical procurement agent that reads invoices and prepares a reconciliation for a human reviewer. Its identity belongs to your chosen enterprise provider, but an acquired company's invoice application still lives in another identity domain. The application works, the migration has slipped twice, and the integration team knows how to provision a local account.

The immediate proposal is reasonable on its own terms. Teach the agent or its connector to authenticate against the acquired application's provider, assign the local read permission, and let it retrieve the invoices. The demonstration succeeds, the business requirement is met, and the migration remains somebody else's project.

What exactly has that successful demonstration established?

It has established a working access path. It has not established that the agent's purpose, the connector's account, the local permission, and the approval that justified access belong to the same governed lifecycle. Those relationships are the part of the design that still needs a decision.

Microsoft's AI Gateway overview provides a different integration direction: shared tool endpoints with application credentials separated from backend credentials. Keep the retained identity provider behind that boundary rather than making it part of every agent's identity configuration. The backend authorization relationship still needs governance, but it does not need to become another direct identity relationship for the agent.

Now let the procurement project end. If access approval exists in one system, the connector account in another, and permission ownership in a third, somebody must know that the original business decision has expired and translate that fact into each place that still grants access. Your architecture needs to identify who does that translation and what evidence proves it happened.

Calling this federation does not settle the question. Federation can be part of a legitimate integration, but an accepted identity is not evidence that access ownership, permission expiry, and operational responsibility have become unified. Microsoft's identity-pillar maturity guidance treats identity stores, access management, visibility, and governance as separate concerns precisely because successful authentication is not the whole problem.

The migration backlog is therefore not merely an inconvenience to work around. In this example, it is the reason the agent can acquire access through two independently administered lifecycles. If you accept the connector without resolving that relationship, you have made the old fragmentation part of the new system's security design.

That is the decision worth challenging. The question is not whether the connector can authenticate. It is whether the organization can explain, maintain, and withdraw the authority behind the action it enables.

One identity provider gives agent access a common authority

The case for one identity provider starts with a common reference point. Every organization-controlled agent should have an identity whose accountable owner, intended purpose, and access relationships can be governed in the chosen identity domain. Microsoft's agent identity governance model provides a concrete example: agents have identities, access rights, and human sponsors responsible for lifecycle and access decisions.

The benefit is not that every agent receives the same treatment. The procurement agent and a production remediation agent should have different permissions and different constraints. The benefit is that those differences are expressed within an authority you have selected and can hold accountable, rather than emerging from whichever authentication mechanism each integration happened to support.

One provider does not mean one principal. It means one place to establish the agent's identity and the policy under which it enters your governed environment. Distinct agent identities and access rights remain necessary; the documented Entra agent model explicitly supports distinct identities with distinct access.

This changes the procurement discussion. The acquired application's authentication scheme is no longer allowed to determine how the agent itself is governed. It becomes a constraint on the workload integration, to be addressed without creating another independent identity lifecycle for the agent.

Notice the scope of that position. Your organization controls its agents and the conditions under which they use its governed tool surface. You do not suddenly control every partner directory or every backend identity authority, and the gateway authorization scenarios do not require you to pretend otherwise.

There is a temptation to call a common product name sufficient consolidation. It is not sufficient for this policy. If the deployment still leaves unrelated authorities deciding who an agent is, who may approve its access, and who must retire it, the governance problem remains even when the administration portals look familiar.

Define the chosen authority concretely: the identity domain, the responsible operating team, the accepted issuers, and the process for introducing agents. At the API boundary, make that choice real through documented token-validation constraints rather than a statement of intent. Azure API Management's Entra token-validation policy, for example, exposes tenant, audience, caller, and required-claim controls.

The procurement agent's entry into that environment should therefore be a consequence of the enterprise's identity decision, not a negotiation reopened for each connector. A workload can require a different backend integration. It does not get to select a different security strategy for the agent that needs it.

The choice also creates a more useful migration priority than a general instruction to consolidate someday. A workload becomes relevant when an agent needs access to it, and that request creates a concrete occasion to reassess its identity integration. You can make progress against the old estate without making completion of the old estate a prerequisite for governing the new one.

There is a concentration of responsibility here, and it should be explicit. The selected identity platform becomes a dependency whose privileged administration, change process, availability, and recovery deserve architectural attention. Consolidation is not an excuse to leave that control plane underprotected; distributing the responsibility across several authorities is not a substitute for protecting it either.

The architectural rule is straightforward: choose the agent's identity authority once. Resolve workload diversity at the integration boundary rather than allowing every workload to reopen that choice.

One policy and governance engine makes that authority accountable

A common identity provider is necessary for this strategy. It is not sufficient. You can centralize authentication and still leave access approvals in project tickets, expiry in spreadsheets, and decommissioning in the memory of the person who configured the connector.

That is why the recommendation includes one authoritative policy and governance engine for agent access. It must connect the business justification for access to the identity receiving it, the resources it covers, the conditions under which it is used, and the event that ends it. Without that connection, the provider has become a common login service for a fragmented permission estate.

The word engine matters, but it does not mean every decision runs in one process. It means there is one authoritative system of policy and access lifecycle to which agent integrations conform. Resource-specific enforcement can remain distributed without allowing each resource integration to invent an unrelated grant, review, and retirement process.

With independent governance engines, the procurement decision has to be represented more than once. Each representation must refer to the correct principal, the same approved operation, and the same business event that ends access. For this architecture, keeping those representations equivalent is an obligation you have created, not a property you can assume because the systems exchange identity information.

The cost is therefore not merely an extra administration screen. If the reconciliation closes and only one representation of its authorization ends, the design still contains an access path that no longer corresponds to the business decision. One authoritative engine gives you a single decision to propagate and verify, instead of several independent grants whose continuing agreement becomes another integration project.

Microsoft's own separation of concerns is useful here. Conditional Access is its Zero Trust policy engine, combining signals to make and enforce access decisions. Agent identity governance addresses a different set of questions through sponsorship, access assignments, request pathways, and expiry.

Those capabilities should serve a common authority; they are not interchangeable features. An approval does not answer every runtime access question, and a successful runtime policy evaluation does not establish an enduring business justification. The Conditional Access overview labels agent targeting as preview, while the governance documentation specifies licensing prerequisites, indicating still evolving capabilities.

For the procurement agent, the governance decision begins with the purpose: read the invoice data needed for reconciliation. Somebody accountable approves that purpose and the access it requires. The permitted action, its resource boundary, and its duration should then remain recognizable as that same decision when the integration team implements the connection.

An illustrative architecture-review contract could capture that relationship without pretending to be an executable product schema:

agent_access:
  identity_authority: chosen-enterprise-provider
  accountable_sponsor: procurement-operations
  resource: acquired-invoice-api
  permitted_action: read-invoices
  grant_and_expiry: central-governance-record
  enforcement: approved-gateway-and-backend
  evidence: linked-approval-and-access-events

The value is not the format. The value is that the resource, permitted action, accountable person, expiry, and enforcement path belong to one reviewable contract. If a team cannot explain how those fields correspond to the implementation, the integration is not ready merely because the request succeeds.

There are concrete mechanisms for parts of this lifecycle. The agent governance documentation describes access-package requests by agents, sponsors, or administrators, followed by configured approval and assignment expiry. As argued in Access packages are the control plane for Entra Agent ID permissions, the important architectural shift is to make permission acquisition a governed process rather than a collection of direct assignments.

Do not extend that mechanism beyond its actual scope. An expiring assignment in the chosen platform is not, by itself, a lifecycle implementation for an unrelated backend account. The separate backend authentication relationship documented by API Management still needs an explicit connection to the governance decision.

This is also where compliance stops being a word appended to a security diagram. For this integration, your control objective should be to demonstrate that access was justified, implemented within its approved boundary, reviewed as required, and retired through an accountable process. A successful sign-in answers only part of that inquiry.

Evidence therefore belongs in the design, not in a reporting project commissioned after rollout. API Management's security guidance describes gateway logging, security monitoring, and configuration governance, but those facilities still require you to decide what to collect and how to relate it to access approvals. A log destination is not the same thing as an evidenced control process.

The point of consolidation is that the procurement sponsor should not need to understand several unrelated permission lifecycles to withdraw one business authorization. One authoritative governance decision must have a defined effect on the entire access path. Otherwise you have consolidated the sign-in and left the standing privilege behind.

The gateway is an enforcement point, not another authority

The gateway brings agentic resources under one governed roof and bridges the identity domains behind them. As argued in Your API gateway is not an identity provider, and promoting it to one is a liability, it must not become another identity provider. The agent's identity authority stays fixed; backend diversity becomes an integration concern rather than a new identity strategy for each agent.

Microsoft's AI Gateway (preview) brings model connections and MCP tools into a shared control surface; Azure API Management's AI gateway capabilities include exposing existing API operations as MCP servers and proxying existing MCP servers. The dedicated product and API Management capabilities are different offerings, so do not infer identical features from the gateway name.

The Microsoft Agent 365 integration (preview) makes the governance relationship explicit: Agent 365 supplies inventory and governance intent; the gateway enforces controls on MCP traffic. Its support table distinguishes server-level controls in API Management v2 from tool-level controls in the AI Gateway tier, which require a static allowed-tool list.

For the procurement agent, the gateway in this diagram is its MCP endpoint. The invoice application's existing identity authority stays on the backend side of that boundary.

flowchart LR
    subgraph AgentDomain["Governed agent domain"]
        I["Chosen identity provider"]
        A["Procurement agent"]
        G["Approved gateway"]
    end
    subgraph WorkloadDomain["Retained workload domain"]
        B["Backend identity authority"]
        W["Invoice API"]
    end
    E["Correlated audit evidence"]
    I -->|"Agent token"| A
    A -->|"Token for gateway resource"| G
    B -->|"Configured backend credential"| G
    G -->|"Authorized backend call"| W
    I -.-> E
    G -.-> E
    W -.-> E

The bridge is a configured backend authentication relationship, not a new identity issuer or an automatic transfer of the agent's permissions. API Management's authorization model separates frontend access from backend credentials; use that separation to expose the approved invoice-reading tool without making the agent a client of the legacy provider.

Discovery is not routing. Agent 365 does not automatically route agents through the gateway: the developer must configure its MCP endpoint and restrict direct access to the underlying server. The diagram's evidence links are also requirements to implement, not automatic correlation.

The architectural goal is one governed tool surface, not one physical gateway instance. Make the existing identity domains a backend integration responsibility, not permission to proliferate agent identities and policy engines.

A second identity domain is a consolidation decision

Return to the acquired invoice application. Its presence in another identity domain is real, and the procurement requirement does not make the old migration obstacles vanish. It does, however, create a decision point with a named consumer, a bounded resource requirement, and a reason to revisit the status quo.

The first question should be whether the workload's identity integration can move to the chosen provider. Do not equate that assessment with moving all of its data or rewriting the application. The proposal is to bring its identity and access relationship into the selected governance model; Microsoft's identity-store consolidation guidance places application integration and migration within that broader direction.

If the workload can make that move, evaluate the remaining access model rather than declaring the job finished at single sign-on. The procurement agent's approved read access still needs an accountable grant, appropriate enforcement, and a lifecycle. Changing the identity integration is valuable because it can simplify those relationships, not because a new login screen is the objective.

The recurring objections deserve a concrete answer. If the reason to postpone migration is that the application already works, the new agent requirement has changed what you are asking it to work within. You are no longer evaluating an isolated legacy application; you are deciding whether its access model is suitable for the governed agentic system now being built.

There will still be workloads that cannot move now. Their operators may be outside your organizational control, or their integration constraints may make an immediate change disproportionate. Your identity strategy should account for that reality without allowing it to become permission for the agent to accumulate another independently governed credential.

The second path is to retain the workload in its current domain and publish the approved operation as an MCP server tool behind the established AI gateway. The existing-API-to-MCP capability gives this decision a concrete implementation path. The agent calls the governed MCP endpoint; the gateway's backend integration deals with the legacy identity provider.

For the procurement case, publish the invoice-reading tool, not a general-purpose tunnel into the acquired application. Do not start by asking how the agent can sign in to that application's provider. Start by asking which business operation should become an approved tool, who can invoke it, and how the gateway's backend access remains within that decision.

This decision does not remove the data owner's responsibilities. Resource-specific authorization and data restrictions still need enforcement; the frontend/backend authorization distinction does not make the frontend decision a replacement for every backend check. What changes is that the agent's access must enter through an approved governance relationship rather than an unrelated local onboarding process.

The workload integration also needs a retirement path before it needs a production launch. If the central grant ends, the design must identify what prevents continued use of the retained backend relationship for that agent's purpose. A reusable gateway credential may support other approved consumers, so its existence and the procurement agent's authorization cannot be treated as the same thing.

There is a third outcome, although it is not a third integration pattern: the workload is not ready for agent access. If neither migration nor a safe, governed gateway path is feasible, the correct decision is to withhold onboarding until the architecture changes. A deadline does not make an ungovernable permission relationship conform to the policy.

This is the discipline behind the single-provider position. It does not deny the existence of other security domains. It prevents their existence from becoming an automatic exception to the identity and governance strategy of your agentic systems.

Enforce the strategy before the next agent goes live

The recommendation needs an accountable decision, not another statement in a reference architecture. Establish the selected identity provider and the policy and governance engine for agentic access, then make new integrations demonstrate how they conform. Otherwise the first connector that encounters friction will turn the strategy back into an aspiration.

For the procurement agent, the review should follow the business authorization all the way to the invoice operation. The sponsor's approval, the agent identity, the governed grant, the MCP tool permission, and the backend authority should form an explainable relationship. If that relationship breaks at a credential maintained outside the lifecycle, the review has found a design gap, not an administrative detail to defer.

That does not require the architecture board to configure every permission. It requires the board to insist that somebody can show where authority originates, where it is enforced, and how it ends. The implementation teams can then choose supported mechanisms within the identity governance and gateway security capabilities available to them.

Verification should test the claim the architecture makes. A consumer outside the approved identity and permission boundary must not be able to invoke the invoice tool, and an unavailable tool must not remain reachable through a direct endpoint. For deployments using Microsoft Agent 365's documented gateway controls, test server blocking and any supported tool-level blocking rather than treating inventory registration as enforcement.

The lifecycle test matters just as much. End the procurement authorization and establish what happens to subsequent requests, existing credentials, and retained backend access. Do not accept the word "revoked" as a substitute for documented behavior across the two authorization relationships described in API Management's model.

Your compliance evidence should be able to follow that same sequence. Logging and configuration-governance facilities support an investigation only when the implementation records the relevant decisions and you have defined their ownership and retention. Consolidation is not a certificate of compliance, and it does not remove the need to protect the underlying data.

This is not a promise that one identity platform solves every AI security problem. It is a refusal to add agent access while leaving the authority behind it fragmented and unexplained. That is a security decision you can make before the remaining technology decisions have become expensive commitments.

The old estate will continue to impose constraints. Your next agent does not need to inherit those constraints as its governing policy. Choose one identity authority and one policy and governance engine, then require every workload integration to respect that choice.

References

• Microsoft guidance for the CISA Zero Trust identity pillar
• What is Conditional Access?
• Governing agent identities
• Authentication and authorization to APIs in Azure API Management
• Validate Microsoft Entra tokens in Azure API Management
• Secure your Azure API Management deployment
• Govern tools with Microsoft Agent 365 and Azure API Management (preview)
• What is AI Gateway?
• AI gateway capabilities in Azure API Management
• Access packages are the control plane for Entra Agent ID permissions
• Your API gateway is not an identity provider, and promoting it to one is a liability