AgentCore Identity, part of AWS's AgentCore suite for deploying, scaling, and securing AI agents, reached general availability in October 2025. It is built on Amazon Cognito, AWS's existing identity service, extended with capabilities aimed specifically at agent workloads rather than human or conventional application authentication. For agents built on Bedrock and operating primarily against AWS-native resources, this is a serious, first-party answer to the question of how an agent proves who it is and what it can access. The more interesting question for most enterprises is not whether AWS solved agent identity within its own estate — by the public record, it did — but what AgentCore Identity does and does not cover once agents, models, and tools span more than one cloud.

What AgentCore Identity covers

Building agent identity on Cognito rather than inventing a parallel system is a deliberate choice: it means agent identities inherit the operational maturity of a service AWS customers already run for user authentication, rather than asking teams to adopt an entirely new identity primitive for agents specifically. The AgentCore suite is designed around the operational lifecycle an agent goes through — being deployed, scaled, and run against real resources — and Identity is the component of that suite responsible for the authentication and authorization layer specifically.

A documented integration point worth calling out directly: AgentCore Identity can be paired with Azure Entra ID as a shared identity provider, using OAuth 2.0, for AgentCore's Runtime components. That is a meaningfully different posture from a fully closed, AWS-only identity model — it gives organizations already standardized on Entra ID a supported path to keep a single identity provider of record even when the agent workload itself runs on AWS infrastructure. For any organization already running a hybrid AWS-plus-Microsoft estate, this integration point is worth evaluating directly rather than assuming AgentCore Identity requires abandoning an existing Entra-centric identity strategy.

It is worth placing AgentCore Identity in the broader identity taxonomy rather than treating it as a category of one. It sits alongside the general concepts covered in machine identity vs. workload identity vs. agent identity: AgentCore Identity is AWS's concrete, product-level implementation of agent identity specifically, layered on top of the same workload-identity foundations (Cognito, in this case) that AWS already offers for non-agent service-to-service authentication.

Where AWS-native coverage is a legitimate, sufficient answer

If your agent population is built on Bedrock, deployed through AgentCore, and calls AWS-native resources — S3, DynamoDB, Lambda, other Bedrock-hosted models — AgentCore Identity is a reasonable default rather than a gap to fill with something else. You get agent identity backed by a mature identity service, a supported integration path to Entra ID if that is your workforce identity provider, and an authentication layer that is maintained and evolved as part of the same suite you use to run the agents themselves. Building a parallel, independent identity layer for a genuinely single-cloud AWS estate adds operational overhead without a corresponding governance gain, in the same way that a Microsoft-only shop is usually well served by Microsoft's own agent governance stack rather than an additional identity layer on top of it.

Where the cross-cloud boundary bites

The honest limitation, based on the public record, is at the boundary between clouds. Reporting on Microsoft's Agent 365 integration model shows that AWS AgentCore agents and Google Gemini Enterprise agents currently integrate with Agent 365 only through registry synchronization, in public preview — meaning Agent 365 can know that an AWS AgentCore agent exists and hold a record of it, but there is no cross-cloud runtime policy enforcement between the platforms. An agent's actual behavior at runtime is governed by whichever platform it runs on; a unified enforcement point spanning AWS, Azure, and Google Cloud agent runtimes does not yet exist as a first-party capability from any single hyperscaler.

This matters concretely for any organization running agents on more than one cloud, which is the common case rather than the exception once an enterprise has grown through acquisitions, multiple product lines, or simply different teams choosing different platforms. Registry visibility — knowing an agent exists — is not the same as policy enforcement — controlling what that agent is authorized to do at the moment it acts. The gap between those two is exactly where governance risk accumulates silently, because a registry entry can create a false sense that the agent is covered when only its existence, not its behavior, is visible centrally.

A short checklist for evaluating your own exposure

  1. Map which of your agents run entirely within AWS versus which touch other clouds, models, or SaaS platforms. AgentCore Identity's direct coverage is strongest for the first group and does not extend runtime enforcement to the second.
  2. Check whether your organization's identity provider of record is Entra ID, Okta, or something else, and confirm whether AgentCore's documented integration paths for that provider meet your requirements — the Entra ID via OAuth 2.0 path is documented; verify current support for other providers against AWS's own documentation before assuming parity.
  3. Identify your third-party MCP server population. Tool access governed through MCP servers your agents call is a distinct control surface from AWS resource access, and AWS-native identity does not automatically extend policy enforcement to every MCP server an agent connects to. MCP server vetting and registry risk covers that population specifically.
  4. Decide where a single audit trail matters most. If auditors, regulators, or incident responders need one coherent record of agent activity across AWS and non-AWS systems, per-cloud identity logging alone will not produce that; it will produce fragments that need to be manually reconciled.
  5. Check data residency requirements against where AgentCore Identity and its dependent AWS services actually run. Data residency for AI agents covers why this is a separate question from authentication coverage, particularly for regulated workloads.
  6. Revisit this evaluation as your cloud footprint changes, not as a one-time decision — a single-cloud AWS estate today can become multi-cloud after the next acquisition or platform migration, and identity coverage that was sufficient can quietly stop being so. Cross-org agent federation and trust manifests covers the pattern for extending trust across organizational and, by extension, cloud boundaries deliberately rather than by accident.

The identity and access for AI guide covers the broader set of controls this evaluation sits inside, including credential lifecycle and cross-org federation, which matter regardless of which cloud or identity provider you standardize on.

The realistic pattern for multi-cloud estates

The pattern here mirrors what shows up across every hyperscaler's agent identity offering: strong, well-engineered coverage within that vendor's own estate, and an honest, currently unresolved gap at the boundary where clouds meet. Okta for AI Agents shows the same shape from an identity-provider angle rather than a cloud-platform angle — deep coverage for what registers through it, an open question for what does not. For organizations with agents genuinely confined to one cloud and one identity provider, platform-native tooling is very likely sufficient. For organizations with agents spanning AWS, Azure, Google Cloud, and third-party MCP servers — which describes most enterprises past a certain size — a governance layer that is not anchored to any single cloud's identity boundary is what closes the registry-visibility-without-enforcement gap described above. What is an AI control plane covers what that category of tooling generally provides.

Praesidia is an AI agent security and governance control plane covering agent identity and access, guardrails, audit evidence, and cost controls across agents regardless of which cloud or identity provider they run on.

Common questions

Do I need a third-party identity layer if I only run agents on AWS? If your entire agent population runs on Bedrock and AgentCore against AWS-native resources, AgentCore Identity is very likely a sufficient, well-supported answer on its own. The evaluation changes the moment agents, models, or tools outside AWS enter the picture, which is worth checking honestly rather than assuming.

Is AgentCore Identity the same thing as IAM roles for Bedrock? No. IAM governs AWS resource-level permissions generally; AgentCore Identity is a purpose-built layer for agent authentication and authorization within the AgentCore suite, built on Cognito and extended with agent-specific capabilities, rather than a repurposing of general-purpose IAM roles.

Can AgentCore Identity work alongside Microsoft Entra ID? Yes — AWS documents a supported integration where Entra ID serves as a shared identity provider via OAuth 2.0 for AgentCore's Runtime components, giving organizations with Entra as their identity provider of record a path to extend that to AWS-hosted agents rather than maintaining a fully separate identity system.

Does registry sync with Microsoft Agent 365 mean AWS agents are governed by Microsoft's policies? No. As of the most recent public reporting, that integration is registry synchronization only, in public preview — Agent 365 can maintain a record that an AgentCore agent exists, but runtime policy enforcement on that agent's actual behavior remains with AWS. Do not assume registry visibility implies cross-cloud enforcement; verify current integration depth against both vendors' documentation before relying on it for a compliance claim.

What is the single biggest gap for a multi-cloud enterprise relying only on AgentCore Identity? A unified audit trail and consistent policy enforcement across clouds. Per-cloud identity and logging produce fragments of the picture rather than one coherent record, which becomes a real problem the moment an incident, audit, or regulatory inquiry needs to reconstruct what an agent did across systems that span more than one provider's boundary.