3 Prerequisites to Adopting Claude Platform on AWS

AWS recently launched Claude Platform on AWS, which blends Anthropic’s native Claude Platform with Amazon’s identity and billing fabric. Organizations using both AWS and Anthropic in their tech stack now have a flexible, centralized way to govern identity and access across both cloud and AI.

This integration does however introduce some security considerations worth addressing. This article presents three baseline controls to put in place before fully rolling it out. Namely:

1. Protecting Critical Workspaces via SCP
2. Restricting Static Credential Creation & Use via SCP
3. Enabling CloudTrail Data Events for Improved Visibility

Claude Platform on AWS

In addition to simple Anthropic model invocation, Claude Platform offers additional features like:

• Managed Agents
• Agent Sessions
• Persistent Memory Stores
• Execution Environments
• Credential Vaults for MCP Auth Credentials
• User & API Key Management

Claude Platform on AWS allows organizations to use Anthropic’s entire native platform and feature set through AWS. For organizations already using Claude Platform, this integration can be more appealing than AWS’s previous AI offerings. AI workloads hosted in Claude Platform can be migrated wholesale rather than having to be re-implemented through a combination of Amazon Bedrock and Amazon Bedrock AgentCore.

Arguably, one of the biggest benefits of this integration is the means to manage access using cloud-native IAM primitives. With Claude Platform on AWS, AWS identities can access the same familiar Claude Platform API or UI with access gated by their cloud permissions. 

There are a few benefits to this approach:

1. Granularity: Permissions can be assigned to users granularly rather than just having a few pre-defined roles. This is done through the standard IAM policy assignment, using the IAM permission to API action mappings published by Anthropic. 
2. Expiration: API requests are authenticated using AWS credentials, meaning access can be achieved through short-term credentials rather than static keys. If role session credentials or short-lived API tokens are leaked, the impact is time-gated to a few hours.

Existing applications relying on “ANTHROPIC_API_KEY” environment variables can use short-lived tokens generated by AWS’s Token Generator. For example, you can use the following shell command to generate a (region-scoped) short-term Anthropic API key based on the current user’s AWS identity:

export ANTHROPIC_API_KEY="$(python3 -c "from token_generator_for_aws_external_anthropic import TokenGenerator; print(TokenGenerator(region=\"us-east-1\").get_token())")"

Alternatively, you can send SigV4 signed requests directly and do away with the API keys entirely. If you’re already running anthropic-powered workloads on AWS infrastructure with execution roles (lambda functions, ecs containers, etc.), this can make a lot of sense as authorization becomes as easy as adding the requisite aws-external-anthropic permissions to the execution role.

Baseline Controls

So we can use Anthropic’s native Claude Platform all while controlling access through AWS’s IAM service and leveraging short-term credentials for greater security. This is a good starting point, but there are a handful of good security controls we can implement to further secure the AI service from the get-go:

1. Protect Critical Workspaces

The ability to use AWS’s IAM system with Claude Platform is a double-edged sword. As dev teams move fast to keep up with the rapid advancements in AI, unneeded standing privilege often gets left behind. As per Sonrai’s Cloud Access Risk Report, roughly 92% of all cloud identities with access to sensitive permissions have not used them in the last 90 days, and roughly 61% of cloud identities go entirely unused in that same period. 

By integrating Claude Platform with AWS’s identity fabric, the blast radius of a compromised AWS identity can now extend to Claude Platform. Let’s consider the case where a developer’s AWS credentials are compromised. In addition to all the other AWS services they have access to, the compromised credentials could now enable a would-be attacker to:

1. Update skills used by Claude Managed Agents with malicious instructions. This type of attack is already a known issue with local coding agents today, and can silently alter agent behaviour.
2. Update environments used by Claude Managed Agents with malicious dependencies. NPM packages can be added to execution environments, and can include preinstall/postinstall scripts that run automatically as part of this installation. A single command updating these environments can be enough to compromise the agents using them.

Service Control Policies (SCPs) can be used to protect Claude Platform workspaces containing critical AI infrastructure by building an explicit allow-list of the identity ARNs allowed to perform actions in the workspace. For example, if you use Claude Platform workspaces to segregate environments as referenced in the Claude Platform docs, you may want to restrict production workspace access to only a handful of users or roles:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyUnauthorizedAccessToWorkspace",
      "Effect": "Deny",
      "Action": "aws-external-anthropic:*",
      "Resource": "arn:aws:aws-external-anthropic:*:*:workspace/<workspace_id>",
      "Condition": {
        "ArnNotLike": {
          "aws:PrincipalArn": [
            "<permitted_identities>"
          ]
        }
      }
    }
  ]
}

Non-allowlisted identities – even global admins with * permissions – will encounter errors when attempting to perform actions on the protected workspace:

2. Eliminate Long-Term Credentials

While this integration does grant users the ability to use short-lived credentials to access the Claude Platform API, the ability to use static keys was also brought in. Because access is now controlled through AWS’s IAM service, those static Anthropic API keys now live in AWS. As it turns out, how AWS manages static Anthropic API keys is actually a recycled version of their long-term Bedrock API Key implementation. 

Sergio Garcia of BeyondTrust penned an excellent writeup on how long-term bedrock keys are created alongside their related security concerns; we’ll revisit some of those same concerns here as we see how this process applies to Claude Platform on AWS. 

In short, when long-term Anthropic keys are created in the AWS console, the following happens behind the scenes:

1. An shadow IAM User with the AeaApiKey-XXXXXXXX naming convention is created (“aea” stands for “AWS External Anthropic”)
2. The AnthropicLimitedAccess managed policy is attached to the user
3. A Service Specific Credential is created for the shadow user and returned in the console, which can then be used as an Anthropic API key

These API keys last by default for a year, meaning if this key were ever to be compromised, an attacker would likely still be able to cause damage upon acquiring it. As for impact, the default permissions associated with these keys enable holders to perform nearly all Claude Platform actions in all available Claude Platform workspaces; this highlights the importance of protecting critical workspaces as detailed in the section above. 

The shadow user also presents a risk in and of itself. It is yet another standalone identity with standing privilege that must exist to facilitate the API key use – something a would-be attacker could use for persistence.

There are two strategies for mitigating the risks of these long-term keys: preventing their creation and preventing their use:

Preventing Long-Term Anthropic Key Creation

We can prevent the creation of long-term credentials for Claude Platform by restricting the creation of service-specific credentials. We can do this using the same SCP we recommended to prevent the creation of long-term bedrock keys in our AI Governance Guide:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyServiceSpecificCredential",
      "Effect": "Deny",
      "Action": [ "iam:CreateServiceSpecificCredential" ],
      "Resource": [ "*" ]
    }
  ]
}

This doesn’t prevent the creation of the shadow IAM users though. If we want to do that, we can additionally target IAM user creation when the shadow-user naming convention is used:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyShadowIamUserCreation",
      "Effect": "Deny",
      "Action": [ "iam:CreateUser" ],
      "Resource": [ "arn:aws:iam::*:user/AeaApiKey-????????" ]
    }
  ]
}

Preventing Long-Term Anthropic Key Use

In the event that long-term keys already exist somewhere in the organization, we can ensure they can’t be used by blocking requests that use long-term api keys as bearer tokens. We can use the following SCP to do this in a way that still permits short-term key use:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyWhenLongTermBearerTokenUsed",
      "Effect": "Deny",
      "Action": "aws-external-anthropic:CallWithBearerToken",
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws-external-anthropic:BearerTokenType": "LONG_TERM"
        }
      }
    }
  ]
}

Long-term key use is denied:

Short-term key use is permitted:

3. Enable CloudTrail Data Events

Anthropic documents which API actions are logged as data events and which are logged as management events. It turns out that all model invocations, as well as all actions related to managing agents, sessions, environments, skills, and memory stores are all classified as data events. 

Out of the box, CloudTrail does not log data events. This means that the aforementioned attack scenarios (i.e. malicious skills manipulation & agent compromise via malicious environment dependencies) could go undetected unless data events are explicitly turned on for this service.

By enabling data events for external anthropic workspaces, we can get insights into which AWS identities are performing what actions in Claude Platform:

We can even ingest these into cloudwatch logs to get a better understanding of who’s doing what:

With this visibility in place, the data can be used to tighten least-privilege policies based on actual usage, as well as monitor for anomalous behaviour from unexpected identities.

Final Thoughts

Being able to control access to Claude Platform through something as flexible as AWS’s IAM service is a boon to any organization that has a good handle on their existing identity debt. For organizations that don’t, this integration will add to the pile and potentially expand the existing blast radius should something go wrong. 

Security baselines are important, and for new services it can often be hard to know where to start. The three controls included in this article aren’t intended to be the be-all and end-all when it comes to building a baseline for Claude Platform on AWS, but it is intended to be a good starting point. As this integration and AWS’s other AI services continue to mature and evolve, so will their best-practices. As such, stay tuned to Sonrai Security as we continue to put out more content like this tackling AI in the cloud.