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.
At a glance
What this is: Sonrai Security analyses how Claude Platform on AWS changes IAM control boundaries by tying AI workspace access to AWS identity, short-lived credentials, and CloudTrail visibility.
Why it matters: IAM teams need to understand that AI workspaces inherit the same privilege, offboarding, and logging failures as any other cloud identity surface, but with faster-moving operational blast radius.
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.
Context
Claude Platform on AWS ties Anthropic's platform features to AWS identity and billing controls, which changes the way access is provisioned, monitored, and revoked. The underlying issue is not whether AI workloads can run in AWS, but whether existing IAM governance can still control a workspace that now exposes agents, sessions, memory, environments, and credential vaults through the cloud identity fabric.
For IAM and NHI programmes, the control gap is familiar but the workload is not. Once AI workspaces sit behind AWS permissions, standing privilege, static credentials, and incomplete telemetry can all become entry points for misuse, persistence, or poor attribution.
The article is best read as a baseline-control discussion, not a product endorsement. Sonrai Security argues that organisations with weak identity hygiene will import their existing cloud IAM debt into AI operations unless they tighten workspace boundaries, credential creation, and audit visibility first.
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. In that setup, privilege scope, workspace integrity, and auditability are all coupled, so one compromised identity can alter agents, environments, or credentials. The result is a wider blast radius than most IAM reviews assume.
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. If one is exposed in a container, pipeline, or config file, the attacker can reuse it until it is manually revoked. For AI agents, that persistence creates a larger blast radius than the workload actually needs.
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. If those actions sit outside default telemetry, incident responders cannot prove who changed what or when. That makes the logging gap a governance gap, not just an observability issue.
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.
Technical breakdown
How AWS identity extends into Claude Platform workspaces
Claude Platform on AWS uses AWS identity and policy constructs to gate access to the Claude Platform API and UI. That means the effective security boundary is no longer just the application account, but the AWS principal, its session scope, and the permissions mapped to Claude actions. In practice, this blends traditional cloud IAM with AI workspace operations such as agents, skills, environments, and memory stores. When that mapping is broad, one compromised AWS identity can reach multiple AI control planes. The architectural shift matters because the same IAM decision now governs both infrastructure and AI runtime behaviour.
Practical implication: treat Claude workspaces as identity-governed resources and scope AWS principals to the smallest set of permitted workspace actions.
Why long-term Anthropic keys reintroduce standing privilege
The article describes long-term Anthropic API keys as being created through AWS using a shadow IAM user and service-specific credential. That pattern reintroduces standing privilege even when short-lived credentials are available, because the long-term key can persist for a year and remains usable if exposed. The shadow user also adds a separate account object that must be governed, monitored, and eventually removed. This is a classic non-human identity problem: the credential lifecycle, not just authentication, determines the blast radius. Short-term tokens reduce exposure windows; long-term keys preserve them.
Practical implication: govern service-specific credentials as NHIs, with explicit creation restrictions and revocation paths for any long-lived key material.
Why CloudTrail data events matter for AI workspace governance
The article notes that model invocations and management actions for agents, sessions, environments, skills, and memory stores are logged as data events, not management events. If data events are not enabled, those actions may fall outside default CloudTrail visibility. That creates a dangerous monitoring gap because malicious skill updates, dependency changes, and unusual agent actions can occur without the evidence needed for attribution or investigation. For identity teams, the logging question is not generic observability. It is whether AI workspace actions are captured at the same fidelity as their access risk warrants.
Practical implication: verify CloudTrail data-event coverage for AI workspace actions before relying on logs for least-privilege tuning or anomaly detection.
Threat narrative
Attacker objective: The objective is to manipulate Claude Platform workspaces and associated AI agents through trusted identity paths, then preserve or extend access through long-lived credentials and weak visibility.
- Entry occurs when a compromised AWS identity or a long-term Anthropic key can reach Claude Platform workspaces through mapped permissions.
- Credential access expands when standing privilege or shadow service-specific credentials provide durable access beyond the original session.
- Escalation follows when an attacker updates skills or environments used by Claude Managed Agents, allowing malicious instructions or dependencies to alter agent behaviour.
- Impact is achieved when those changes influence AI workspace execution across agents, sessions, memory, or model invocations without adequate logging or containment.
Breaches seen in the wild
- Azure Key Vault Contributor escalation 2024: Datadog found Azure Key Vault Contributor could add itself to access policies and read every secret, key and certificate in a vault.
- Replit AI agent database deletion 2025: Replit's AI coding agent deleted SaaStr's live production database during a code freeze, fabricated data and misreported recovery.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
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.
Standing privilege is the wrong default for AI workspaces. The article's long-term key model shows how quickly short-lived access can be undermined by durable credential paths and shadow users. That is an NHI lifecycle problem, not just a secrets hygiene problem, because the credential object itself becomes the persistence mechanism. The implication is that AI access design must assume credential provenance and offboarding are as important as authorisation scope.
CloudTrail data-event gaps create false confidence in AI observability. If model invocations and workspace actions are classified as data events, default logging settings can miss the very actions that matter most for abuse detection. That means least privilege cannot be validated after the fact unless the events exist in the first place. The implication is that identity teams need auditable runtime traces for AI workspace actions, not only policy documents.
Runtime governance is becoming the decisive control layer for agentic cloud access. The article points to a named control gap we can call the AI workspace blast radius: a compromised cloud principal can alter agent behaviour, environment dependencies, and access paths inside the same trust boundary. That is where identity governance now fails or succeeds. Practitioners should assume that access convenience and attack surface will move together unless the workspace boundary is explicitly constrained.
AI identity controls must be measured by what can change mid-session. Traditional IAM reviews assume privileges persist long enough to be reviewed, but agent-facing environments can be modified through a single authorised action. That collapses the review window and shifts the control question to issuance, scope, and logging at the point of change. The implication for identity programmes is simple: if the action can rewrite the workspace, it is already a governance event.
From our research library:
- 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.
- Read next: Agentic AI Identity Guide
What this signals
AI workspace governance now sits inside the IAM programme, not beside it. Claude-style integrations collapse cloud and AI access into one control surface, so identity teams have to govern principals, sessions, and workspace mutation rights together. If that boundary is not explicit, least privilege becomes theoretical because the same identity can both use and reshape the environment.
CloudTrail coverage should be treated as a control prerequisite, not a monitoring enhancement. When agent actions, environments, and skill changes are logged as data events, missing that telemetry means missing the evidence needed to prove containment or misuse. Practitioners should verify event coverage before they rely on anomaly detection or access reviews to tell them the truth.
For practitioners
- 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.
- Review NHI inventory for shadow users Identify any AWS-created shadow IAM users or service-specific credentials tied to AI access and map them to owners, purpose, and revocation criteria.
- Recalculate blast radius around AI workspaces Reassess which AWS principals can alter agent skills or environments, then remove broad write access from identities that should only invoke models.
Key takeaways
- 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.
- Standing privilege and long-term credentials are the main governance risk because they let AI access outlive the session and the person who should own it.
- CloudTrail data events matter because the most security-relevant AI actions can disappear from default logging unless organisations enable them explicitly.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | The article centers on agent workspace access, privilege scope, and misuse through trusted identity paths. |
| Recommendation — Restrict agent workspace privileges and separate invoke-only access from permissions that can change agents or environments. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Claude workspaces and shadow API keys are governed as non-human identities with excessive permissions. |
| NHI-07 — Long-Lived Secrets | The article warns that year-long Anthropic keys reintroduce durable credential risk inside AWS. | |
| Recommendation — Reduce workspace and key permissions to the minimum actions needed for the task and remove broad write access. Block long-lived API keys and require short-lived credentials for all AI workspace access paths. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Service-specific credentials and token lifetime are central to the article's access-risk analysis. |
| Recommendation — Apply authenticator lifecycle controls to prevent durable keys from becoming persistence paths. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is fundamentally about mapping and limiting who can act inside AI workspaces. |
| Recommendation — Review and tighten entitlements for AI workspaces so only approved principals can modify high-risk resources. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Compromised AWS identities can be used to reach AI workspaces and expand access across environments. |
| Recommendation — Map AI workspace abuse paths to credential access and lateral movement to prioritise detections around identity abuse. | ||
Key terms
- AI workspace: An AI workspace is a shared environment where users interact with an AI system through chats, files, projects, and administrative settings. It becomes a governance object when access, retention, and activity logging are managed like other enterprise systems that handle sensitive data.
- 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.
- Service Specific Credential: A service-specific credential is a credential issued for one named cloud service rather than for broad, general use. It can simplify access to a single endpoint, but it also creates a distinct lifecycle, revocation, and enforcement surface that must be governed separately from standard access keys.
- 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.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 3, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org