TL;DR: Amazon Bedrock AgentCore covers AWS-native agent identity, but non-AWS agents still depend on AWS credentials and Cognito lacks CIBA, DCR, and out-of-band approval, according to Descope. The governance gap is not agent orchestration itself; it is the absence of a cloud-neutral identity layer that can issue, observe, and revoke access consistently across runtimes.
At a glance
What this is: This analysis says identity-aware agents need a cloud-neutral governance layer because AWS-native controls do not extend cleanly to agents running outside AWS.
Why it matters: IAM, IGA, and platform teams need to govern agent identity as a fleet-level access problem, not a single-cloud runtime feature, if they want consistent issuance, audit, and revocation.
Context
Identity-aware agents expose a governance gap when the control plane assumes a single cloud, a single directory, and a single authorization model. In practice, those assumptions break as soon as the agent fleet spans AWS, other clouds, and third-party tools that still need bounded access.
The article’s central issue is not whether agents can run in production. It is whether the identity layer can issue, observe, and revoke access consistently across runtimes, with policy enforced at issuance rather than after the token already exists.
For IAM and NHI programmes, that shifts the problem from runtime orchestration to cloud-neutral access governance. The question is whether the organisation can treat agent identity as a managed fleet with consistent authorization, credential handling, and lifecycle control.
Key questions
Q: How should teams govern identity across multiple cloud platforms?
A: Teams should govern identity across multiple cloud platforms by standardising policy intent, mapping entitlements consistently, and checking that revocation works across every connected system. The goal is not one universal directory, but one governable model for access decisions, audits, and lifecycle actions across heterogeneous environments.
Q: Why do non-AWS agents create governance risk even when AWS runtimes are secured?
A: Because the risk is in the identity boundary, not the runtime alone. If a non-AWS agent still depends on AWS credentials or AWS-routed authorization, governance becomes fragmented and the organisation loses a consistent way to scope and revoke access.
Q: What breaks when authorization is decided after the token already exists?
A: The main failure is that privilege can become observable too late to matter. Once the token has already been minted, the agent may already have a usable path to tools or data, so the safest control point is before issuance.
Q: Should organisations separate agent runtime controls from identity governance?
A: Yes. Runtime attestation, token injection, and cross-cloud policy serve different purposes, and collapsing them into one control plane makes portability and offboarding harder. Separate layers let each cloud contribute without becoming the only trust boundary.
Technical breakdown
Why AWS-native agent identity stops at the cloud boundary
Amazon Bedrock AgentCore Identity is designed for workloads that stay inside AWS. It can attest an agent at startup, inject tokens without bootstrap secrets, and authorize AWS service access through IAM and SigV4. But once a non-AWS agent must register or act across another runtime, the identity layer becomes dependent on AWS credentials and AWS APIs. That means the directory, policy decision point, and credential boundary are no longer cloud-neutral. The operational difference matters because identity is being used as infrastructure glue rather than as a portable trust layer.
Practical implication: map which agent identities still depend on AWS-only routing before you assume you have a fleet-wide governance model.
Why issuance-time policy matters for agent authorization
The article distinguishes between validating an inbound token and deciding what that token should contain in the first place. Issuance-time policy evaluates the user, the agent, the requested scope, and the tenant before a token exists, which prevents a later escalation path from ever materialising. That is materially different from group-based grant logic, because groups become inputs to the decision rather than standing authority. In cloud-neutral agent identity, this is the control that turns authorization into a bounded decision instead of a post-hoc check.
Practical implication: move scope decisions to issuance time if you need to prevent agents from asking for more privilege than they should receive.
How credential vaulting changes the exposure model for agents
The source describes a single credential vault that can hold OAuth tokens and static API keys across runtimes, then release scoped credentials at call time. That pattern reduces credential persistence inside the agent environment and keeps raw secrets out of model context, which is especially important when agents access third-party services and internal APIs. The governance point is not just rotation. It is eliminating long-lived secret residency in places where agent execution is opaque, distributed, and difficult to inspect after the fact.
Practical implication: separate token issuance from tool execution so no raw secret has to live inside the agent runtime.
Threat narrative
Attacker objective: The objective is to turn fragmented agent identity into a durable access path that can be reused across runtimes and clouds.
- Entry occurs when a non-AWS agent must participate in the workflow but still relies on AWS credentials to exist as a managed identity.
- Privilege is granted through the surrounding cloud control plane rather than through a portable, runtime-neutral policy boundary.
- Escalation risk appears when the same credential path is reused across runtimes, tools, and tenants without a consistent issuance decision.
- Impact is inconsistent observability and revocation, with access harder to maintain once the agent fleet extends beyond AWS.
Breaches seen in the wild
- Moltbook AI agent keys breach: Moltbook breach exposed 1.5M AI agent keys.
- DeepSeek database exposure 2025: An unauthenticated DeepSeek ClickHouse database exposed over a million log lines with plaintext chat history and API keys in 2025.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Cloud-neutral agent identity is the real control plane requirement: the article shows that cloud-native agent governance works only inside the ecosystem that issued it. Once agents span AWS and non-AWS runtimes, identity, directory, and policy all need to travel with the workload. Practitioners should treat cloud neutrality as an access governance requirement, not a convenience feature.
Issuance-time authorization is the decisive boundary for agents: the article’s strongest control point is policy at token issuance, before the token exists. That model prevents delegated privilege from becoming standing privilege, because scope, tenant, and user context are checked before the agent can act. The implication is that agent authorization must be designed around what can be granted, not what can be inspected later.
Agent directories need lifecycle governance, not just inventory: a list of agent names and creation timestamps is not a governance model. What matters is whether each agent entry carries policy, credential boundaries, and revocation logic that survive runtime changes. The practitioner conclusion is to govern agents as a managed identity fleet, not as a loose set of tool integrations.
Cloud-neutral governance surfaces a portability gap in today’s agent stacks: the article makes clear that AWS-native attestation and IAM pathing are valuable, but they do not solve cross-cloud identity consistency. That leaves a governance seam between runtime identity and fleet policy. Teams should expect this seam to shape vendor selection, architecture, and offboarding design.
Agentic authorization should be separated from cloud runtime control: the article demonstrates that runtime attestation, token vaulting, and policy evaluation are different layers. When those layers are collapsed into one cloud, governance appears simpler than it is. The practitioner takeaway is to preserve separation so one runtime cannot define the whole trust model.
From our research library:
- Business leaders plan to spend $124 million on average on AI in 2026, and 91% say data security and risk will shape their AI strategy.
- Read next: AI Agent Identity Security Buyer's Guide
What this signals
Cloud-neutral agent governance: the article exposes a portability problem that many programmes have not yet named. If agent identity only works inside one cloud, the organisation does not have a fleet strategy, it has a local implementation. Practitioners should expect this gap to show up first in offboarding, auditability, and tenant separation.
Issuance-time controls will matter more than runtime inspection: the useful control point is when a token is created, not after the agent has already acted. That shifts architecture toward policy engines, scoped token exchange, and auditable directory records rather than broad runtime trust.
The market is moving toward unified identity layers for AI agents because cloud-specific controls do not solve multi-runtime governance. Teams that delay this shift will end up with separate identity exceptions for each cloud and no consistent revocation story.
For practitioners
- Define a cloud-neutral agent directory Inventory every agent across AWS, other clouds, and prototypes in one managed directory with policy, ownership, and revocation data attached to each entry.
- Move authorization to issuance time Require token contents to be decided before an agent can call tools, using user context, tenant, and requested scope as inputs to the policy decision.
- Vault third-party and internal credentials Store OAuth tokens and static API keys outside the agent environment and release them only at call time through a shared credential vault.
- Separate runtime attestation from fleet governance Keep cloud runtime attestation, token injection, and cross-cloud policy enforcement as distinct controls so AWS does not become the only governance boundary.
Key takeaways
- Identity-aware agents running across clouds expose a governance gap that cloud-native controls cannot close on their own.
- The article’s key evidence is that non-AWS agents still depend on AWS credentials and that Cognito lacks CIBA, DCR, and out-of-band approval.
- Practitioners should centralise directory, policy, and credential vaulting so agent access can be issued and revoked consistently across runtimes.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agent identities spanning clouds can be mis-scoped or over-granted at issuance. |
| Recommendation — Apply ASI03 to keep agent privileges scoped to the exact runtime and task context. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The article centres on inbound JWT validation, OIDC discovery, and cross-runtime auth boundaries. |
| NHI-05 — Overprivileged NHI | Policies must prevent agents from receiving scopes they should not hold across clouds. | |
| NHI-07 — Long-Lived Secrets | The article warns against raw secrets entering agent environments and staying there too long. | |
| Recommendation — Use NHI-04 to validate agent authentication paths before tokens are accepted by any runtime. Apply NHI-05 to limit every agent to the smallest scope needed for its current task. Use NHI-07 to replace persistent secrets with short-lived, scoped credential retrieval. | ||
| MITRE ATT&CK | TA0006; TA0004 — Credential Access; Privilege Escalation | Credential retrieval and scope expansion are the key failure modes in cross-cloud agent access. |
| Recommendation — Map agent credential paths to TA0006 and TA0004 to find where scope can expand improperly. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is fundamentally about governing permissions and entitlements for agent identities. |
| Recommendation — Apply PR.AA-05 to enforce issuance-time authorization and revocation discipline for agent access. | ||
| NIST Zero Trust (SP 800-207) | Least privilege and continuous verification — Least privilege and continuous verification | Cross-cloud agents need ongoing verification rather than one-time trust in a single runtime. |
| Recommendation — Design agent access so verification and scope are continuous across every runtime boundary. | ||
Key terms
- Cloud-neutral agent directory: A cloud-neutral agent directory is a shared inventory and policy surface for agents that run across multiple runtimes. It keeps identity, credential, and audit data in one place so governance does not fragment when workloads span AWS, Azure, GCP, and other platforms.
- Issuance-time authorisation: Issuance-time authorisation is the decision made before a token is minted, when the system can evaluate the user, agent, resource, tenant, and requested scope together. It is stronger than static consent because it governs the specific action being requested, not just the identity standing behind it.
- Credential Vaulting: Credential vaulting stores privileged secrets in a controlled system rather than distributing them to users or embedding them in workflows. The security value comes from reducing direct exposure, supporting revocation, and creating a single governance point for high-risk credentials.
- Cross-cloud AI governance: Cross-cloud AI governance is the practice of applying one policy model across models, agents, and tools that run in different platforms. It exists to prevent identity, audit, and residency controls from fragmenting as teams move from experimentation to production.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle 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.
Published by the NHIMG editorial team on June 12, 2026.
Updated on October 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org