TL;DR: Claude Platform on AWS gives organizations short-lived access paths, but it also extends AWS identity risk into AI workspaces, with Sonrai Security warning that standing privilege, static credentials, and missing CloudTrail data events can widen blast radius and hide malicious agent manipulation. The real issue is not access convenience, but whether IAM programmes can still govern agent sessions, workspace boundaries, and credential provenance at runtime.
NHIMG editorial — based on content published by Sonrai Security: 3 Prerequisites to Adopting Claude Platform on AWS
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
What's in the full article
Sonrai Security's full blog covers the operational detail this post intentionally leaves for the source:
- The exact SCP patterns used to block unauthorized workspace actions in AWS
- The shadow IAM user and service-specific credential flow behind long-term Claude API keys
- Which Claude Platform actions are logged as data events and how to verify they are enabled
- Examples of how to translate real usage into tighter least-privilege policy scopes
👉 Read Sonrai Security's analysis of Claude Platform on AWS identity controls →
Claude platform on AWS: what changes for IAM teams?
Explore further
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Claude platform on AWS raises new cloud IAM control gaps