Agentic identity governance expands across AWS AgentCore and Foundry

At a glance

What this is: PlainID’s update extends agentic security and authorization coverage to AWS AgentCore and Microsoft Foundry, with the core finding that enterprise controls must scale across heterogeneous agent environments.

Why it matters: IAM, PAM, and NHI teams need a consistent authorization model for AI agents because visibility, policy enforcement, and access boundaries break down quickly once agents span multiple platforms and internal systems.

👉 Read PlainID's update on expanded AWS AgentCore and Microsoft Foundry support

Context

Agentic identity governance is the problem of controlling what AI agents can access, what they can do, and which systems they can reach as they move across platforms. The gap is not whether agents exist, but whether policy, visibility, and enforcement can follow them consistently across data, MCP tools, and downstream actions.

PlainID’s announcement frames a familiar enterprise failure mode: native platform guardrails are useful inside a cloud boundary, but they do not solve authorization once an agent reaches into internal systems or a second cloud. That makes independent runtime authorization a governance issue, not just a platform feature decision.

Key questions

Q: How should security teams govern AI agents across multiple platforms?

A: Security teams should use a centralized authorization model that inventories agents, enriches them with business context, and enforces policy at runtime across platforms. The key is continuity: when an agent moves between cloud environments or into internal systems, the same governance decision must still apply. Without that, visibility and control fragment quickly.

Q: Why do native cloud guardrails fall short for agentic AI governance?

A: Native guardrails usually stop at the boundary of the cloud or platform they were designed for. That is not enough when an AI agent reaches into internal enterprise systems or a second cloud, because access decisions no longer stay inside one control domain. Independent runtime authorization is needed to keep policy consistent across the full workflow.

Q: What breaks when AI agent discovery is incomplete?

A: When discovery is incomplete, the organisation cannot know which agents exist, what they are connected to, or what they can access. That leaves policy enforcement, enrichment, and review operating on a partial inventory, which is the same as governing only part of the environment. Hidden agents become hidden access paths.

Q: How can IAM teams decide whether agentic authorization is working?

A: IAM teams should look for one decision fabric across data, tools, and actions, with consistent enforcement even when an agent crosses platform boundaries. If policies differ by platform, or if teams cannot explain why a given action was allowed at runtime, the control model is not yet working as intended.

How it works in practice

Agent registry and discovery across agent platforms

Agent registry and discovery are the control plane functions that let security teams identify which agents exist, where they run, and what resources they touch. In practice, this becomes the minimum inventory layer for agentic governance because unmanaged agents create shadow AI risk and hidden access paths. Profile enrichment adds business and security context, which turns a raw agent list into something policy can act on. Without discovery, every downstream control is partially blind.

Practical implication: build a complete agent inventory before you depend on policy enforcement or access reviews.

Runtime authorization for data, MCP tools, and actions

Runtime authorization decides whether an agent may access a resource at the moment of execution, rather than assuming static entitlements are enough. That matters because agent behaviour is contextual, and access often depends on the current task, connected tool, or target data set. When policies are enforced across data, MCP tools, and actions, teams can constrain agent behaviour at the point of decision instead of relying on coarse platform defaults. This is where agentic governance differs from ordinary workload access control.

Practical implication: evaluate whether your policies can be enforced at the action layer, not just at login or provisioning time.

Independent authorization layers in multi-cloud agentic environments

An independent authorization layer separates enterprise policy from any one cloud or agent platform. That architecture matters because native controls stop at boundary lines, while agents increasingly operate across AWS, Microsoft, and internal systems in the same workflow. The governance issue is not only privilege scope, but also policy continuity as the agent moves between environments. A central authorization model gives security teams one decision fabric for heterogeneous ecosystems, which is the only way to keep agent governance coherent at scale.

Practical implication: treat cross-platform agent access as a policy continuity problem and test it against multi-cloud workflows.

NHI Mgmt Group analysis

Agentic authorization cannot rely on platform-native guardrails alone. The article reinforces a structural boundary problem that identity teams already know from NHI governance: controls that work inside one platform often stop at the edge of another. As agents move from cloud-native runtime to internal enterprise systems, the real issue is not whether a guardrail exists, but whether it still applies after the first hop. Practitioners should assume boundary leakage unless policy remains independent of the platform.

Shadow AI becomes an authorization problem before it becomes a discovery problem. If teams cannot see which agents exist, profile enrichment and policy enforcement are already partial. That means discovery is not a housekeeping task, it is the prerequisite for any defensible agent governance programme. The practical conclusion is simple: if the agent inventory is incomplete, the authorization model is incomplete too.

Independent runtime authorization is now the control pattern that matters for agentic AI. The article points to the need for a policy layer that governs what an agent can do as conditions change, rather than relying on static entitlements or cloud-local defaults. This aligns with NIST Cybersecurity Framework and Zero Trust thinking, but applied to AI agent behaviour rather than human sessions. Security teams should treat runtime policy continuity as the central design requirement.

Multi-cloud agent governance is converging on a named concept: policy continuity across agent boundaries. That concept matters because the core failure is not simply too much access, but access decisions that fragment as an agent crosses platforms. Once an agent can operate across AWS, Microsoft, and internal systems, isolated controls no longer describe the true risk surface. Practitioners should organise governance around where policy breaks, not where the agent was first created.

NHI governance and agentic AI governance are collapsing into the same operating model. The same questions now apply across service accounts, tokens, and agents: what exists, what is connected, what is allowed, and what is revocable in real time. The difference is that agent behaviour is more dynamic, so old entitlement assumptions become less durable. Teams need one governance model that spans machine identities and autonomous-like agent flows without pretending they are the same thing.

From our research:

• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to Ultimate Guide to NHIs.
• Our research also shows that 97% of NHIs carry excessive privileges, which broadens the attack surface when governance does not keep pace with deployment.
• For lifecycle detail, the Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs shows why offboarding, rotation, and review must stay aligned.

What this signals

Policy continuity is becoming the decisive operating requirement for agentic AI. As agents spread across cloud platforms and internal systems, teams will need to prove that authorization does not fragment when the workflow crosses a boundary. With 92% of organisations exposing NHIs to third parties, according to the Ultimate Guide to NHIs, the lesson is broader than AI: uncontrolled trust expansion is already a structural problem.

The next governance gap will be between agent discovery and action-level enforcement. Organisations that can list agents but cannot constrain their tools, data, and downstream actions at runtime will still be exposed, even if their inventory looks complete on paper. That is where AI agent governance starts to resemble advanced NHI governance, only with faster-moving behaviour.

For practitioners

• Inventory every agent platform in scope Map where agents are created, where they run, and which systems they can reach. Include cloud-native platforms and internal systems so hidden agent paths do not sit outside policy review.
• Enrich agents with governance context Attach business purpose, owner, data sensitivity, and tool dependencies to each agent profile so policy decisions can reflect operational reality rather than a bare technical identifier.
• Test policy continuity across platform boundaries Validate that the same authorization rule still applies when an agent moves from one cloud to another or into internal systems. If the policy changes at the boundary, the control model is fragmented.
• Enforce decisions at the action layer Check whether governance can constrain data access, MCP tool use, and downstream actions at runtime. If control exists only at provisioning time, the agent can still overreach during execution.

Key takeaways

• AI agent governance now depends on continuous authorization across platform boundaries, not just on visibility or inventory.
• Native cloud guardrails are insufficient once an agent reaches beyond a single platform into internal systems or another cloud.
• Practitioners should treat discovery, enrichment, and runtime policy as one control chain, because a break in any link weakens the whole model.

Key terms

• Agent Registry: A registry is the authoritative inventory of agents in an environment, including ownership, purpose, and platform location. For governance, it is the first control layer because you cannot review, enrich, or restrict what you have not identified.
• 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 Authorization: Runtime authorization is the decision to allow or deny access at the moment an agent attempts an action, not only when it is provisioned. In agentic environments, it is the control that keeps policy aligned with changing context and tool use.
• Policy Continuity: Policy continuity means the same governance rule remains effective as an identity moves across systems, clouds, or tools. In agentic AI, it is the measure of whether authorization still holds after the agent crosses a platform boundary.

Deepen your knowledge

Agentic identity governance and runtime authorization across cloud platforms are covered in the NHI Foundation Level course, the industry's only accredited NHI security programme. If you are trying to extend control from human and service-account governance into agentic environments, this is a useful starting point.

This post draws on content published by PlainID: PlainID expands support for AWS AgentCore and Microsoft Foundry across its agentic security and authorization platform. Read the original.