Anomity Integrates with the OpenAI API Platform
- Anomity now connects to the OpenAI Platform, the builder side of OpenAI at platform.openai.com. One read-only Admin key brings your projects, service accounts and API keys into the Anomity inventory, with who owns them and how they are governed.
- These are the credentials that usually live in a build pipeline or on a server, never on a laptop, and in OpenAI's tenancy rather than your cloud account, so neither the Endpoint Sensor nor the cloud connectors could see them before.
- Findings: API keys with no expiry, keys older than 90 days, keys not used in the last 30 days or never, keys owned by someone who has left the organization, service accounts with no recorded creator, and an organization with no spend limit. A model allowlist check ships switched off.
- Keys are folded onto their project rather than listed as applications, and a finding names the offending keys, so one policy failure is one ticket rather than one per key.
- Every call is a read. The key is stored encrypted, and an application key pasted by mistake is rejected with a message saying why.
- It shipped the same day as the Anthropic Console connector, and both feed the same cloud AI posture policy as Amazon Bedrock, Azure AI Foundry and Google Cloud Vertex AI.
Anomity now integrates with the OpenAI Platform. Connect your OpenAI organization with one read-only Admin key and Anomity brings its projects, service accounts and API keys into your inventory, along with who owns them and how they are governed. The integration is available today from Settings, under Integrations, in the Anomity console, and it shipped alongside its Anthropic sibling, the Anthropic Console connector.
This post covers what the connector reads, what it flags, how it authenticates, and one check we removed before shipping because the data behind it did not exist.
Why the OpenAI Platform, and why now
An OpenAI API key is one of the most common credentials in a modern engineering estate, and one of the least visible. It usually lives in a CI secret, a server's environment or a deployment config rather than on a managed laptop, so Anomity's Endpoint Sensor only sees the copies that leak onto developer machines. And the project that issued it lives in OpenAI's tenancy, not in your cloud account, so the cloud connectors for Amazon Bedrock, Azure AI Foundry and Google Cloud Vertex AI never reach it either. The organization that issues the keys is the only place to see all of them at once.
The card is named OpenAI Platform, never just 'OpenAI', on purpose. Azure AI Foundry also serves OpenAI models, and OpenAI itself runs two separate planes: the builder plane at platform.openai.com, where projects, keys and service accounts live, and the ChatGPT workspace where employees chat, which has its own console, its own credential and often its own admin. This connector reads the builder plane only, so an outage on one plane never marks the other red.
What the connector reads
Everything below comes from the OpenAI Administration API, and every call is a GET.
| From OpenAI | What Anomity records |
|---|---|
| The organization | One row, carrying organization-wide facts: the number of members and admin keys, the number of projects, whether a spend limit is configured, and how many keys had recorded activity in the last 30 days. |
| Projects | One row per project, with its model permissions (an allow list or deny list, and how many models it names), its data residency, its members, and the key posture of every API key inside it. |
| Service accounts | One row per service account, with the project it belongs to and who created it, where OpenAI records that. |
| API keys | Not rows of their own. Each key is folded onto its project, and a finding names the offending keys. A key is not an AI application, and a row per key would both bury the inventory and fan one policy failure out into one ticket per key. |
What it flags
OpenAI posture runs through Anomity's cloud AI posture policy type, with a template for OpenAI Platform key and project hygiene. Very little of the cloud vocabulary applies here: an OpenAI organization has no invocation logging switch, no content filter and no region. So rather than force those sentences onto it, every check below has wording of its own.
- API key with no expiry. It stays valid until somebody remembers to revoke it, which is how a key outlives the person or service that created it.
- API key older than 90 days. The rotation interval both OpenAI's and Anthropic's hardening guidance names.
- Dormant API key. Enabled, but never used or not used in the last 30 days, read from the key's own last-used timestamp. An unused credential is attack surface with no offsetting benefit.
- Key owner has left. The key's owner is no longer a member of the organization. This one has no switch: a live key belonging to someone who has left is not a matter of policy taste. It is only raised when the member list was actually read, so an unreadable directory never orphans every key in the org.
- Service account with no recorded creator. Nobody is accountable for what it does or whether it is still needed.
- No spend limit. A leaked key can spend without any ceiling. Raised once, on the organization, and only when OpenAI answers that no limit is configured; a read that failed is a coverage gap, not an 'uncapped' finding.
- No model allowlist. A project that can call any model the organization can reach. Off by default, because most projects have none.
- Discovery gap. Anything Anomity should have been able to read but could not.
The spend limit check is the one we would turn on first. Stolen model keys are monetized by running inference on the victim's bill, a pattern we covered in LLMjacking: stolen-key cost abuse, and a ceiling is what turns an unlimited bill into a bounded one. The rotation and ownership checks follow the same playbook we laid out after the OpenCode console breach: know which provider keys exist, who owns them, and when they were last used, before you need to rotate them in a hurry.
The check we removed
An early version of the connector raised 'data retention not set deliberately' on projects. Testing against a live organization showed the OpenAI project object has no retention field at all; it carries data residency, which is where inference runs, not how long anything is kept. Reading a missing field as a finding would have flagged every project in every organization for something we never read, so the check was deleted. Residency is shown as a note on the project instead. The same live testing confirmed that keys do return their own last-used time, which is why dormancy is read directly rather than guessed from spend data.
How it authenticates
Anomity's AWS, Google Cloud and Azure connectors hold no secret at all. The OpenAI Administration API offers no federation option, so this connector does need a stored key, which is exactly why it asks only for read access.
- In the OpenAI console, go to Settings, Admin keys, and create an Admin key with the permission Read all Administration API resources.
- In Anomity, add an OpenAI Platform connector and paste the key. It starts with
sk-admin-. The organization ID field is optional and only used to label findings. - Test, then sync. A project key (
sk-proj-) pasted by mistake is rejected with a message that says so, and a refused request names the two likely causes: a key without Administration API permission, or an IP allowlist blocking the caller.
The key is stored encrypted, and nothing in the connector calls a mutating endpoint. Revoking Anomity's access is deleting the Admin key in the OpenAI console.
Once connected, OpenAI gets its own board in the console, and every finding shows its full path: the source, the organization, the project and the finding itself. Any policy over a connected source can be scoped to OpenAI alone, so a rule written for your OpenAI organization never fires on your Google Workspace grants.
How Anomity and the OpenAI Platform fit together
OpenAI's console is where keys are created, scoped, limited and revoked, and it stays that way. Anomity reads the result: which keys exist, which have no expiry or no owner, which nobody has used in a month. An API key used by a pipeline is a non-human identity like any other, and the governance questions in our guide to non-human identity governance apply to it unchanged: who owns it, can it be rotated, and can it be turned off.
The connector sits next to the Anthropic Console for the Anthropic API, Claude Enterprise for the plane where employees use Claude, and the cloud connectors from AWS Bedrock to Cloudflare, 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, the Browser Sensor covers AI web services including ChatGPT and whether the account in use is corporate or personal, and on agents that expose a hook 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 OpenAI organization, book a 30-minute demo.
Frequently asked questions
What does the Anomity OpenAI Platform integration do?
It connects one OpenAI organization to Anomity's cloud discovery using the OpenAI Administration API. It reads the organization's projects, the service accounts and API keys in each project, project members and model permissions, organization members, admin keys, the spend limit, and a 30-day usage window. It then evaluates key and project hygiene through Anomity's cloud AI posture policy and raises findings in the Anomity console.
What credential does Anomity need from OpenAI?
An organization Admin key (it starts with sk-admin-), created in the OpenAI console under Settings, Admin keys, with the permission 'Read all Administration API resources'. The Administration API has no federation option, so unlike Anomity's AWS, Google Cloud and Azure connectors this is a stored secret. That is why read-only matters: every call the connector makes is a GET, and the key is stored encrypted. Revoking access is deleting the Admin key in OpenAI.
Does this cover ChatGPT?
No. OpenAI runs two planes with two consoles, two credentials and two admin populations. This connector reads the builder plane at platform.openai.com: projects, keys and service accounts. The ChatGPT workspace your employees chat in is administered separately and is not read by this connector. Employee use of ChatGPT on managed devices is covered by Anomity's Browser Sensor.
How does Anomity decide a key is dormant?
From the key's own last-used timestamp, which the Administration API returns. A key that has never been used, or was last used more than 30 days ago, and is still enabled is flagged. It is not inferred from spend data, so an organization whose usage endpoint refuses Anomity does not end up with every key reported as unused.
Why is there no data retention check?
Because the OpenAI project object has no retention field. A project carries its data residency, which is where inference runs, not how long anything is kept. We checked the shape against a live organization before shipping, and inventing a retention finding from an absent field would have flagged every project for something we never read. Residency is shown as a note on the project.
Does the integration change anything in OpenAI?
No. It never calls a write endpoint. Findings are raised in Anomity and routed wherever your other findings go: the SIEM, Slack or Jira.
What if part of the organization cannot be read?
Each read beyond the project list is individually non-fatal and reported. If the member list cannot be read, key ownership is marked 'not checked' rather than reporting every key as orphaned. If the spend limit cannot be read, it is a coverage gap, not an 'uncapped' finding. The IP allowlist is not exposed by the Administration API at all, so the organization row says it was not checked rather than implying it was.
Does Anomity replace OpenAI's own admin controls?
No. OpenAI's console is where keys are created, scoped, limited and revoked. Anomity reads that posture alongside every other AI provider and cloud you connect, and adds what no vendor console sees: 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.
