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.
NHIMG editorial — based on content published by Descope: Build Identity-Aware Agents With Amazon AgentCore and Descope
By the numbers:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, sharing sensitive data, and revealing access credentials.
Questions worth separating out
Q: What breaks when agent identity is scoped only to one cloud?
A: Governance breaks when runtime identity, policy, and credential handling all depend on one cloud boundary.
Q: Why do agentic AI programmes need issuance-time policy?
A: Because by the time a token is already live, the risky decision has been made.
Q: How should teams handle secrets used by AI agents and MCP tools?
A: Teams should keep secrets out of the agent environment and retrieve them only at call time from a managed vault.
Practitioner guidance
- Separate runtime identity from fleet governance Keep runtime attestation inside the cloud that hosts the agent, but manage directory, policy, and audit in a cloud-neutral layer so multi-cloud agents do not inherit fragmented controls.
- Move privilege decisions to token issuance Evaluate user, tenant, role, and requested scope before minting an access token so denied permissions never become live credentials in the first place.
- Vault every downstream credential used by agents Store OAuth tokens and static API keys in a central credential vault and retrieve them at call time instead of leaving raw secrets in agent context or runtime variables.
What's in the full article
Descope's full post covers the operational detail this post intentionally leaves for the source:
- Step-by-step configuration for Descope projects, clients, resources, and connections across AgentCore and MCP
- Concrete JWT authoriser settings for inbound auth, including discovery URLs, allowed clients, and audience checks
- Code-level examples for token exchange, credential fetching, and approval gating in agent tools
- Detailed setup for CIBA, SSO federation, and per-tenant approval flows that this post only frames at a governance level
👉 Read Descope's analysis of identity-aware agents on Amazon AgentCore →
Identity-aware agents beyond AWS: where governance breaks down?
Explore further
Cloud-neutral agent identity is becoming a governance requirement, not an integration nice-to-have. The article shows that agent identity tied too tightly to one cloud leaves non-native agents dependent on that cloud’s credential path and authorization assumptions. That creates a fleet design problem for NHI and agentic AI programmes because identity governance no longer aligns with runtime diversity. Practitioners should treat cloud neutrality as an identity boundary decision, not a deployment preference.
A few things that frame the scale:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, sharing sensitive data, and revealing access credentials, according to AI Agents: The New Attack Surface report.
- 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
A question worth separating out:
Q: Who is accountable when a headless agent needs sensitive approval?
A: Accountability stays with the organisation that defines the approval boundary, not with the model that requests the action. For sensitive workflows, out-of-band approval gives human reviewers a separate consent path, which is essential when the agent initiates the operation but a person must still authorise it.
👉 Read our full editorial: Identity-aware agents need cloud-neutral governance beyond AWS