Anomity Integrates with Claude Enterprise

Anomity now integrates with Claude Enterprise. Connect your tenant with one read-only API key created in claude.ai and Anomity brings your linked organizations, members, roles and directory groups into your inventory, with members outside your email domains flagged. The integration is available today from Settings, under Integrations, in the Anomity console. The key it asks for cannot read chats, files or session transcripts.

This post covers what the connector reads, why the key is scoped the way it is, what it flags, and where its current limits are.

Why Claude Enterprise, and why now

Anthropic runs two planes. The builder plane is your API organization, which the Anthropic Console connector reads: workspaces, API keys and who created them. Claude Enterprise is the other one, the plane where employees use Claude at claude.ai. It has its own key type, its own administrators and its own question, which is not 'which keys exist' but 'who is in this tenant, and is it set up the way we think'.

Anomity's Browser Sensor already answers part of that from the device side: it sees sign-ins to Claude on managed devices and whether the account is corporate or personal. What it cannot see is the tenant's own directory: the contractor's personal address someone invited, the linked organization nobody remembers creating, the group provisioned from your identity provider. That view only exists on Anthropic's side.

The card has been in the console as 'coming soon' since the vendor-organization connectors arrived, because no response from the Compliance API had been observed. Anthropic has since published the full reference: key creation and scopes, pagination, response schemas and the error catalog. We checked the connector against it, fixed what a first customer would have hit, including member lists that would have stopped after the first page, and opened it to customers.

A key that cannot read conversations

The most important design decision in this connector is a scope it does not ask for. Listing an organization's users through the Compliance API needs read:compliance_user_data, and that scope also reads every chat, file and session transcript in the tenant. An integration that only wants a member list should not hold that.

So the setup asks for three read-only scopes, read:compliance_org_data, read:compliance_activities and read:members, and reads members from the Admin API member list instead. With that key, 'Anomity does not read your conversations' is enforced by Anthropic, not just promised by our code. A broader key still works; the content endpoints are simply never called.

What the connector reads

Two of those notes deserve a second look in most tenants. Claude Code's bypass-permissions mode is the setting that lets an agent run tools without asking, which we unpacked in what --dangerously-skip-permissions really skips. And a compliance key that can read or delete content is a credential with reach into every conversation, worth knowing about even when it belongs to your own archiving tool.

What it flags

Claude Enterprise runs through Anomity's cloud AI posture policy type, with a template for Claude Enterprise workspace governance.

• Members outside your domains. People from outside your own email domains are members of the tenant, so company conversations and uploaded files are reachable by accounts your directory does not govern and your offboarding does not touch. The addresses are named on the organization. Subdomains of a listed domain count as yours. With no domains listed, the check is skipped and the row says so.
• Compliance activity feed not readable. The connected key cannot read the activity feed, so there is no record available of who used Claude, from where, or when. Scopes are fixed when a key is created, so the fix is a new key rather than a setting change, and the note says that.
• Discovery gap. An organization, member list or other fact Anomity should have been able to read but could not.

The external-member check is the same question, with the same sentence, that Anomity asks of an Atlassian organization. 'Who in this AI tenant is not one of us' is one question, and a customer should answer it once rather than once per vendor. It pairs with the identity-provider side: if your directory lives in Microsoft Entra, the group rows show which Claude groups are provisioned over SCIM from your identity provider and which were created by hand.

How setup works

1. On a Claude Enterprise plan, the primary owner turns on the Compliance API in claude.ai, under Organization settings, API.
2. On the same page, the primary owner creates an API key with read:compliance_org_data, read:compliance_activities and read:members. It starts with sk-ant-api01-.
3. In Anomity, add a Claude Enterprise connector, paste the key and list your email domains. A Console Admin key (sk-ant-admin01-) or a Claude API key (sk-ant-api03-) is refused before it is stored, in the browser and again on the server.
4. Test. The result reports organizations, the activity feed and members separately, and names any missing scope, since a missing scope is the likeliest setup mistake and cannot be fixed on an existing key. Then sync.

The key and the domain list can be edited on the connected card, so rotating the key does not mean deleting the connector. Errors are mapped to what an admin should actually do: a key Anthropic did not authenticate and a Compliance API that is not enabled each get their own message, and a rate-limited request is retried once after the wait Anthropic asks for.

Current limits

The connector follows Anthropic's published reference and its error handling was checked against the live API before shipping. The limits are at the edges, and we would rather name them:

• No production tenant had completed a sync when it shipped. Field names come from Anthropic's documentation, and anything we cannot read degrades to a note, never to a false finding.
• Several linked organizations share one member list. The Admin API lists members tenant-wide and cannot split them by organization, so they are reported once, on the first organization, with a pointer on the others, rather than raising the same finding once per organization.
• Settings are notes, not findings. Until the settings response has been observed from a live tenant, Anomity shows it and does not judge it.
• Anthropic enables the settings endpoint per tenant. Where it is not enabled yet, the organization row says so and that it is not a gap in your configuration.

How Anomity and Claude Enterprise fit together

Claude Enterprise is where SSO, SCIM, roles, retention and the compliance feed are configured, and it stays that way. Anomity reads the directory and the settings and puts them next to everything else you connect: the Anthropic Console and OpenAI Platform API organizations, the OAuth grants AI apps hold in Google Workspace, and the cloud AI platforms. Tenant governance is only half of the picture; the other half is what people paste into it, which we covered in what employees actually paste into ChatGPT, Claude and Copilot, and the MCP connectors the tenant reaches, which we covered in enterprise-managed MCP connectors.

Around the connector, the Endpoint Sensor inventories Claude Code and every other agent, MCP, extension, plugin, skill, secret, hook, CLI and local LLM runtime on each managed device; the Browser Sensor sees Claude sign-ins and whether the account is corporate or personal; and on agents that expose a hook, such as Claude Code's PreToolUse, Anomity decides allow, deny or log before a tool call runs. Findings route to the SIEM, Slack or Jira. Anomity collects metadata only, redacts secret values on the endpoint, and is SOC 2 Type II attested. To see it against your own Claude Enterprise tenant, book a 30-minute demo.