Topic starter
03/06/2026 2:22 pm
TL;DR: Claude Platform on AWS extends identity risk into AI workspaces, Sonrai Security warns, especially when standing privilege, static credentials, and missing CloudTrail data events are in play. AI workspace governance now depends on runtime visibility into who can alter agents, boundaries, and credentials.
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: 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.
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.
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.
Glossary terms: AI workspace, Shadow IAM User, Service Specific Credential, CloudTrail Data Event
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 19 hours ago by NHI Mgmt Group
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