Where a Claude User Profile Travels on AWS - Request Headers, the Bedrock Body, and Which Paths Restrict One Customer

First Published: 2026-11-05
Last Updated: 2026-11-05

On October 20, 2026, Anthropic added user profiles to the Claude API. These user profiles provide a mechanism for businesses using Claude within their own services to inform Anthropic about which end customer each request is intended for. Anthropic's documentation on user profiles describes their purpose as follows:

A safety enforcement action, such as a restriction or a ban, can then apply to one end customer instead of your whole organization. When it does, the rest of your traffic is unaffected.

However, there is not a single path for invoking Claude on AWS. There are three entry points: the Claude API, Claude Platform on AWS, and Amazon Bedrock. The Bedrock entry point further branches into three separate paths. Each path differs in where the user profile ID is placed (in HTTP headers or in the request body), the level of scrutiny applied to the ID, and whether actions are reported or actively enforced. For example, on Claude Platform on AWS, the enforcement_status is always unrestricted, and Anthropic will not reject requests based on open actions. Claude in Amazon Bedrock only inspects the format of the ID and does not look up the profile. Regarding the bedrock-runtime path, which AWS recommends for new applications, documentation indicating whether or not a user profile is accepted was not found in either Anthropic's or AWS's materials.

This article presents, in tables and diagrams, a breakdown of each path, detailing whether a user profile can be created, where the ID should be placed, what is inspected, and whether actions are reported and enforced. It then lists the layers responsible for determining the unit of enforcement actions (Anthropic's organization, workspaces, AWS accounts, and IAM). This article is not a step-by-step guide to using the user profile API, nor does it cover pricing. The information presented was verified as of November 5, 2026.

On November 5, 2026 (UTC), requests with user profile IDs were sent to the three Bedrock paths using a validation account in the us-east-1 region. Even the two bedrock-runtime paths (P4 and P3b), for which no statement was found, rejected requests with malformed IDs with a 400 error. This is an observation and does not indicate attribution or enforcement. The results are detailed in Chapter 10.

Related articles on this site:

1. Scope and Assumptions
2. How to Read the Tables
3. What User Profiles Are For
4. The Path Table
5. Three Paths in Amazon Bedrock
6. Who Is Affected by an Enforcement Action?
7. Layers That Decide the Unit of an Enforcement Action
8. Ways to Learn About Enforcement Actions
9. Where Sources Disagree, What the Documentation Does Not List, and Statements Not Found
10. Observations from This Configuration
11. Failure Modes
12. Frequently Asked Questions About Claude User Profiles and AWS Paths
13. Summary
14. References

1. Scope and Assumptions

This chapter defines the intended audience for this article, outlines the scope of its content, specifies the date when the source materials were verified, and establishes the terminology used.

1.1 Intended Audience

This article is intended for businesses that are using Claude to support their services, aggregating requests from multiple end customers and sending them through a single Anthropic organization or an AWS account. Specifically, it targets platform and security professionals at SaaS providers, gateway providers, and businesses that resell API usage.

In particular, this article is written for readers who are considering the following:

If a user profile ID is attached, enforcement actions will only apply to a single customer, whether using Bedrock or Claude Platform on AWS.
If IDs are sent in the header, they will be treated consistently regardless of the path.
If workspaces are segmented by customer, enforcement actions will also be segmented by customer.

This article provides evidence, through documentation, that these three assumptions do not hold on some paths.

1.2 Scope: What This Article Covers and What It Does Not

This article addresses the following topics:

For each path, whether a user profile can be created, where IDs should be placed, what is checked, and whether enforcement actions are reported and applied.
Handling requests without IDs.
The layers involved in defining the unit of enforcement actions: Anthropic organizations, workspaces, AWS account linking, and IAM.
Methods for determining the status of enforcement actions: enforcement_status, enforcement_actions, and organizational webhooks.
Discrepancies in documentation and missing text.
Observations made in Chapter 10.

This article does not cover the following topics:

Pricing.
Criteria for safety enforcement actions and inferring the reasons behind those actions.
Detailed instructions on how to write profile items. Anthropic's "Create a profile" API reference covers this.
Detailed procedures for the Verification Portal and programs such as the Cyber Verification Program.
Gateway configuration. This is covered on this site in Running Claude Apps Gateway on AWS.
General concepts of tenant isolation. This is covered on this site in AWS SaaS Multi-Tenant Architecture Guide.
Descriptions of Bedrock's two endpoints. This is covered on this site in Amazon Bedrock Inference Endpoints and API Keys.
Request size limits. Another article in this series covers this (Which Request Size Limit Hits First Between Your App and Claude).
The extent to which agents can trigger Step Functions operations. Another article in this series covers this (When a Step Functions Workflow Is an Agent Tool).
Methods for circumventing enforcement actions or falsifying IDs.

1.3 Verification Date and Materials

This article was verified on November 5, 2026. The API version discussed in this article is 2026-10-21. The user profile page and the organization webhook page may be updated.

This article refers to Anthropic's documentation using the following names:

User profile page: User profiles for end-customer attribution page
Verification Portal page: Send an end customer a link to the Verification Portal page
Webhook page: Organization webhooks page
API reference: User profile API reference, including the pages for Create a profile, Retrieve a profile, List profiles, Update a profile, and Delete a profile.
IAM page: Claude Platform on AWS IAM actions page
Bedrock page: Claude in Amazon Bedrock (Opus 4.7 and later) page
Legacy Bedrock page: Claude on Amazon Bedrock (Opus 4.6 and earlier) page
Release notes: Claude Platform release notes

This article refers to AWS documentation using the following names:

Bedrock Messages API page: Inference using Anthropic Messages API page
Bedrock Claude parameters page: Anthropic Claude Messages API page, including the request and response pages.
Bedrock Workspaces page: Workspaces (Anthropic-compatible) page
Bedrock request metadata page: Per-request metadata tagging page
Service Authorization Reference: Service Authorization Reference, specifically the page for the aws-external-anthropic namespace on Claude Platform on AWS.

This article also examined the source code of Anthropic's Python SDK, as it existed on November 5, 2026, when viewed on GitHub's main branch. The SDK's source code does not consist of text from Anthropic's official documentation. This article will present information derived from the SDK's source code, clearly distinguishing it from the content found in Anthropic's documentation.

1.4 Terminology

This article uses the following terms with the following meanings:

User Profile: An Anthropic user profile. These are created via POST /v1/user_profiles and have IDs that begin with uprof_. This article does not refer to Amazon Cognito user profiles, AWS CLI profiles, or Bedrock inference profiles as "user profiles."
End Customer: A company or individual that uses a service provided by a business. Anthropic's documentation refers to this as "end customer."
Enforcement action: A safety enforcement action implemented by Anthropic. There are two types: restrictions and bans.
Attribution: Informing Anthropic which end customer a request is for.
Anthropic Organization: The organization in the Claude API, or the organization in Claude Platform on AWS.
Workspace: This article differentiates between three entities with similar names:
Anthropic Workspace: A workspace within an Anthropic organization.
Platform on AWS Workspace: A workspace in the Claude Platform on AWS organization. It has an IAM ARN.
Bedrock Workspaces: AWS resources that Amazon Bedrock places on top of bedrock-mantle.
Path: The way a request takes from an application's server to Claude. The names of the paths are aligned with the article on request size limits in this series (see Section 4.1).
Inspecting Path: A path that checks the ID for each request. This is a path described on the user profile page, which checks the ID for each request.
Format-Only Path: A path that checks only the format of the ID and does not retrieve a profile.

2. How to Read the Tables

This chapter defines the columns in the tables presented in this article, as well as how to describe the state of the sources and how to cite their sources. The columns in the summary table, presented in Chapter 4, are used consistently across the three articles in this series.

2.1 Table Columns

The summary table in Section 4.3 has the following seven columns:

Layer: The layer to which the row applies.
Limit or Control: The control mechanisms associated with that layer.
Set By: The company that defines these controls.
What Happens at the Boundary: How requests from outside the boundary are handled.
How You Can Tell: Where you can verify that the control is in effect.
Where It Is Written: The source of the information for that row.
Source State: The state of the documentation, described using the terminology in Section 2.2.

The table in Section 4.2, which describes the paths, uses the following seven columns: Path, Create Profiles Here, Where the ID Goes, What Is Checked, Enforcement Reported and Applied, Where It Is Written, and Source State. The Create Profiles Here column indicates whether user profiles can be created along that path. The Enforcement Reported and Applied column describes whether enforcement status is reported and whether requests are rejected based on enforcement actions.

2.2 Terms for the State of the Sources

This article uses eight terms to describe the state of the documentation. These English terms will also be used in the tables.

Stated: The documentation contains a statement regarding the matter.
Stated as not supported: The documentation explicitly states that the matter is not supported or cannot be used.
Documentation does not list: While a list or table exists, the specific item is not included. This does not indicate that the matter is unsupported or unavailable.
Not recorded (stated): The documentation states that the information is not included in logs or records.
No statement found: Despite searching using different search terms and examining different categories of documentation (as described in Section 1.3), no relevant statement could be found. This does not indicate that the matter is unsupported or unavailable.
Sources disagree: The documentation from two different sources provides conflicting statements regarding the same matter. This article will present both statements and their sources, without designating either as incorrect.
Inference: This is an inference made by this article, and is not a statement found in any of the documentation. This article will clearly indicate that the statement is an inference.
Observation: This is based on observations made during testing (as described in Chapter 10) and does not represent a statement from the documentation. This article will not overwrite any statements found in the documentation with observations.

This article distinguishes between "Stated as not supported" and "No statement found." The former refers to a statement in the documentation, while the latter indicates that this article was unable to find a relevant statement.

2.3 How Sources Are Cited

For each point, this article indicates which company's page and which section contains the relevant text, all in the same sentence. If a piece of text from a user profile page appears within a particular section, this article also specifies the scope of that section. For example, there are three instances of text describing how to handle requests without an ID, each located on the user profile page but within different sections (Section 3.3). This article focuses on presenting the text from each section without extending it to other paths.

3. What User Profiles Are For

This chapter outlines the purpose of the user profile, explains how to handle requests without an ID, and defines who gets a user profile, all in the context of the user profile page.

3.1 Limiting Enforcement Actions to a Single Customer

The user profile page states, regarding platform and gateway operators, as well as businesses reselling API usage, as follows:

If you operate a platform or gateway, or resell API access, the requests you send for your end customers arrive under your organization. Anthropic runs automated safety classifiers over API traffic. Without a profile on the request, one end customer can trigger an enforcement action that applies to your whole organization.

Businesses should create a profile for each end customer using the POST /v1/user_profiles endpoint, and save the returned ID. Subsequently, they should include that ID with every request sent on behalf of that customer. As stated at the beginning, an enforcement action can apply to a single end customer instead of the entire organization. The language on the user profile page uses the word "can," and does not explicitly promise that enforcement actions are limited to a single customer.

The user profile page contains only one sentence regarding pricing. This article will interpret that sentence as a clarification that a user profile should not be considered part of the pricing mechanism.

On their own, profiles don’t change billing or pricing.

3.2 Defining User Profiles

The user profile page specifies who user profiles should be created for, as detailed in the table below. This section summarizes the information in the table.

Who the Traffic Is For	Profile	`access_type`
Users registered with the product	One profile per user	`application`. This is the default value.
Companies you resell API access to	One profile per company. Not per individual within the company.	`passthrough`. This is not the default and must be explicitly specified.
Internal organization	Do not create	Not applicable
Workspaces within the internal organization	No separate profile	Not applicable

The passthrough profile represents a company, not the individual who initiated the request. The user profile page also states that if a request originates from an individual, their identifier should also be sent in the metadata.user_id field of the Messages request. This metadata refers to the request-side metadata and is separate from the profile's metadata fields.

The user profile page describes creating user profiles as follows:

POST /v1/user_profiles isn’t idempotent, so every call creates a new profile, even when reference_id matches an existing one.

Repeated attempts to create profiles will result in duplicate profiles for the same customer. The user profile page states that the ID should be saved in the customer's record, and the service instance should read from that record.

The user profile page also indicates that Anthropic does not verify the details in the profiles.

Anthropic doesn’t verify the details.

3.3 Three Sentences, Each With a Different Scope, Cover Requests Without an ID

These sentences regarding requests without an ID are found in three distinct locations on the user profile page.

The first is the last sentence of the second paragraph of the introductory text on the page referenced in Section 3.1. This sentence uses the word "can," without specifying a particular path.

The second is in the table that lists who is being provided with a profile, specifically in the row pertaining to the company's own use.

None. Anthropic counts a request with no profile ID as your own usage.

The third sentence is found in the section discussing Claude Models on Google Cloud (Google managed) and Amazon Bedrock.

A request with no ID goes through unattributed, and if it triggers an enforcement action, the action applies to your whole organization.

It is within this third sentence that it explicitly states that the enforcement action applies to the entire organization. This article does not extend this statement to other paths. Regarding requests without an ID on other paths, the user profile page addresses them through the first sentence using "can" and the second sentence, which counts them as being for the company's own use.

The user profile page indicates that requests for end customers and those for the company's own use should be kept in separate organizations, and this point will be addressed in Section 7.1.

4. The Path Table

This chapter outlines the paths, specifying for each path whether user profiles can be created, where IDs should be placed, what is checked, and whether enforcement actions are reported and applied.

4.1 Path Names

This article uses the path names of the request size limits article in this series. However, P3 is divided into two parts. This is because the text on the user profile page only discusses the earlier integration (see Section 5.2).

Path	Claude-Side Entry
P1	Claude API
P2	Claude Platform on AWS
P3a	The earlier integration using ARN-versioned model IDs via Bedrock's `bedrock-runtime`'s InvokeModel and Converse. Opus 4.6 and earlier models, as described on the legacy Bedrock page.
P3b	Integrations using Bedrock's `bedrock-runtime`'s InvokeModel to call newer models that do not use ARN-versioned model IDs.
P4	Bedrock's `bedrock-runtime`'s Messages API. The URL begins with `/anthropic`.
P5	Bedrock's `bedrock-mantle`'s Messages API, referred to as "Claude in Amazon Bedrock" in Anthropic's documentation.

Microsoft Foundry and Claude Models on Google Cloud are outside the scope of this article. One paragraph below the table in Section 4.2 covers them.

4.2 Path Table

The following table outlines the handling on each path.

Path	Create Profiles Here	Where the ID Goes	What Is Checked	Enforcement Reported and Applied	Where It Is Written	Source State
P1 Claude API	Yes	`anthropic-user-profile-id` header	Checked on each request. Format errors and IDs from other organizations will result in a 400 `invalid_request_error`. Message Batches are checked for format only when creating the batch.	Reported via `enforcement_status`. Per the general sentence in the enforcement section, while an enforcement action is open, Anthropic refuses some or all inference requests that carry the ID.	User profile page	Stated
P2 Claude Platform on AWS	Yes. Requires the calling entity to have IAM actions for user profiles.	`anthropic-user-profile-id` header	Same as P1	Not reported. `enforcement_status` is always `unrestricted` and `enforcement_actions` is always empty. Anthropic does not refuse requests because of an open action.	User profile page, IAM page	Stated
P3a Earlier Integration	No	Does not work	—	—	User profile page	Stated as not supported
P3b InvokeModel with newer models	No	No statement found	No statement found. In the configuration in Chapter 10, a malformed ID in the request body returned a 400 error.	No statement found	Legacy Bedrock page, user profile page, Chapter 10	No statement found. Checks: Observation
P4 `bedrock-runtime` Messages API	No	No statement found	No statement found. In the configuration in Chapter 10, a malformed ID in the request body returned a 400 error.	No statement found	Bedrock Messages API page, Chapter 10	No statement found. Checks: Observation
P5 Claude in Amazon Bedrock	No. Must be created within an organization using either the Claude API or Claude Platform on AWS.	Top-level `user_profile_id` in the request body	Format only. Format errors will result in a 400 error. Well-formed IDs will be accepted without retrieving the profile.	No statement found regarding how Bedrock reports enforcement actions, or any text stating that requests may be rejected due to enforcement actions. It is not stated whether the general statements in the enforcement section apply to P5.	User profile page	Location and checks: Stated. Enforcement: No statement found

Regarding the P1 and P2 checks, the user profile page states the following:

The Claude API, Claude Platform on AWS, Microsoft Foundry deployments hosted on Anthropic, and Claude Models on Google Cloud (Anthropic managed) check the ID on every request. If the ID is malformed or doesn’t belong to the organization that sends the request, the API returns a 400 invalid_request_error.

For paths outside this article's scope, the page indicates that with Microsoft Foundry deployments hosted on Anthropic, as well as with Anthropic-managed Claude Models on Google Cloud, user profiles can be created and IDs are sent in the header. Regarding Claude Models on Google Cloud (Google managed), the page states that user profiles cannot be created, and IDs are sent in the header, with only the format being checked, similar to Bedrock. The page specifies that IDs should be placed in the request body only for P5, one of the six listed paths.

4.3 Summary Table

The following table lists the layers that decide the unit of an enforcement action, using the columns common to the three articles in this series.

Layer	Limit or Control	Set By	What Happens at the Boundary	How You Can Tell	Where It Is Written	Source State
Profile ID on the request	An ID specific to each request. P1 and P2 take it in the header, and P5 in the request body.	Anthropic	P1 and P2 reject malformed IDs and IDs from different organizations with a 400 error. P5 only rejects malformed IDs with a 400 error.	HTTP status codes and error types	User profile page	Stated
Anthropic organization	Profiles belong to an organization. By default, P1 and P2 only accept IDs from requests originating from the organization that created the profile.	Anthropic	P1 and P2 reject an ID created by another organization with a 400 error.	HTTP status codes	User profile page	Stated
Anthropic workspace	Profiles do not belong to a workspace. IDs are accepted within any workspace within the organization.	Anthropic	Even if workspaces are separated, profiles are not separated.	—	User profile page	Stated
AWS account link	Links a Bedrock AWS account to the organization that creates the profiles.	Anthropic Verification Portal	Before linking, programs applied to the profile are not applied to requests from that account.	Portal displays "Linked"	User profile page, Verification Portal page	Stated. Relationship between linking and attribution: No statement found
IAM on Claude Platform on AWS	The six IAM actions for user profiles are permitted at the account level with `Resource: "*"`	AWS IAM, Anthropic's documentation	Not granted by a statement with a workspace ARN.	IAM rejections	IAM page, Service Authorization Reference	Stated. `DeleteUserProfile` in the Service Authorization Reference: Documentation does not list
Enforcement status	`enforcement_status` and `enforcement_actions`. For P2, it is always `unrestricted` and empty.	Anthropic	For P1, while an enforcement action is open, some or all requests are refused. P2 does not refuse requests because of an open action.	Profile retrieval and listing	User profile page, API reference	Number of values: Sources disagree
Organization webhook	Two events: when an enforcement action opens and when it ends.	Anthropic	Events are not sent.	—	Webhook page	Stated

5. Three Paths in Amazon Bedrock

This chapter outlines the paths within Bedrock – P5, P3a, P3b, and P4 – noting that the paths handle user profiles in three distinct ways.

The following diagram details, for each path, where IDs are placed and what is inspected.

Where the User Profile ID Goes on Each Path

5.1 P5 Claude in Amazon Bedrock Receives the ID in the Request Body

The user profile page describes user profiles within Bedrock as follows:

On Amazon Bedrock, profiles work only with Claude in Amazon Bedrock.

Anthropic's Bedrock page defines Claude in Amazon Bedrock as follows: /anthropic/v1/messages is the Messages API endpoint for bedrock-mantle.

This page covers Claude in Amazon Bedrock, which serves Claude through the Messages API at /anthropic/v1/messages on AWS-managed infrastructure.

The user profile page details where the ID is located within Claude in Amazon Bedrock as follows:

On Claude in Amazon Bedrock, put the ID at the top level of the request body:

The following example shows model, max_tokens, user_profile_id, and messages arranged at the same level in the request body.

{
  "model": "anthropic.claude-opus-5-5",
  "max_tokens": 1024,
  "user_profile_id": "uprof_011CZkZCu8hGbp5mYRQgUmz9",
  "messages": [{ "role": "user", "content": "Hello, Claude" }]
}

Regarding the P5 inspection, the user profile page states, in the sections for Google Cloud (Google managed) and Bedrock, as follows:

Claude Models on Google Cloud (Google managed) and Claude in Amazon Bedrock check the format of the ID but don’t look the profile up. They reject a malformed ID with a 400. They accept any well-formed ID, so a successful response doesn’t confirm that the ID matches a profile.

This statement indicates that even if the ID contains typos or belongs to a deleted profile, it will pass the P5 inspection as long as the format is correct. The user profile page also states that after a profile is deleted, requests that carry the deleted ID can still succeed for up to about 10 minutes, after which the inspecting paths reject them with a 400 error, while Google Cloud (Google managed) and Claude in Amazon Bedrock will continue to accept the request. No statement was found regarding the rules for the ID format, other than the reference in the API reference stating that the ID begins with uprof_.

The Anthropic Python SDK's AnthropicBedrockMantle client moves the ID specified in the header to the top level of the request body before sending it. The description of the function in the SDK's source code, identified as _mantle.py, is as follows. This is a statement from the SDK's source code, not from Anthropic's documentation.

Mantle reads the user profile ID from the body of these requests, and from the header on other routes.

This function only moves the ID on requests for Messages and Token Counting. Gateways that assemble requests without using the SDK must ensure that the ID is placed at the top level of the request body. This article did not check SDKs for other languages.

In the configuration in Chapter 10, a P5 Messages request with a malformed ID only in the header returned 200 (Observation). On this path, for this request, the ID in the header was not checked.

5.2 User Profiles Do Not Work on P3a, the Earlier Integration

The user profile page, in the sections regarding Google Cloud (Google managed) and Bedrock, states:

It doesn’t work with the earlier Amazon Bedrock integration that you call with InvokeModel or Converse.

This sentence refers to the earlier Amazon Bedrock integration, which links to the legacy Bedrock page. That legacy Bedrock page describes its scope as using ARN-versioned model IDs with the InvokeModel and Converse integrations. This article interprets this sentence as pertaining to P3a.

5.3 P3b and P4 Are Not Confirmed in the Documentation

Regarding P3b and P4, no statements were found indicating whether they receive a user profile.

The legacy Bedrock page mentions new models as follows:

Claude Fable 5.1, Claude Fable 5, Claude Opus 5.5, Claude Opus 5, Claude Sonnet 5.5, Claude Sonnet 5, Claude Haiku 5.5, Claude Opus 4.8, and Claude Opus 4.7 are reachable through InvokeModel on bedrock-runtime. These requests are served by the same infrastructure as the Claude in Amazon Bedrock endpoint.

The statement that they are served by the same infrastructure does not state that user profiles work on P3b. However, some readers may interpret the statement from Section 5.2 – "that you call with InvokeModel or Converse" – as applying to all invocations of InvokeModel. Since the available documentation confirms neither interpretation, P3b will be marked as "No statement found."

Concerning P4, AWS's Bedrock Messages API page states that the Messages API is available on both bedrock-runtime and bedrock-mantle, and recommends bedrock-runtime for new applications.

For new applications, we recommend the bedrock-runtime endpoint.

AWS's Bedrock Workspaces page also makes the same recommendation. However, on Bedrock, the user profile page states that user profiles work only with Claude in Amazon Bedrock, and Anthropic's Bedrock page gives that endpoint as bedrock-mantle. If you follow AWS's recommendation and choose either P4 or P3b, you leave the only path where the documentation states that user profiles work. This article does not recommend one endpoint over the other. If it is necessary to attribute requests using an ID, you must verify this distinction when selecting an endpoint.

In the configuration in Chapter 10, P4 and P3b also rejected a malformed user_profile_id at the top level of the request body with a 400 error and the same message as P5, and returned 200 for requests with well-formed IDs (Observation). This observation indicates that P4 and P3b inspect the format of this field. It does not show that requests are attributed or that enforcement actions apply. This article keeps the source state of P4 and P3b as No statement found.

A thorough search of four AWS Bedrock pages (the Messages API page, two pages detailing Claude parameters, and the Workspaces page) yielded no mention of "user profile" or "user_profile_id." Furthermore, there is no handling of user profiles in the client-side source code for InvokeModel in Anthropic's Python SDK.

5.4 Bedrock Request Metadata Is a Separate Mechanism

Amazon Bedrock includes request metadata, allowing you to associate key-value pairs with each request. According to the documentation, this metadata is added as the X-Amzn-Bedrock-Request-Metadata header when using InvokeModel, and in the requestMetadata field in the request body when using Converse. This request metadata is logged with model invocations and is intended for tracking usage, allowing you to segment it by team or application. This article does not treat request metadata as a mechanism for conveying the unit of Anthropic's enforcement actions. Neither company's documentation contains any statements regarding the relationship between request metadata and user profiles (No statement found).

6. Who Is Affected by an Enforcement Action?

This chapter lists, for each path, which requests may be stopped when an enforcement action opens.

6.1 P1 Claude API

The user profile page states the following regarding open enforcement actions:

While an action is open, Anthropic refuses some or all inference requests that carry the profile’s ID.

The enforcement action applies to some or all requests that carry the ID. The API reference clarifies the difference between restrictions and bans, stating that with restrictions, some service may still be provided to the end customer, while bans mean that service has stopped where the ban applies. This article does not specify the criteria for which requests will be rejected.

6.2 P2 Claude Platform on AWS

The user profile page describes Claude Platform on AWS as follows:

On Claude Platform on AWS, the two fields don’t report enforcement actions: enforcement_status is always unrestricted, and enforcement_actions is always empty. Anthropic doesn’t refuse requests there because of an open action.

In P2, you can create profiles, and IDs are checked for each request. However, the enforcement_status does not indicate any actions taken, and Anthropic does not reject P2 requests based on any open enforcement actions. Therefore, this article reads that the purpose of the user profile, which is that enforcement actions block only a single customer's requests, does not apply to P2 (Inference). The two sentences on the user profile page do not mention any specific timeframe. This article has not found any statements indicating that this behavior is expected to change (No statement found).

6.3 P5 Claude in Amazon Bedrock

Regarding P5, the user profile page describes the location of the ID, the format check, and the linking to an AWS account. There are no statements found that specifically mention Bedrock and detail how enforcement actions are reported or how requests are rejected based on those actions.

The statements in Section 6.1 concerning actions do not specify a particular path. The user profile page only explicitly mentions Claude Platform on AWS as an exception. Anthropic's Bedrock page states that P5 runs on AWS-managed infrastructure, and the user profile page does not connect this to actions. The user profile page does state, for Bedrock and Google Cloud (Google managed), that a request with no ID goes through unattributed and that an action it triggers applies to the whole organization (Section 3.3). There are no statements found that indicate whether the general statements about actions apply to P5 requests that carry an ID. This article does not state whether only one customer stops on P5 or not. Based on the documentation, this article can only conclude that P5 receives the ID.

6.4 Rejections on P1 and P2

By default, P1 and P2 only accept IDs on requests from the organization that created the profile and reject IDs from profiles created by other organizations with a 400 error. The user profile page states the following regarding scenarios with two organizations:

This means that if you send traffic under more than one organization, for example one on the Claude API and one on Claude Platform on AWS, a request from an organization that didn’t create the profile gets the same 400.

Message Batches are an exception. The user profile page states the following:

Message Batches is the exception: creating a batch checks only the ID’s format.

If a correctly formatted ID belongs to a different organization, the batch will be created, and each request in the batch will result in an errored result.

7. Layers That Decide the Unit of an Enforcement Action

This chapter outlines the layers involved in deciding the unit of an enforcement action, starting with Anthropic's organization, followed by AWS accounts, and then IAM.

The following diagram illustrates the relationship between these layers.

7.1 Organization and Workspace

The user profile page describes the workspace, providing a table outlining who should have a profile.

No separate profile. A profile belongs to your organization, and its ID works on requests through any workspace in it.

The same page also details the distinction between internal and end-customer usage.

Profiles belong to an organization, not a workspace, so separate workspaces in one organization aren’t enough.

Even when workspaces are segmented by customer, neither profiles nor the unit of enforcement actions are split. The user profile page specifies that requests for end customers should be directed to one organization, while your own usage should be directed to another.

The organization associated with the Claude API and the organization associated with Claude Platform on AWS are separate entities. As mentioned in Section 6.4, by default, P1 and P2 only receive IDs from requests originating from the organization that created the profile. Businesses that send requests from the same customer through both paths will need to create profiles for each organization. This is an inference of this article (Inference). The user profile page does not describe how to use IDs across organizations.

7.2 Bedrock Workspaces Are Not Anthropic Workspaces

The AWS Bedrock Workspaces page states:

Amazon Bedrock Workspaces provide application-level isolation for your generative AI workloads using the Anthropic-compatible Messages API on the bedrock-mantle endpoint.

Bedrock Workspaces are resources within your AWS account, used to separate applications for tracking usage, monitoring, and controlling access. The workspaces mentioned in two sentences in Section 7.1 regarding user profiles are workspaces within Anthropic's organization. No statement is found in either company's documentation describing the relationship between Bedrock Workspaces and user profiles (No statement found). This article does not state that dividing Bedrock Workspaces separates the unit of an enforcement action.

7.3 Linking Your AWS Account

The user profile page explains that you need to link your AWS account to the Anthropic organization that creates your profiles. The process involves three steps:

The organization administrator or owner should initiate the link in the Verification Portal at portal.anthropic.com, under Linked accounts.
An individual with IAM management access for your AWS account should execute the commands provided in the portal.
The organization administrator or owner should complete the verification process in the portal.

The user profile page further explains the purpose of linking as follows:

Programs that apply to a profile apply to an account’s requests only after the account is linked and the portal shows it as Linked.

This statement indicates that linking the account is the condition for programs applied to a profile to apply to that account's requests. It does not state that failing to link will prevent your P5 requests from being attributed. (No statement was found explicitly describing the relationship between linking and attribution.)

7.4 IAM for Claude Platform on AWS

Claude Platform on AWS requires IAM actions to manage user profiles. The IAM page lists six actions in the aws-external-anthropic namespace.

Action	Route
`CreateUserProfile`	`POST /v1/user_profiles`
`GetUserProfile`	`GET /v1/user_profiles/{id}`
`ListUserProfiles`	`GET /v1/user_profiles`
`UpdateUserProfile`	`POST /v1/user_profiles/{id}`
`DeleteUserProfile`	`DELETE /v1/user_profiles/{id}`
`CreateUserProfileEnrollmentUrl`	`POST /v1/user_profiles/{id}/enrollment_url`

The IAM page describes the scope of these six actions as follows:

The user profile actions are account-scoped, like ListWorkspaces. A statement whose Resource is a workspace ARN does not grant them; use Resource: "*".

This scope matters for configurations that separate workspaces on a per-customer basis. The IAM page provides an example that limits roles to a single workspace, noting that the workspace ARN condition silently filters out account-scoped actions. These excluded actions include user profile actions. The note continues, stating:

If the role needs user profiles or usage and cost reports, add a separate Allow statement for those actions with Resource: "*".

Roles limited to a per-customer workspace, as configured, cannot create or read user profiles.

The IAM page also highlights two additional points. First, the AWS managed policy AnthropicInferenceAccess permits Get* and List* actions, specifically allowing GetUserProfile and ListUserProfiles. Second, the wildcard aws-external-anthropic:*File matches actions ending in "File," and therefore also applies to CreateUserProfile, GetUserProfile, UpdateUserProfile, and DeleteUserProfile. A wildcard intended to permit only actions for the Files API may also inadvertently permit user profile actions.

The AWS Service Authorization Reference lists five actions: CreateUserProfile, CreateUserProfileEnrollmentUrl, GetUserProfile, ListUserProfiles, and UpdateUserProfile, but leaves the "resource type" column blank. DeleteUserProfile is not listed in the Service Authorization Reference (Documentation does not list). This article does not determine which documentation is correct.

To create the registration link for Claude Platform on AWS, a beta header is still required. The Verification Portal page states that for Claude Platform on AWS, you need to send a request to POST /v1/user_profiles/{id}/enrollment_url with the header anthropic-beta: user-profiles-2026-08-18.

8. Ways to Learn About Enforcement Actions

This chapter outlines the methods by which a business can determine that an enforcement action has opened.

8.1 The Number of `enforcement_status` Values Differs Between the User Profile Page and the API Reference

In the release notes for October 21, 2026, Anthropic added two fields, enforcement_status and enforcement_actions, to the user profile. The user profile page states that to receive these two fields, requests should be sent without a user-profiles- value in the anthropic-beta header.

Send these requests with no user-profiles- value in the anthropic-beta header, because user-profiles-2026-09-04 and earlier values leave the fields out.

The number of values for enforcement_status is different between the user profile page and the API reference.

Source	Values
User Profile Page	`unrestricted`, `restricted`, `banned` (3 values)
API reference	`unrestricted`, `pending`, `restricted`, `banned` (4 values)

The API reference describes pending as a status while a restriction that an identity check can clear is open, the end user has submitted that check, and Anthropic's review of it has not ended. This article does not determine which documentation is older. The user profile page describes how to handle unknown values as follows:

Anthropic can add values. Treat an enforcement_status you don’t recognize as restricted, a type you don’t recognize as restriction, a reason you don’t recognize as unspecified, and an action you don’t recognize as null.

By following this guidance, implementations that are not aware of the pending status will treat it as restricted.

enforcement_actions lists the open enforcement actions, each with a type, id, reason, action, opened_at, and expires_at. Profiles with open enforcement actions can be found using the API, specifying enforcement_status[]=restricted and enforcement_status[]=banned. The user profile page notes that the updated_at field may not always update reliably when enforcement actions change.

8.2 Organization Webhooks Are Not Sending Events

In the release notes for October 20, 2026, Anthropic added organization webhooks to the Admin API, using the webhooks-2026-10-07 beta header. These events consist of two types: user_profile.enforcement_action_opened when an enforcement action opens, and user_profile.enforcement_action_resolved when an enforcement action ends. The webhook page states, in a note at the top:

Event delivery isn’t live: Anthropic doesn’t send the two events, so an endpoint you register receives nothing.

The prerequisites listed on the webhook page are that the organization is using the Claude API, that organization webhooks are enabled, and that HIPAA readiness is not enabled. Access requires an application to Anthropic's account team. The page lists only the Claude API, in beta, as a supported platform. This article does not state that you will receive notifications regarding enforcement actions via webhook. The user profile page indicates that when no events are present, you should compare the two fields with their previous values.

8.3 What You Can Find Out on P2 and P5

In P2, the enforcement_status is always unrestricted (see Section 6.2). Reading the unrestricted status in P2 does not confirm that no enforcement action is open. In P5, profiles are created within organizations using either the Claude API or Claude Platform on AWS, so the location to read the enforcement_status is the organization that created the profile. No statement was found indicating whether an enforcement action opened on P5 requests is reflected in that organization's enforcement_status.

9. Where Sources Disagree, What the Documentation Does Not List, and Statements Not Found

This chapter summarizes matters that were not determined based on the available documentation.

9.1 Where Sources Disagree

The number of values for the enforcement_status field: 3 on the user profile page and 4 on the API reference (Section 8.1).
The number of IAM actions for user profiles: 6 on the IAM page and 5 on the Service Authorization Reference, which does not include DeleteUserProfile (Section 7.4). This article labels this as Documentation does not list.

9.2 Statements Not Found

This article describes information that could not be found after searching through Anthropic's documentation, AWS documentation, and the source code of Anthropic's Python SDK.

Whether the new models for InvokeModel (P3b) and the bedrock-runtime Messages API (P4) accept a user_profile_id. In the configuration in Chapter 10, only the format check was observed.
How enforcement actions are communicated in P5, and whether requests are rejected based on them. Whether the general sentence in the enforcement section applies to P5.
The relationship between AWS account linking and attribution.
The relationship between Bedrock Workspaces and user profiles.
The relationship between Bedrock request metadata and user profiles.
The rules regarding ID formats. The API reference only mentions that IDs begin with uprof_.
Planned changes to the handling of enforcement_status in Claude Platform on AWS.
Descriptions of user profiles in AWS documentation. These descriptions were not found after searching through four Bedrock pages and the "What's New" section.

9.3 Features in Beta

Organization webhooks. Uses the webhooks-2026-10-07 header; only organizations on the Claude API. No events are currently being sent.
Creation of a registration link for Claude Platform on AWS. Requires the user-profiles-2026-08-18 header.

For core user profile operations, the beta header is no longer required on API version 2026-10-21.

10. Observations from This Configuration

This chapter details the results of observing the responses received when sending requests with user profile IDs to three different paths within Bedrock, using a validation account. The observations do not override the documentation.

10.1 Configuration

In this article, requests were sent from a local script to three different paths within us-east-1, without creating any resources on AWS.

P5: https://bedrock-mantle.us-east-1.api.aws/anthropic/v1/messages
P4: https://bedrock-runtime.us-east-1.amazonaws.com/anthropic/v1/messages
P3b: InvokeModel for bedrock-runtime

The requests were sent between UTC 01:28 and 01:30 on November 5, 2026. They were signed using SigV4 and sent with the request body as written. The Anthropic SDK was not used, because its Bedrock Mantle client modifies the requests, as described in Section 5.1. The max_tokens value was set to 16.

The model used for P5 was anthropic.claude-opus-4-7. For P4 and P3b, the model was the inference profile us.anthropic.claude-opus-4-7. When sending the raw model ID to P4 and P3b, a 400 error was returned, saying that on-demand throughput is not supported. The anthropic-version header was set to 2023-06-01 for P5 and 2026-10-21 for P4. The initial request sent to P5 with the 2026-10-21 version exceeded the 60-second read timeout in the local script, and this article did not repeat that request.

For each path, an initial request without any IDs was sent, and it was verified that an HTTP 200 response was returned. Subsequently, two IDs were added to the top level of the request body and sent. One was a malformed ID, not-a-profile, and the other was the ID from the example of the user profile page, uprof_011CZkZCu8hGbp5mYRQgUmz9. On P5, a request was also sent with the malformed ID included only in the header.

10.2 Results

The following table summarizes the results of seven requests.

Case	Path	What Was Sent	Result
M1	P5	`not-a-profile` at the top level of the request body	400 `invalid_request_error`
M2	P5	The example ID from the user profile page at the top level of the request body	200
M4	P5	`not-a-profile` in the header only	200
R1	P4	`not-a-profile` at the top level of the request body	400 `invalid_request_error`
R2	P4	The example ID from the user profile page at the top level of the request body	200
I1	P3b	`not-a-profile` at the top level of the request body	400. The `x-amzn-errortype` header contained `ValidationException`.
I2	P3b	The example ID from the user profile page at the top level of the request body	200

The three rejections (M1, R1, and I1) returned the same error message.

user_profile_id: must be a well-formed `uprof_...` tagged ID

M1 and R1 returned it in Anthropic's error body format. I1 returned it in the InvokeModel error body format. The example ID used for M2, R2, and I2 is not a profile of this article's organization. Nevertheless, all three paths returned a 200 status code. This matches the user profile page's statement, for P5, that only the format is checked and the profile is not looked up. For P4 and P3b, no such statement was found (No statement found).

10.3 What This Configuration Does Not Show

Even if a request goes through, that does not prove that it was attributed. The 400 errors on P4 and P3b do not show that the unit of an enforcement action becomes one customer either. As the user profile page indicates, even if P5 returns a successful response, it cannot be verified that the ID matches the profile. This article did not send requests meant to trigger enforcement actions. Consequently, this article did not observe which requests, or through which paths, those actions ultimately reach.

11. Failure Modes

This chapter lists failures resulting from mixing up paths and layers.

Placing the ID only in the header on P5. The user profile page indicates that it should be located at the top level of the request body. The SDK's Bedrock Mantle client moves the ID; a custom gateway does not.
Migrating to P4 or P3b, following AWS recommendations, while maintaining the assumption that user profiles work. No statement was found on whether P4 and P3b accept user profiles. What the configuration in Chapter 10 observed is only the format check.
The system interprets a 200 response from P5 as confirmation that the ID is correct. P5 only performs format checks, allowing IDs with typos or for deleted profiles to pass through.
On Claude Platform on AWS, the system reads unrestricted and determines that no enforcement action is open. P2 always returns unrestricted.
The assumption is that if workspaces are separated by customer, enforcement actions will also be separated. Profiles belong to an organization.
An attempt is made to create profiles using roles specific to each customer's workspace. IAM actions for user profiles are not granted by a statement with a workspace ARN.
The wildcard *File for the Files API also permits actions related to user profiles.
The system repeatedly calls POST /v1/user_profiles on each retry, resulting in duplicate profiles for the same customer.
The ID of profiles created within an organization for the Claude API is attached to requests from the organization on Claude Platform on AWS. P2 rejects this with a 400 error.
The system registers with the organization's webhook, waiting for notifications regarding enforcement actions. No events are being sent.
The system treats Bedrock request metadata as a substitute for a user profile.

12. Frequently Asked Questions About Claude User Profiles and AWS Paths

12.1 If a user profile ID is attached, does an enforcement action on Bedrock stop only one customer?

The documentation does not say so. It does state that Claude in Amazon Bedrock accepts IDs, as indicated on the user profile page. However, there is no mention of how Bedrock specifically communicates enforcement actions or how they might be used to reject requests (see Section 6.3).

12.2 On Claude Platform on AWS, does an enforcement action reach a single customer?

The user profile page states that enforcement_status is always unrestricted, and that Anthropic will not reject requests due to any open actions (see Section 6.2). This article reads that the purpose of a user profile, which is that an enforcement action stops only a single customer, does not apply to Claude Platform on AWS (Inference).

12.3 Can the ID be sent in the header regardless of the path?

No. P1 and P2 receive the ID in the header, and P5 receives it at the top level of the request body. P3a does not work. For P3b and P4, no statement was found (see Section 4.2).

12.4 Does the `bedrock-runtime` Messages API support user profiles?

This is not explicitly confirmed in the documentation. While AWS is recommending bedrock-runtime for new applications, the user profile page states that, on Bedrock, user profiles work only with Claude in Amazon Bedrock (see Section 5.3). In the configuration in Chapter 10, the bedrock-runtime Messages API also rejected requests with malformed IDs with a 400 error (Observation). This does not show that attribution or enforcement actions work.

12.5 If workspaces are separated per customer, are enforcement actions also separated?

No. The user profile page states that a profile belongs to the organization, not to a workspace. No text was found describing the relationship between Bedrock Workspaces and user profiles (see Sections 7.1 and 7.2).

12.6 If the AWS account that uses Bedrock is not linked, are its requests left unattributed?

The documentation does not say this. However, the user profile page describes linking an account as a condition under which programs applied to the profile can apply to that account's requests (Section 7.3).

12.7 Does an enforcement action on requests without an ID always apply to the entire organization?

The user profile page describes requests without an ID with three sentences, each within a specific scope. The sentence that definitively states the action applies to the entire organization is found in the section for Google Cloud (Google managed) and Bedrock (Section 3.3).

12.8 Can you learn through a webhook that an enforcement action has opened?

Currently, it is not possible to determine when an enforcement action opens through webhooks. The webhook page indicates that it does not send events. You can either retrieve the profile or filter the enforcement_status using the list API (see Section 8.2).

13. Summary

User profiles are mechanisms that can apply enforcement actions not to an organization as a whole, but to a single end customer. The text on the user profile page uses "can."
The location of the ID varies depending on the path. For P1 (Claude API) and P2 (Claude Platform on AWS), it is in the header, while for P5 (Claude in Amazon Bedrock), it is at the top level of the request body.
The strength of the checks also differs. P1 and P2 check the ID on every request, while P5 only checks the format.
In P2, enforcement_status is always unrestricted, and Anthropic will not reject requests based on open actions.
The Bedrock path branches into three options. P5 accepts the ID, while user profiles do not work with the earlier integration (P3a). P3b and P4 are not settled by the documentation. In the configuration in Chapter 10, P3b and P4 also checked the ID format. AWS recommends using bedrock-runtime for new applications.
Profiles belong to an organization. Even if you divide workspaces, the unit of enforcement actions is not split. Bedrock Workspaces are separate from Anthropic workspaces.
For the user profile's IAM actions in Claude Platform on AWS, the scope is at the account level. Roles limited to individual workspaces cannot directly handle profiles.
The number of values for enforcement_status differs between the user profile page and the API reference. The organization's webhooks are not sending events.
When choosing a path or creating a gateway, verify your path's row in the table in Section 4.2.

14. References

References:
Tech Blog with curated related content

Written by Hidekazu Konishi