Agentic identity governance expands across AWS AgentCore and Foundry

At a glance

What this is: PlainID expanded its agentic security and authorization coverage to AWS AgentCore and Microsoft Foundry, aiming to standardise visibility and policy enforcement across more enterprise agent environments.

Why it matters: IAM and security teams need a governance model that keeps agent authorization consistent across platforms, because agent sprawl quickly turns visibility gaps into control gaps.

👉 Read PlainID's analysis of agentic identity governance across AWS AgentCore and Microsoft Foundry

Context

Agentic identity governance is the problem of deciding what an AI agent can see, call, and change across the systems it touches. As agent deployments move from pilots into production, the hard part is no longer agent creation but consistent authorization across data, MCP tools, and downstream actions.

The article argues that native platform guardrails are not enough once an agent reaches into internal enterprise systems or other cloud environments. That is the governance gap: an agentic estate can be technically present, yet still lack a coherent control plane for discovery, profile context, and runtime policy enforcement.

Key questions

Q: How should enterprises govern AI agents across multiple clouds and SaaS platforms?

A: Enterprises should treat AI agents as distributed NHIs and govern them with a unified model for discovery, ownership, secrets, and policy enforcement across every runtime they touch. The hard part is not defining the control model but applying it consistently across heterogeneous environments, and the implementation patterns vary by stack. The NHI Lifecycle Management Guide covers the operational side in more detail.

Q: Why do native agent controls fall short once an AI agent reaches other systems?

A: Native controls are usually scoped to one platform, so they stop being authoritative when an agent calls into internal enterprise systems, external tools, or another cloud. That creates a policy seam where access can drift even though each platform appears secure in isolation.

Q: Should IAM teams be involved in AI agent governance from the start?

A: Yes, because AI agents inherit access, secrets, and revocation problems that are already IAM concerns. IAM teams should define entitlement boundaries, session scope, audit expectations, and offboarding rules before the first production rollout. If those controls are deferred, the programme will scale faster than it can be governed.

Q: What is the difference between platform-native guardrails and independent authorization for agents?

A: Platform-native guardrails protect actions inside one vendor environment, while independent authorization governs the agent across environments. The first is perimeter control, the second is a portable policy model that stays effective when the agent crosses into other systems or cloud boundaries.

How it works in practice

Why independent authorization matters for agentic platforms

Agentic platforms often provide internal controls, but those controls rarely govern cross-boundary access with the same policy model once an agent reaches enterprise data, tools, or external systems. An independent authorization layer separates identity governance from the execution platform, so the policy decision follows the agent rather than being trapped inside one cloud or workflow boundary. That matters when agents are heterogeneous and move between products, environments, and data domains.

Practical implication: Treat platform-native guardrails as local controls and design a separate authorization layer for cross-environment agent decisions.

Why agent discovery and profile enrichment are governance controls

Discovery tells you which agents exist. Profile enrichment adds the context needed to govern them, including business function, connected resources, and policy scope. Without those two steps, governance becomes reactive because teams cannot answer basic questions about ownership, access paths, or blast radius. For agentic AI, inventory is not a reporting exercise. It is the prerequisite for authorization, policy segmentation, and lifecycle control.

Practical implication: Build an authoritative agent inventory before you attempt policy enforcement or recertification for agentic workloads.

How consistent enforcement works across data, tools, and actions

In agentic environments, authorization must be evaluated at runtime across multiple decision points: data access, tool invocation, and the action the agent is about to execute. That is different from a one-time login control because the agent may chain decisions across several systems in one task. Consistent enforcement means the same policy intent is applied regardless of whether the agent is touching a dataset, calling an MCP tool, or triggering an operational action.

Practical implication: Map agent policies to each decision point so data access, tool use, and action execution cannot drift apart.

NHI Mgmt Group analysis

Agentic identity governance is becoming a control-plane problem, not a product feature problem. Once enterprises deploy agents across multiple platforms, the decisive issue is whether authorization follows the agent across systems. Platform-native guardrails can help locally, but they do not solve governance once the agent crosses into enterprise data or another cloud boundary. Practitioners should evaluate agent governance as an independent policy layer, not as an extension of whichever platform built the agent.

Inventory is now a governance control, not a discovery luxury. The article’s emphasis on registry, discovery, and enrichment reflects a deeper truth: you cannot govern what you cannot reliably enumerate. For agentic estates, missing inventory means missing ownership, unclear context, and no defensible policy boundary. That is why agent registration and enrichment should be treated as prerequisite controls for runtime authorization, not as optional operational metadata.

Independent authorization is the named concept this market is converging on. The governance requirement is no longer just access control, but an independent authorization layer that can secure agentic flows across AWS, Microsoft, and internal systems. That concept matters because enterprise risk now sits in the seams between platforms, where native controls stop and policy consistency breaks. Practitioners should assume agent environments will remain heterogeneous and design for that reality from the start.

Agentic policy consistency will matter more than platform completeness. Enterprises will increasingly compare controls on whether they can enforce one authorization model across many agent runtimes, not on whether a single platform can secure its own perimeter. That shifts buying and architecture decisions toward governance that survives platform change. The practical conclusion is simple: if the control model cannot travel with the agent, it will not scale with the programme.

Zero Standing Privilege remains the right directional model, but agentic governance is broader than just ephemeral access. PlainID’s framing shows that real control also depends on knowing the agent’s context, connected resources, and action scope. In practice, the challenge is not only issuing access on demand. It is maintaining runtime authorization that keeps pace with the agent’s changing context and environment.

From our research library:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• Read next: Agentic AI Identity Guide

What this signals

Independent authorization is becoming the default architecture for agent governance. As agent estates spread across clouds and internal systems, the programme question shifts from whether a platform can secure its own agents to whether policy can travel with the agent across boundaries. That requires ownership, context, and enforcement to be treated as one control surface, not three separate projects.

Service-account-style governance breaks down if teams treat agents as static assets. The operational reality is closer to living identity management: agents appear, change context, and connect to new resources faster than many review cycles can keep up. Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs, which is a warning sign for any team extending governance to agents.

For practitioners

• Define an independent authorization layer Separate policy decisions from any single agent platform so authorization can be applied consistently across AWS AgentCore, Microsoft Foundry, internal systems, data, and tools.
• Inventory and classify every agent Create a live registry that captures ownership, platform, connected resources, and policy scope for each agent before production rollout.
• Enrich agent profiles with business context Attach business purpose, data sensitivity, and tool relationships to each agent record so policy decisions are based on context rather than platform labels.
• Enforce policy at each decision point Apply authorization checks separately to data access, MCP tool use, and agent actions so one allowed step does not implicitly authorise the next.
• Review cross-platform control gaps Test whether your current governance model still works when an agent moves between cloud boundaries or reaches into internal systems that the original platform does not control.

Key takeaways

• Agentic AI governance now depends on consistent authorization across platforms, not just on securing a single agent runtime.
• Discovery, enrichment, and enforcement are linked controls, because teams cannot govern agents they cannot enumerate or contextualise.
• The practical test is whether policy still holds when agents cross cloud boundaries, call tools, and trigger actions in one workflow.

Key terms

• Independent authorization layer: A policy layer that makes access decisions outside the agent platform itself. In agentic environments, this reduces reliance on native guardrails alone and lets the enterprise apply consistent controls across data, tools, APIs, and actions.
• Agent Registry: An agent registry is a central catalog of sanctioned and shadow AI agents, including their identities, permissions, and lifecycle state. Its value depends on whether it feeds broader governance, because a registry without telemetry, ownership, and offboarding can become another silo.
• Profile Enrichment: Profile enrichment adds business and security context to an agent record, such as owner, sensitivity, and connected resources. It turns a technical identifier into a governable identity object that policy engines can use for runtime decisions.
• Runtime Authorisation: Runtime authorisation is the practice of deciding access while a task is in progress, rather than only at provisioning time. It matters for NHIs because credentials and entitlements can change risk mid-session, especially when automation or AI agents interact with sensitive systems.

What's in the full announcement

PlainID's full article covers the operational detail this post intentionally leaves for the source:

• Expanded platform coverage details for AWS AgentCore and Microsoft Foundry support
• The vendor's description of how registry, discovery, enrichment, management, and enforcement fit together
• PlainID's framing of independent authorization across AWS, Microsoft, and internal systems
• The specific enterprise use cases the article says benefit from broader agent coverage

👉 The full PlainID article covers the expanded agent registry, discovery, enrichment, management, and enforcement scope.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.