Claude platform on AWS raises new cloud IAM control gaps

At a glance

What this is: Sonrai Security argues that Claude Platform on AWS improves identity centralisation but also widens the blast radius of compromised AWS identities across AI workspaces and agent controls.

Why it matters: IAM teams need to treat AI workspaces, short-term credentials, and cloud permissions as one control plane because the same identity debt can now affect both cloud operations and AI execution.

By the numbers:

• roughly 92% of all cloud identities with access to sensitive permissions have not used them in the last 90 days.
• roughly 61% of cloud identities go entirely unused in that same period.

👉 Read Sonrai Security's analysis of Claude Platform on AWS identity controls

Context

Claude Platform on AWS ties AI access to AWS identity and billing controls, which changes the operational model for teams that already run cloud IAM. The problem is not the integration itself, but the fact that any standing privilege or weak credential hygiene in AWS can now reach into AI workspaces, managed agents, sessions, and memory stores.

For IAM practitioners, that creates a familiar but broader governance problem: the access boundary is no longer just cloud infrastructure, it is also AI execution. Controls such as scoped workspaces, short-lived credentials, and telemetry for model and agent actions become part of the same identity programme rather than separate projects.

Key questions

Q: How should security teams govern Claude Platform access through AWS IAM?

A: Treat Claude Platform permissions as part of the AWS identity model, not as a separate AI exception. Scope which users, roles, and workloads can reach production workspaces, limit sensitive actions with explicit allow-lists, and verify that the same identities cannot modify agent state, environments, or memory without a documented need.

Q: Why do static AI credentials create more risk than short-lived tokens?

A: Static credentials create standing privilege, which increases the time an exposed secret remains usable and broadens the number of sessions an attacker can reuse. Short-lived tokens reduce exposure duration, but only if organizations prevent fallback paths that recreate durable API keys or shadow users.

Q: What breaks when CloudTrail data events are not enabled for AI services?

A: You lose the visibility needed to see model invocations, agent actions, and workspace changes that are classified as data events rather than management events. Without that telemetry, security teams cannot reliably distinguish normal AI operations from unauthorized environment changes or malicious manipulation.

Q: What is the difference between workspace allow-listing and least privilege in AI governance?

A: Least privilege defines the minimum rights a principal should have, while workspace allow-listing adds a boundary that blocks access to sensitive AI environments regardless of broader identity permissions. In practice, both are needed when cloud identities can influence agent behaviour, environment content, and session state.

Technical breakdown

How AWS identity gating changes Claude workspace access

When Claude Platform is accessed through AWS, the effective authorisation layer becomes cloud-native IAM plus service-specific permissions. That means a user, role, or execution identity can invoke AI features only if AWS policy allows the relevant action, which is cleaner than managing a separate identity plane but also inherits all the weaknesses of AWS entitlements. The key technical shift is that AI actions are no longer isolated from cloud permissions. If a principal can manage workspaces, agents, or environments, that principal can influence model behaviour and operational state. This makes entitlement scoping, role design, and boundary enforcement the first security questions, not the last.

Practical implication: Map AI service actions to AWS identities before rollout and decide which principals should never be able to touch production workspaces.

Why static credentials create long-lived AI exposure

Short-lived tokens reduce exposure time, but static API keys reintroduce standing privilege into an AI access path. In this model, a long-term credential is not just an authentication artifact, it is a durable bearer secret that can be reused across sessions and environments. The article’s shadow IAM user pattern shows why this matters: the credential may look like an integration convenience, but it also creates another identity object with persistent reach. From an NHI perspective, the risk is not the token alone, but the combination of persistence, broad permissions, and limited traceability when the key is used outside normal human workflows.

Practical implication: Treat long-lived AI API keys as high-risk NHIs and remove any remaining path that allows them to be created or reused.

Why CloudTrail data events matter for agent and workspace telemetry

CloudTrail management events do not capture the full operational story for AI services if model calls, agent actions, environment changes, and memory-store updates are logged as data events instead. That creates a visibility gap unless those data events are explicitly enabled and forwarded into a monitoring stack. The technical issue is simple: without service-level telemetry, you cannot distinguish legitimate agent activity from malicious workspace modification or abnormal identity use. For identity teams, logging is not an audit afterthought here. It is the only practical way to reconstruct who changed what in an AI workspace and whether least privilege still matches real usage.

Practical implication: Enable data-event logging before broad adoption so you can investigate agent actions, workspace changes, and unexpected identity use.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• 230M AWS environment compromise — 230M AWS environments compromised via exposed .env files with cloud credentials.

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

NHI Mgmt Group analysis

Claude Platform on AWS turns cloud identity debt into AI identity debt. Sonrai Security’s core point is that existing AWS entitlements now govern AI workspaces, managed agents, and session-level activity as well as infrastructure. That means the blast radius of a compromised cloud identity is no longer limited to cloud services. Practitioners should treat the integration as a control-plane merger, not a simple feature expansion.

Standing privilege was designed for access that persists long enough to be reviewed. That assumption fails when static keys and shadow IAM users create durable access paths into AI services that can be used across workspaces and sessions. The implication is not merely that controls are missing, but that the governance premise itself is wrong for this execution model.

Workspace governance has become a boundary-control problem, not just a permissions problem. Critical AI workspaces need explicit allow-lists because broad AWS entitlements can now alter agent skills, dependencies, and runtime environments. This is the point where least privilege becomes operational containment, and containment must extend to AI-specific actions as well as cloud APIs.

Visibility now determines whether AI misuse is detectable at all. If model invocations and agent operations are logged as data events, then leaving CloudTrail data events off creates a blind spot that can mask malicious manipulation of environments or sessions. Identity governance without telemetry cannot validate actual usage against intended access.

Identity blast radius is the right concept for cloud-connected AI governance. The article shows that one cloud identity can now influence both infrastructure and AI execution state. Practitioners need to assess not just who has access, but which AI objects that access can mutate and whether those objects sit inside production-critical boundaries.

From our research:

• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security, according to the 2026 Infrastructure Identity Survey.
• Organisations that describe themselves as confident in their AI deployment actually experience a 72% security incident rate, compared to 33% for those who remain cautious.
• That governance gap is structural, not theoretical, and it is why OWASP Agentic AI Top 10 should shape the next control review.

What this signals

The immediate planning signal is that AI identity governance cannot be bolted on after cloud adoption. With 67% of organisations still relying heavily on static credentials despite the risks they pose to agentic AI deployments, the control gap is already familiar to most IAM teams, and the next step is deciding which identities must lose durable access first.

Identity blast radius: when a single AWS principal can alter both infrastructure and AI runtime state, the governance question shifts from entitlement count to reachable impact. That is why teams should pair allow-listing with the Ultimate Guide to NHIs to align workspace boundaries, secret hygiene, and lifecycle review.

For practitioners

• Restrict AI workspace administration to explicit allow-lists Use service control policies and scoped AWS principals to limit which identities can touch production AI workspaces, agent settings, and environment controls.
• Eliminate long-term AI API credentials Block creation of service-specific credentials and shadow IAM users, then deny bearer-token use where long-term keys still exist.
• Turn on AI service data-event logging Enable CloudTrail data events for model calls, agent actions, environments, and memory stores, then forward them into monitoring for anomaly detection.
• Re-scope least privilege from AWS into AI runtime behaviour Review which identities can update skills, dependencies, sessions, and workspace configuration, then remove permissions that are unnecessary for day-to-day use.

Key takeaways

• Claude Platform on AWS ties AI execution to cloud identity controls, which expands the blast radius of weak AWS governance into agent and workspace operations.
• Static credentials and shadow users create durable AI access paths that undermine the value of short-lived authentication unless they are explicitly blocked.
• Telemetry and boundary controls matter together, because least privilege cannot be validated if model and agent actions are not logged as data events.

Key terms

• Shadow IAM User: A shadow IAM user is an identity created behind the scenes to support a service-specific credential or similar integration. It behaves like standing access even when the user never logs in directly, which makes it a persistent governance object that can outlive the purpose that created it.
• CloudTrail Data Event: A CloudTrail data event records service activity such as model invocations, agent actions, and object-level changes rather than broad control-plane administration. For AI services, it is often the only practical way to reconstruct what an identity actually did inside a workspace.
• Workspace Allow-list: A workspace allow-list is a policy boundary that limits which identities may perform actions in a sensitive AI environment. It is more restrictive than broad role-based access because it protects the environment itself, not just the user’s general permissions.

Deepen your knowledge

Claude Platform on AWS access control and AI workspace governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are extending cloud IAM into agentic workloads, it is worth exploring.

This post draws on content published by Sonrai Security: 3 Prerequisites to Adopting Claude Platform on AWS. Read the original.