Anomity Integrates with Okta for AI Agents
- Anomity now connects to Okta (in beta). The connector reads the AI agents registered in Okta for AI Agents, the API service apps and API tokens that act without a person, the custom authorization servers that issue machine tokens, and the AI applications in the Okta SSO catalog.
- It then does the part only an endpoint view can do: it joins Okta to the fleet. If people sign in to an AI vendor's tools on managed devices and no Okta application covers that vendor, those sign-ins sit outside SSO, MFA and offboarding, and Anomity raises it as a finding.
- Findings land in the same policy engine as the rest of Anomity: client secrets on agents and service apps, agent connections and authorization-server policies that allow every scope, API tokens owned by a super administrator or older than 90 days, and AI vendors used on the fleet with no Okta app.
- Setup uses private_key_jwt. Anomity mints a keypair, the customer registers the public key on an Okta API Services app, and every call is a read. No Okta secret is ever handed to Anomity, and revoking access is deleting the key in Okta.
- It works with or without the Okta for AI Agents subscription. Without it, the agent rows stay empty and everything else still runs.
- Okta answers which agents have an identity and how they are governed. Anomity answers what is actually running and signed in on every managed device. Put together, they answer the question neither can alone: which AI on the fleet is outside the identity plane.
Anomity now integrates with Okta. Connect an Okta org and Anomity reads the AI agents registered in Okta for AI Agents, the machine identities and API tokens that act without a person, and the AI applications behind Okta single sign-on, then joins all of it to what is actually running on your managed devices. The integration is available today in beta, from the discovery connectors page in the Anomity console.
This post explains what the connector reads, what it finds, how it authenticates, and why we think the most useful thing an endpoint platform can do for an identity provider is tell it what it is missing.
Why Okta, and why now
Customers keep asking us the same question about identity: what does Anomity do with Okta? The honest answer used to be a card in the console that said 'coming soon'. It is not a question about single sign-on for the Anomity console. It is a question about agents, and it got sharper the moment Okta shipped a first-class registry for them.
Okta for AI Agents gives AI agents an identity in the same Universal Directory that holds people. Okta describes the lifecycle in four moves: find and register agents, with a verified identity and a human owner; govern them with least-privilege policies on each connection and access reviews; control their access at runtime; and stop a rogue agent with a kill switch and a full audit trail. Agents built on other platforms can be imported, and Okta lists AWS Bedrock AgentCore among them. It makes Okta one of the first identity providers to treat agents as principals in their own right, alongside Microsoft's Entra Agent ID, and it is the right direction. We made the same argument from first principles in our guide to non-human identity governance: an agent that can act needs an owner, a credential you can rotate and a way to be turned off.
A registry has a boundary, though, and the boundary is registration. The agents in Okta are the ones somebody registered. The coding agent a developer installed on Monday, the MCP servers wired into it, and the AI vendor accounts people signed in to from the browser do not register themselves. That is the half of the picture Anomity's sensors already hold, and joining the two is the point of this integration.
What the connector reads
Everything below comes from read-only Okta API scopes, and every call is a GET.
| From Okta | What Anomity records |
|---|---|
| AI agents in Okta for AI Agents | One row per agent: its lifecycle state (staged, active or inactive), how its linked application authenticates, and the resources it is connected to. The agent providers Okta imports from, such as AWS Bedrock AgentCore, are recorded too. |
| API service apps | One row per machine identity, with how it authenticates (client secret or private key) and every Okta API scope granted to it. Those grants are scored by the same scope-risk model that rates Google Workspace and GitHub OAuth grants, so an app holding a .manage scope stands out. |
| API tokens | Folded onto the org row rather than one row each, every token named with its owner: tokens owned by a super administrator, tokens older than 90 days, and tokens usable from any network. |
| Authorization servers | One row per custom authorization server, flagged when a policy open to all clients grants any scope to a machine grant type. |
| The SSO catalog | The AI applications behind Okta single sign-on, named by vendor, with how many people are assigned to each. Assignment is not sign-in, and the row says so. |
The fleet join: AI that signs in outside Okta
Okta knows which applications are behind single sign-on. Anomity knows which AI tools people are actually signed in to, on every managed device: the Endpoint Sensor sees the accounts behind agents and CLIs, and the Browser Sensor sees sign-ins to AI web services, including whether the account is corporate or personal. Put the two lists side by side and the gap is a finding.
If thirty laptops are signed in to an AI coding tool and there is no application for that vendor in Okta, those are thirty accounts outside SSO, outside MFA policy and outside offboarding. When someone leaves, Okta deprovisions everything it knows about, and that account is not one of them. Anomity raises it on the Okta org row, naming the vendor and the number of devices, sorted by reach. It is the same 'SSO bypass' problem identity teams already track, evidenced from the endpoint rather than inferred.
Two details keep the signal clean. The join works per vendor, not per tool, because an interactive coding agent is not a workload principal and 'this agent is not registered in Okta' would be true on every fleet and mean nothing. And it counts only hosted accounts: a local model runtime or an API-key setup is inventoried elsewhere in Anomity, but it is not something Okta could have put behind SSO, so it does not inflate the gap.
The second half of the join compares remote MCP servers configured on managed devices against the resources Okta agents are connected to, and flags the servers no registered agent covers. It switches on once Okta's resource connections name MCP servers, which is exactly the inventory gap we described in how to build an MCP server registry.
What it flags
Okta posture runs through Anomity's agent identity policy type, with a seeded template, Okta AI agent and API credential posture, that applies only to Okta rows. Each check can be switched on or off per policy.
- Static client secret. An agent's linked application, or a service app, authenticates with a client secret instead of a key. A secret is a copyable bearer credential; a key pair is not.
- Connection or policy allows every scope. An agent resource connection that allows all scopes, or an authorization-server policy open to all clients that grants any scope to a machine grant.
- MCP resource not approved. An agent connected to an MCP server that is not on the organization's MCP allowlist in Anomity.
- Super administrator API token. A token that carries every permission its owner has, with no proof of possession.
- Aged API token. A token older than 90 days.
- Unrestricted API token. A token usable from any network. Off by default, because most orgs never set a network zone.
- AI vendor without SSO and MCP server without an Okta agent. The two halves of the fleet join.
- Discovery gap. A read the credential should have been able to make, but could not, so a silent gap never reads as a clean org.
Findings route to the SIEM, Slack, email or Jira like every other Anomity finding. An org without Okta for AI Agents is not penalised for it: that tier is a note, never a discovery gap.
How it authenticates: no Okta secret leaves your org
We could have asked for an Okta API token, which is what most integrations ask for. We did not, for the same reason the connector flags them: an API token is a bearer secret tied to one person, it carries every permission that person has, and if that person is a super administrator, so is every system holding the token.
- In Anomity, add an Okta connector with your org URL. Anomity generates an RSA keypair, stores the private key encrypted, and shows you the public key.
- In Okta, create an API Services app, set client authentication to public key / private key, and add the public key.
- Grant the read scopes the connector lists, assign an administrator role, and paste the app's Client ID back into Anomity.
- Test, then sync. Anomity signs a short-lived assertion for each access token, and handles apps that require DPoP proof of possession without extra setup.
Revoking Anomity's access is deleting the key from the app in Okta. Rotating it means minting a fresh pair in Anomity and registering the new public key in Okta. The Okta for AI Agents scope is optional, so an org without that subscription connects the same way.
What beta means here
We verified the connector end to end against a real Okta org before shipping it. Beta is a statement about the edges, and we would rather name them:
- Okta's AI Agents API is itself in beta. We read it as Okta returns it today and will follow it as it changes.
- Agent owners are not exposed by Okta's API yet. The owner and orphaned-agent checks therefore report 'not checked' instead of raising findings, and start working without a release if Okta adds the resource.
- Some shapes have not been seen with real data, such as an MCP server on an agent resource connection. Each is read tolerantly and degrades to a note, never a false finding.
- Custom Okta domains are not accepted yet; orgs on okta.com, oktapreview.com and okta-emea.com are.
How Anomity and Okta fit together
Identity and isolation are different controls, as we argued in the AI agent containment gap, and neither is the whole answer. Okta is the identity plane: it issues the identities, enforces who and what may access which resource, and owns the kill switch. Anomity covers the endpoint, where agents actually run: the Endpoint Sensor inventories agents, MCPs, extensions, plugins, skills, secrets, hooks, CLIs and local LLM runtimes; the Browser Sensor covers AI web services and the accounts used in them; and cloud discovery now reads Okta alongside the OAuth grants held by AI applications in Google Workspace and GitHub. On agents that expose a hook, Anomity decides allow, deny or log before a tool call runs.
The integration is where those two views meet. Okta tells you which agents have an identity. Anomity tells you which AI is running and signed in across the fleet. The difference between the two lists is the work, and now it is a finding with a vendor, a device count and an owner. Anomity collects metadata only, redacts secret values on the endpoint, and is SOC 2 Type II attested. To see it against your own Okta org and fleet, book a 30-minute demo.
Frequently asked questions
What does the Anomity Okta integration do?
It connects one Okta org to Anomity's cloud discovery and reads four things: the AI agents registered in Okta for AI Agents and how each one authenticates, the API service apps (machine identities) and the Okta API scopes granted to them, API tokens and who owns them, and the custom authorization servers whose policies issue machine tokens. It also lists the AI applications in the Okta SSO catalog with their assignment counts. Anomity then joins that picture to what its Endpoint and Browser Sensors see on managed devices, and raises findings through the same policy engine that covers the rest of the platform.
What is Okta for AI Agents?
Okta for AI Agents is Okta's product for giving AI agents an identity. Okta describes a lifecycle that runs from discovering and registering agents, with a verified identity and a human owner, through governing their access with least-privilege policies and access reviews, to controlling access at runtime and stopping a rogue agent with a kill switch. Registered agents live in Okta's Universal Directory alongside people, and Okta can import agents from other platforms such as AWS Bedrock AgentCore.
Do I need the Okta for AI Agents subscription to use the integration?
No. Every Okta org has applications, API service apps, API tokens and authorization servers, and the connector reads all of those through the standard Okta Management API. The AI agent registry is an optional tier: if the org does not have Okta for AI Agents, the connector records that as a note on the org, the agent rows stay empty, and the rest of the sync completes normally.
What is the fleet join?
It is the comparison only an endpoint view can make. Okta knows which applications are behind single sign-on. Anomity knows which AI tools people are actually signed in to on managed devices, from the Endpoint Sensor and from the Browser Sensor. When people use an AI vendor's tools on managed devices and no active Okta application resolves to that vendor, those accounts sit outside SSO, MFA and offboarding, and Anomity raises a finding on the Okta org that names the vendor and the number of devices. The check is per vendor on purpose: an interactive developer tool is not a workload principal, so 'this coding agent is not an Okta AI agent' would be true on every fleet and tell you nothing.
What credentials does Anomity need from Okta?
None that leave your Okta org. When you add the connector, Anomity generates an RSA keypair and shows you the public key. You create an API Services app in Okta, register that public key on it, grant read-only Okta API scopes, assign an administrator role, and paste the app's Client ID back into Anomity. Anomity signs a short-lived assertion with its private key to obtain each access token. We chose this over an Okta API token on purpose: an API token is a bearer secret tied to one person and carries every permission that person has. To revoke Anomity's access, delete the key from the app in Okta.
Does the integration change anything in Okta?
No. Every scope is a read scope and every call the connector makes is a GET. Anomity reads posture and raises findings in its own console, routed wherever your other findings go: the SIEM, Slack, email or Jira.
Why is the integration in beta?
Partly because Okta's own AI Agents API is in beta on Okta's side, and partly because some shapes could not yet be verified against real data. Okta does not currently expose agent owners through its API, so the owner check is reported as not checked rather than raised as a finding. Okta orgs on custom domains are not accepted yet. We verified the connector end to end against a real Okta org, and every field it could not verify degrades to a note rather than a false finding.
Does Anomity replace Okta, or Okta's own agent discovery?
No. Okta is the identity plane: it issues the identities, enforces the access policies and owns the kill switch. Anomity complements it the way it complements the network, EDR, DLP and GRC stack, by covering the endpoint: the agents, MCP servers, extensions, skills, hooks, secrets and local runtimes on each managed device, the AI services used in the browser, and policy enforced at the agent hook before a tool call runs.
