AWS AgentCore exposes the governance gap in agentic AI identity

At a glance

What this is: This is an industry analysis of AWS AgentCore that says platform security is improving, but governance gaps remain when AI agents create and consume non-human identities at scale.

Why it matters: It matters because IAM, PAM, and NHI teams need to understand where platform controls stop and where lifecycle, runtime, and behavioural governance must take over across autonomous and human programmes.

👉 Read Clutch Security's analysis of AWS AgentCore and agentic AI identity risk

Context

Agentic AI changes identity governance because an agent is only useful if it can obtain and use credentials at runtime. That makes the primary problem not just access control, but how non-human identity governance survives when the subject can select tools, combine actions, and consume secrets dynamically.

The article argues that AWS AgentCore improves platform security, but the broader enterprise challenge sits in implementation and runtime oversight. For IAM and NHI teams, that means the governance model has to account for both credential lifecycle and behavioural drift once agent workloads move from experiment to production.

Key questions

Q: How should security teams govern AI agents that can create and reuse credentials?

A: Treat each agent as a non-human identity with a lifecycle, not just a workload. Require discovery of every credential the agent can mint or consume, tie those credentials to a revocation point, and monitor the agent’s actual actions after issuance. That gives IAM and security teams a way to contain scope drift before one session turns into multi-system abuse.

Q: Why do AI agents complicate traditional IAM and PAM controls?

A: Traditional IAM and PAM assume that privilege is stable enough to provision, review, and retire on a human schedule. AI agents can request tools and credentials dynamically during execution, which makes access state more fluid than classic entitlement models expect. The result is a governance mismatch between static approval processes and runtime decision-making.

Q: What breaks when agent behaviour is monitored only at the platform layer?

A: What breaks is visibility into how legitimate access is used after it is granted. Platform controls can confirm that the agent authenticated successfully, but they do not by themselves show whether the agent propagated secrets, reached unintended systems, or chained actions beyond the original task. Without behavioural oversight, abuse can look like normal execution.

Q: How do IAM teams know whether agentic AI is actually under control?

A: Look for evidence that every agent identity is discoverable, every session has a clear end point, and every high-risk action is observable in context. If the team cannot trace credentials from issuance to retirement, or cannot explain unusual tool use, the programme is not yet governing agentic identity.

Technical breakdown

Session isolation and identity controls for agent workloads

AgentCore is described as combining session isolation, identity and access controls, secure token vaults, VPC-only networking, and Zero Trust verification. Technically, that matters because AI agents are not just callers of APIs. They are runtime entities that acquire, store, and reuse tokens across multiple systems during a single task. If the session boundary is weak, a valid credential can be reused outside its intended context, and the agent can continue acting with standing authority. That is why the architectural focus shifts from static authentication to tightly bounded session state and token handling.

Practical implication: map every agent session boundary to the credentials it can access and revoke anything that outlives the session.

Why agentic AI multiplies non-human identity sprawl

The article frames agents as prolific creators and consumers of non-human identities because every autonomous action requires credentials, API keys, tokens, or service accounts. That changes the scale problem. Traditional automation usually has a limited, predictable credential footprint, but agentic systems can spawn many short-lived and task-specific identities across orchestration layers, data stores, and tool interfaces. The result is not just more secrets, but more lifecycle complexity, more entitlement variance, and more places where privilege becomes difficult to inventory or audit.

Practical implication: build discovery and inventory processes that can track agent-created credentials across the full stack, not just in the platform layer.

Runtime governance is the missing control plane

The article separates platform security from runtime governance, which is the right distinction. Platform controls can authenticate the agent and constrain where it connects, but they do not by themselves explain what the agent did with legitimate access once execution began. Runtime governance is about monitoring actual behaviour, detecting scope drift, and understanding whether a legitimate identity has started to combine tools or trigger actions in ways the original authorisation model never expected. That is where traditional IAM stops being sufficient on its own.

Practical implication: pair entitlement review with behavioural monitoring so agent actions are observable after issuance, not just before.

Threat narrative

Attacker objective: The objective is to turn legitimate agent access into uncontrolled cross-system execution that can expose data, modify infrastructure, or amplify downstream compromise.

1. Entry begins when a developer or platform tutorial supplies credentials, tokens, or service account access for an AI agent to operate inside enterprise systems.
2. Escalation occurs when the agent combines legitimate tools and permissions in ways that were not explicitly anticipated at provisioning time, creating scope drift.
3. Impact follows when a misconfigured or abused agent triggers cascading actions across connected systems faster than human review or intervention can contain.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Agentic AI creates an identity governance gap, not just a security gap. The article is right to separate platform hardening from runtime governance because the underlying problem is that agents behave as credential consumers across many systems, not as static workloads. When access can be created, reused, and recombined in the flow of execution, traditional review cadences lose much of their explanatory power. Practitioners should treat this as a governance design problem, not a point product problem.

Standing privilege is the wrong mental model for autonomous agent behaviour. Standing privilege assumes access exists long enough to be enumerated, reviewed, and retired on a human schedule. Agentic systems can acquire and release access at machine speed, which makes that assumption increasingly fragile. The implication is not merely more controls, but a rethinking of how privilege is defined when the actor is runtime-selective and task-composed.

Runtime governance is now part of identity control, not an adjacent monitoring task. The article correctly identifies that legitimate access can still become unsafe once an agent begins combining tools and credentials dynamically. That makes behavioural context part of the authorisation decision, especially where write access, secrets propagation, or cross-system actions are involved. Security teams should stop treating post-authentication monitoring as optional telemetry and start treating it as identity evidence.

Identity blast radius becomes the governing concept for agentic deployments. Agentic AI expands the number of credentials, the number of actions a single identity can trigger, and the number of systems touched per session. That creates an identity blast radius problem where one mis-scoped agent can affect several services before any human sees the pattern. The practical conclusion is that agent governance must be designed around containment, not just access grant.

Agentic AI validates NHI as a core governance domain rather than a niche operational concern. The article’s central claim is that AI agents cannot operate without non-human identities, which makes NHI governance foundational to the agentic stack. That widens the brief for IAM, PAM, and security architecture teams because the control surface now includes agents, service accounts, tokens, and the lifecycle between them. Practitioners should recognise that agent security is NHI governance under a new workload model.

From our research:

• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so, according to AI Agents: The New Attack Surface report.
• Only 33% of organisations report their AI agents have accessed inappropriate or sensitive data beyond their intended scope, which shows how quickly runtime behaviour can outpace governance.
• That gap is why OWASP Agentic Applications Top 10 is becoming a practical reference point for teams building controls around tool use, scope drift, and identity abuse.

What this signals

Identity blast radius: agentic AI expands the number of credentials, systems, and actions tied to a single runtime identity, which means containment has to become a first-class design objective. Teams that only measure onboarding and access approval will miss the point if they cannot trace what an agent did after the grant. The governance model now has to span issuance, use, and retirement across the entire delegation chain.

The policy lesson for practitioners is straightforward: platform security is necessary, but it is not the same as operational control. AWS-style session isolation and token vaulting help, yet organisations still need independent oversight of runtime behaviour, especially where agents can access sensitive data or write into production systems. For a broader security model, teams should align agent governance with the NIST AI Risk Management Framework and map identity risks to OWASP Top 10 for Agentic Applications 2026.

With 98% of organisations planning to deploy even more AI agents within 12 months, per the AI Agents: The New Attack Surface report, the governance problem is going to scale faster than most IAM roadmaps. That makes discovery, runtime telemetry, and lifecycle controls the practical control set to prioritise now rather than later.

For practitioners

• Inventory every agent-created identity Track credentials, tokens, and service accounts that AI agents create or consume across development, staging, and production. Include temporary identities and delegated access paths so the inventory reflects the real runtime footprint, not only the intended design.
• Bind each agent session to a revocation point Define where a session begins and where it must end for every agent workflow. If the agent can reuse a token, call tools, or chain actions after the original task should have ended, the revocation boundary is too loose.
• Monitor for behaviour that exceeds intended scope Create detection logic for tool chaining, unexpected write actions, secrets propagation, and access to systems outside the original task description. Use those signals to distinguish a valid login from a governance failure.
• Separate platform security from runtime oversight Keep cloud-provider controls for identity, session isolation, and network segmentation, but add an independent review path for what the agent actually did with those permissions. The control gap is often behavioural, not infrastructural.

Key takeaways

• Agentic AI changes identity governance because runtime decision-making turns credentials into an active control surface, not a static entitlement record.
• The scale evidence is already clear: organisations are deploying more agents even while governance coverage remains incomplete and behaviour is already drifting beyond intended scope.
• Practitioners need to govern agent identity from issuance to retirement and pair access control with runtime visibility, or platform security will remain only half the answer.

Key terms

• Agentic AI: Software that can choose actions, tools, and timing at runtime rather than only executing a fixed script. In identity terms, that means the subject behaves like a non-human actor with its own access patterns, which raises lifecycle, privilege, and audit requirements that differ from standard automation.
• Runtime Governance: The controls and oversight applied after an identity is already active and using access. For agents, runtime governance means observing what the system actually does with credentials, not just what it was allowed to do at provisioning time. It is the bridge between authentication and accountability.
• Identity Blast Radius: The amount of damage one identity can cause if its access is mis-scoped, abused, or overextended. For agentic systems, the blast radius grows when a single runtime identity can touch multiple tools, data stores, and production systems within one session.
• Standing Privilege: Access that remains available without needing to be re-requested for each task. In agentic environments, standing privilege becomes harder to defend because autonomous systems may use, combine, and release access faster than review processes can observe.

Deepen your knowledge

Agentic AI identity governance is a core topic in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for autonomous agents and their credentials, it is worth exploring.

This post draws on content published by Clutch Security: The Agentic AI Security Paradox, AWS AgentCore Gets It Right but It's Not Enough. Read the original.