Tenant restrictions changedgovernment/tenant-admin/tenant-restrictions

Nearest release: v2.1.224, published 3 hours after upstream edited the page. Shown because the two are within 24 hours of each other. Nothing here says the release caused the edit.

Upstream edited this page at 6 Aug 2026 22:10 UTC, give or take a minute or two: the time comes from Anthropic’s own sitemap rather than from a commit. This site recorded the change at 20 Oct 2026 18:07 UTC.

Upstream edited 6 Aug 2026 22:10 UTC

Recorded here 20 Oct 2026 18:07 UTC

Lines+6added

Lines−6removed

From line 27 where the diff opens

First seen 14 Aug 2026 this site's first read of the page

Recorded edits2to this page, all time

The whole hunk

from line 27, old and new numbered

lines

from line 27

2727

2828The same check applies at sign-in, so a user signing in to a tenant that is not on the list sees the refusal at the sign-in screen rather than after authentication completes.

2929

30<Note>

31 A tenant restriction can only narrow access. A user still needs valid credentials for a tenant on the list; the header never grants access to a tenant the user does not already belong to.

32</Note>

30> [!NOTE]

31>

32> A tenant restriction can only narrow access. A user still needs valid credentials for a tenant on the list; the header never grants access to a tenant the user does not already belong to.

3333

3434## Configure your network proxy

3535

from line 38

38381. **Remove** any `Anthropic-Allowed-Tenant-Ids` header that arrived from the client.

39392. **Set** a single `Anthropic-Allowed-Tenant-Ids` header to your allowlist value.

4040

41<Warning>

42 Your appliance must remove the incoming header before setting its own. If the appliance only appends, ordinary traffic still works, so the misconfiguration is not obvious. A client that supplies its own value can then reach the server with both values, which either bypasses the restriction or causes that client's requests to fail, depending on how the appliance merges the two. Most secure web gateway products have a distinct "set" or "overwrite" action that removes and replaces in one step; use that rather than "append" or "add".

43</Warning>

41> [!WARNING]

42>

43> Your appliance must remove the incoming header before setting its own. If the appliance only appends, ordinary traffic still works, so the misconfiguration is not obvious. A client that supplies its own value can then reach the server with both values, which either bypasses the restriction or causes that client's requests to fail, depending on how the appliance merges the two. Most secure web gateway products have a distinct "set" or "overwrite" action that removes and replaces in one step; use that rather than "append" or "add".

4444

4545Apply the rule to requests for the Claude for Government domains provided to you during onboarding, as well as your agency's own custom domain if you have one. Because Claude for Government is served over HTTPS, your appliance must perform TLS inspection for these hosts so that it can add the header to the encrypted request.

4646