Topic starter
03/06/2026 2:22 pm
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.
Editorial analysis by NHI Mgmt Group, based on content published by Sonrai Security: “3 Prerequisites to Adopting Claude Platform on AWS”.
By the numbers:
- 92% of all cloud identities with access to sensitive permissions have not used them in the last 90 days.
- 61% of cloud identities go entirely unused in that same period.
Key questions
Q: What breaks when AI workspaces rely on standard cloud IAM without extra controls?
A: Standard cloud IAM breaks when the workspace can be modified by the same principals that merely need to invoke it.
Q: Why do long-lived API keys create more risk for AI agents?
A: Long-lived API keys increase risk because they persist across tasks, deployments, and runtime changes.
Q: How can teams tell whether AI workspace logging is sufficient?
A: Logging is sufficient only when actions that can change agents, environments, and memory stores are captured as evidence and can be tied back to specific AWS principals.
Practitioner guidance
- Protect critical AI workspaces with explicit allow-lists Use Service Control Policies to restrict Claude Platform workspace actions to named AWS principals only, especially for production or shared agent environments.
- Block long-term credential creation and use Deny service-specific credential creation and prevent bearer-token use where the token type is long term, so shadow IAM users and year-long API keys do not become persistence paths.
- Enable CloudTrail data events for AI actions Turn on data-event logging for model invocations, agent management, sessions, environments, skills, and memory stores before relying on telemetry for incident response or least-privilege tuning.
Bottom line: Claude Platform on AWS turns AI workspaces into identity-governed resources, so cloud IAM mistakes can now affect agent behaviour as well as infrastructure access.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
03/06/2026 2:29 pm
Claude workspaces inherit cloud IAM debt, they do not erase it. When AWS identity becomes the control plane for AI workspace access, pre-existing privilege creep, stale roles, and weak review cadence move directly into the AI layer. The same entitlement problems that already burden cloud programmes now decide who can shape agents, sessions, and environments. Practitioners should treat Claude workspace governance as an extension of cloud identity governance, not a separate discipline.
A few things that frame the scale:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: Should IAM teams treat Claude Platform workspaces as separate security zones?
A: Yes, because AI workspaces can become high-risk control surfaces even when they sit inside a familiar cloud account. Treat them as separate zones when different principals, different logs, or different privilege rules are required to protect production agents and shared environments. If you would not let a broad admin role alter those assets directly, the workspace needs stronger boundary controls.
👉 Read our full editorial: Claude platform on AWS raises new cloud IAM control gaps