Anomity Integrates with the Anthropic Console
- Anomity now connects to the Anthropic Console. One read-only Admin key brings your Anthropic organization's workspaces, members and API keys into the Anomity inventory, with who created each key and whether the compliance activity feed is switched on.
- The headline finding is the unscoped admin-capable key: a key not bound to a workspace authenticates with the permissions of the account that created it, so an ordinary-looking key created by an admin can change members, workspaces and other keys.
- It also flags keys created by someone who has left the organization, keys with no expiry or older than 90 days, workspaces with more than two administrators, and a compliance activity feed that is off, or that the connected key cannot read.
- Three stricter checks ship switched off: workspaces with no data residency pinned, no deliberate retention setting, and no customer-managed encryption key.
- Endpoints an Admin key cannot reach by design, such as service accounts and workload identity federation, are shown as not collected, never as a coverage gap on a correctly configured organization.
- It shipped the same day as the OpenAI Platform connector, and is separate from Claude Enterprise, the plane where employees use Claude.
Anomity now integrates with the Anthropic Console. Connect your Anthropic organization with one read-only Admin key and Anomity brings its workspaces, members and API keys into your inventory, along with who created each key and whether the compliance activity feed has ever been switched on. The integration is available today from Settings, under Integrations, in the Anomity console, and it shipped alongside the OpenAI Platform connector.
This post covers what the connector reads, the finding it exists for, what it deliberately does not call a gap, and how setup works.
Why the Anthropic Console, and why now
An Anthropic API key has the same blind spot as an OpenAI one. It usually lives in a CI secret or on a server, so the Endpoint Sensor only sees the copies that land on developer machines, and the organization that issued it sits in Anthropic's tenancy, out of reach of the cloud connectors for Amazon Bedrock and Google Cloud Vertex AI, even when those clouds also serve Claude models. The Anthropic organization is the one place every key it issued is visible.
Anthropic also has a shape OpenAI does not: one Admin key reaches both the Administration API and the Compliance API's activity feed. So this is one connector covering both surfaces. It is separate from Claude Enterprise, which is the plane where employees use Claude at claude.ai, with a different key type and often a different administrator.
What the connector reads
| From Anthropic | What Anomity records |
|---|---|
| The organization | One row, carrying organization-wide facts: the number of members and workspaces, every API key's posture (keys are folded here, not listed as applications), whether the compliance activity feed is enabled and readable, and how many customer-managed encryption keys are registered. |
| Workspaces | One row per workspace, with its data residency and allowed inference geographies, its inference data retention setting, whether a customer-managed encryption key is attached, whether it is archived, and how many administrators it has. |
| API keys | For each active key: whether it has an expiry, how old it is, whether it is bound to a workspace, and who created it, joined against the member list. Archived and inactive keys cannot be used, so they are not judged. |
| Not collected | Service accounts and workload identity federation rules. Those endpoints need an org:admin OAuth token, which an Admin key cannot provide by design, so the row says 'not collected' rather than raising a gap. |
The finding this connector exists for
An Anthropic API key that is not scoped to a workspace authenticates with the full permissions of the account that created it. If that account is an organization admin or owner, the key can administer the organization: change its members, its workspaces and its other keys. In a list of keys it looks exactly like every other key. Anomity checks every unscoped key against its creator's organization role and raises unscoped admin-capable key on the organization, naming the keys.
It is the same lesson we keep returning to in our guide to non-human identity governance: a machine credential's real reach is set by the identity behind it, not by how it looks in a list.
What it flags
Anthropic posture runs through Anomity's cloud AI posture policy type, with a template for Anthropic Console key and workspace hygiene. Each check can be switched on or off per policy.
- Unscoped admin-capable key. As above. On by default.
- Key created by a former member. An active key whose creator is no longer in the organization, so nobody remaining is accountable for it. No switch, and raised only when the member list was actually read, so an unreadable directory never reads as everyone having left.
- Key with no expiry and key older than 90 days. The 90-day rotation interval is the control both Anthropic's and OpenAI's hardening guidance cite most.
- Workspace administrator sprawl. More than two administrators on one workspace. Each can change its members, keys and limits.
- Compliance activity feed off. The feed is off by default, per organization, behind a toggle in the Claude Console, so until somebody turns it on there is no record of who used Claude, from where, or when.
- Key cannot read the compliance feed. A different finding with a different fix: the feed may well be on, but the connected key was issued without the read:compliance_activities scope. Telling an admin to 'turn the feed on' would send them to a switch that is already on.
- Off by default: a workspace with no data residency pinned (which cannot be changed after the workspace is created, so fixing it means a new workspace), no deliberate inference retention setting, and no customer-managed encryption key. Most organizations would fail all three by design, so they are there for teams that want them.
- Discovery gap. Anything Anomity should have been able to read but could not.
There is no dormant-key check, unlike the OpenAI connector. The Administration API returns a key's creator but not its last use, and a finding that guessed at dormancy would claim something we did not read. For the rotation side of key hygiene, our write-up on the OpenCode console breach walks through what an inventory of provider keys buys you when one leaks.
How it authenticates
- In the Claude Console, go to Settings, Admin keys, and create an Admin key. It starts with
sk-ant-admin. To have Anomity read the compliance activity feed state, give it the read:compliance_activities scope. - If you want the activity feed, switch it on under Settings, Security in the Claude Console. Anomity reports it as a finding until you do.
- In Anomity, add an Anthropic Console connector and paste the key. A standard API key (
sk-ant-api) is rejected with a message saying why. - Test, then sync.
There is no federation option for the Administration API, so this is a stored key: it is encrypted at rest and the connector never calls a write endpoint. Revoking Anomity's access is deleting the Admin key in the Claude Console. Once connected, Anthropic gets its own board in the console, each finding traces from the source through the organization and workspace to the finding, and any policy can be scoped to Anthropic alone.
How Anomity and the Anthropic Console fit together
The Claude Console is where keys are created and revoked, workspaces are configured and the compliance feed is switched on. Anomity reads the result and tells you which of those decisions were never made: the admin-capable key nobody scoped, the key whose creator has since left, the feed that was never turned on. If you are weighing where activity records for Claude should live and who should hold them, our analysis of Anthropic's customer-held misuse monitoring covers the trade-offs.
The connector sits next to the OpenAI Platform, Claude Enterprise and the cloud AI connectors, all answering through one policy type. Around them, the Endpoint Sensor inventories agents, MCPs, extensions, plugins, skills, secrets, hooks, CLIs and local LLM runtimes on each managed device, including Claude Code; the Browser Sensor covers AI web services and whether the account in use 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 Anthropic organization, book a 30-minute demo.
Frequently asked questions
What does the Anomity Anthropic Console integration do?
It connects one Anthropic organization, the API organization you administer in the Claude Console, to Anomity's cloud discovery. It reads the organization, its workspaces and their members, organization members, API key metadata, customer-managed encryption keys, and whether the compliance activity feed is switched on and readable. It evaluates key and workspace hygiene through Anomity's cloud AI posture policy and raises findings in the Anomity console.
What credential does Anomity need?
One Admin key from the Claude Console (it starts with sk-ant-admin), created under Settings, Admin keys. A single Admin key reaches both the Administration API and the Compliance API's activity feed, so this is one connector for both. To read the activity feed state the key needs the read:compliance_activities scope. A standard API key is rejected. The key is stored encrypted and every call is a read.
What is an unscoped admin-capable key, and why is it the headline finding?
An API key that is not bound to a workspace authenticates with the full permissions of the account that created it. If that account is an organization admin or owner, the key can administer the organization: change members, workspaces and other keys. In a list of keys it looks like every other key, which is exactly why it is worth a finding of its own.
Why does Anomity say a key was 'created by' a former member rather than 'owned by'?
Because that is what the Administration API exposes. It returns a key's creator, not a current owner and not a last-used time, and the finding does not claim more than was read. That is also why there is no dormant-key check for Anthropic, unlike the OpenAI connector: there is no usage timestamp on the key to judge it by.
Why are service accounts shown as 'not collected'?
Service accounts and workload identity federation endpoints require an org:admin OAuth token, which an Admin key cannot provide by design. Being refused there is the documented, normal result of the credential we ask for, so it is recorded as a note. Reporting it as a coverage gap would put a discovery-gap finding on every correctly configured customer on day one.
Does Anomity read prompts or conversations?
No. The connector reads organization metadata: workspaces, members, key metadata and settings. For the compliance activity feed it checks whether the feed is switched on and readable, by asking for a single entry, and does not ingest the feed. It never calls a write endpoint.
How is this different from the Claude Enterprise connector?
Anthropic runs two planes. The Anthropic Console is the builder plane: API organizations, workspaces and API keys. Claude Enterprise at claude.ai is the plane where employees use Claude, with its own key type and its own administrators. Anomity has a separate connector for each, so a customer can hold one without the other and an outage on one never marks the other red.
Does Anomity replace the Claude Console's own controls?
No. Keys are created, scoped and revoked in the Claude Console, and the compliance feed is switched on there. Anomity reads that posture next to every other AI provider and cloud you connect, and adds the endpoint view: the agents, MCP servers, extensions, skills and secrets on each managed device, with allow, deny or log enforced at the agent hook before a tool call runs.
