Last updated: September 2026
Shadow AI agent discovery is an inventory problem, not a new authentication protocol. On 22 September 2026, at Oktane, Okta announced Shadow AI Agent Discovery for Endpoints, extending a capability its Identity Security Posture Management product already had through a CrowdStrike Falcon connector. Keycloak has no equivalent scanner and is unlikely to grow one, because an agent that never calls your identity provider leaves no trace inside it. What Keycloak does own is the chokepoint: any agent that touches your APIs needs a client and a token, and that is where an inventory can actually be enforced. The practical split is that endpoint tooling finds agents on machines, and your identity layer decides which ones get to do anything.
We covered the vendor landscape and why discovery is the genuine Keycloak gap in the 2026 agentic IAM roundup. This post is the narrower follow-up: what Okta actually added, which Keycloak signals a real inventory is built from, and where the boundary sits.
What does “shadow AI” mean when you own the identity layer?
Shadow AI is the same shape as shadow IT, one layer up: software running against company data without going through procurement, review, or any inventory. The term now covers two distinct things that behave very differently, and conflating them is where most governance plans go wrong.
The first is consumer-grade AI use, someone pasting a customer list into a chatbot. That is a data-loss problem, and it belongs to a CASB, a browser extension, or a DLP product. Your identity provider never sees it, because no token is involved.
The second is agents that hold credentials. A coding agent with a service account, an internal MCP server issuing tokens, a workflow bot with a client secret someone generated eight months ago. These are non-human identities, and they are squarely yours.
The distinction that matters: an agent with no credential is a data-governance problem. An agent with a credential is an identity problem, and it will show up in your logs whether or not you inventoried it.
The reason this matters for planning is that “we need shadow AI discovery” usually gets budgeted as one project, then splits into two the moment someone asks which system is supposed to do the finding.
What did Okta announce at Oktane 2026?
Okta used the opening day of Oktane, on 22 September 2026, to widen its AI agent tooling. SiliconANGLE, in “Okta adds AI agent runtime gateway, forms Blueprint Alliance with AWS and CrowdStrike” (22 September 2026), reported that Shadow AI Agent Discovery for Endpoints looks for unmanaged agents running on employee laptops and desktops.
This is an expansion rather than a first move. Okta’s own help documentation describes Identity Security Posture Management discovering AI agents on managed endpoints through a CrowdStrike Falcon connector, covering locally installed agents, which MCP servers are active, who installed each agent and on which device. Endpoint coverage existed before Oktane, which is worth knowing if you are comparing roadmaps rather than headlines.
Several pieces landed alongside it. Per the SiliconANGLE report, Agent SSO, Agent-to-Agent Connections and Resource Access Certifications are generally available, while Agent Gateway and the endpoint discovery feature were presented as planned, with a Configuration Designer and a gateway kill switch behind them. Okta also announced the Blueprint Alliance, whose founding members are Okta, AWS, CrowdStrike, Databricks, Docker, Google Cloud, Lovable, Proofpoint, Salesforce, ServiceNow, Wiz and Zscaler, aimed at a shared reference architecture for securing agents.
The structural point underneath all of it is that endpoint discovery requires an endpoint presence. No identity provider, Okta’s or anyone else’s, finds a local agent by reading its own token logs, which is why this capability arrives through an endpoint connector rather than through the directory.
What can Keycloak see, and what is genuinely invisible to it?
Keycloak sees every agent that authenticates, and nothing else. That is a real limitation, though the visible half is larger than teams expect, because an agent that cannot call anything is not much of a risk.
Concretely, Keycloak 26.x gives you four things worth building on:
- Clients and service accounts. Any agent doing machine-to-machine work needs a confidential client with a service account. That record is your inventory row, whether or not you treat it as one. Our machine-to-machine authentication guide covers the flow itself.
- Client attributes. Keycloak lets you attach arbitrary attributes to a client. Nothing enforces them, which is why conventions have to be enforced in your provisioning pipeline instead.
- Events, in two separate streams. Login-type events such as
CLIENT_LOGINandCLIENT_REGISTERrecord authentication and dynamic registration. Admin events separately record create, update and delete operations on resources likeCLIENT,CLIENT_ROLE_MAPPINGandCLIENT_SCOPE_MAPPING. Both are in the 26.7.4 source, and you need both, because they cover different paths. - Token lifetimes and scopes. Whatever an agent is allowed to do, it does with a token you issued, for a window you chose.
What Keycloak genuinely cannot see is any caller that never reaches it. A local agent hitting an external model API with a personal key is invisible. So is one using a static API key your application validates itself, which is a good argument for moving those behind OAuth in the first place. Our post on API keys versus OAuth covers when that trade is worth making.
Our take: the gap between “agents on the network” and “agents in Keycloak” is not a blind spot in Keycloak. It is a measure of how much of your agent traffic still bypasses your identity layer. Closing that gap is more valuable than scanning for it, because an inventoried agent you cannot revoke is not much better than an unknown one.
How do you build an AI agent inventory in Keycloak?
Start from the assumption that the inventory is the client list, then make the client list carry enough information to be useful. The case for one client per agent is made in the agentic IAM roundup; what follows assumes you have accepted it.
Give every agent client an owner before it reaches production
Keycloak does not ship an ownership model for clients, so you add one with attributes: an owning team, a human contact, a review date, and a flag marking the client as an agent rather than a conventional service. Enforce it where clients get created, in Terraform, in the operator, or in whatever provisioning script you use, because Keycloak itself will happily accept a client with no attributes at all.
The payoff arrives during an incident. An owner attribute turns a 2am investigation into a message to the team that runs the thing.
Stop issuing standing credentials to agent workloads
A client secret that never rotates is the agent equivalent of a shared admin password. Prefer short token lifetimes, and where the client can hold a key, prefer private_key_jwt over a static secret. For agents that act for a specific user rather than for themselves, token exchange keeps the user’s identity attached to the call instead of flattening everything into one service account. We walk through the agent-facing patterns in authenticating AI agents with Keycloak, and the cross-application case in cross-app access and ID-JAG for AI agents.
If you run MCP servers, the same logic applies at the server boundary rather than the agent: see securing MCP servers with Keycloak and OAuth 2.0.
Alert on the three signals that indicate drift
Most agent sprawl shows up as one of three events, and all three are available without buying anything. Note which stream each one lives in, because a pipeline that only ships login events will miss half of this:
| Signal | Where it shows up | Why it matters |
|---|---|---|
| A client you did not provision | CLIENT_REGISTER login event for dynamic registration, plus an admin event with operation CREATE on resource type CLIENT for the admin API and console |
The two creation paths are recorded in different streams |
| A scope or role added to an agent client | Admin events on CLIENT_ROLE_MAPPING and CLIENT_SCOPE_MAPPING |
Agent permissions tend to accumulate without review |
| Token volume jumping on one client | CLIENT_LOGIN event counts, which fire on client-credentials grants |
A loop, a leak, or a new workload nobody mentioned |
Keycloak’s event system can forward all of this off-box, which is where it becomes useful. We documented the pipeline in forwarding Keycloak events to a SIEM, the broader event model in the Keycloak auditing guide, and Skycloak surfaces the same streams through audit logs.
When something does go wrong, revocation granularity matters more than it does for humans, because killing every session for a shared service account takes down more than the offending agent. That problem is covered in revoking a single Keycloak session.
When do you still need an endpoint scanner or a CASB?
You need one when the risk you care about lives on the laptop. If your worry is an employee running a local coding agent against a personal model subscription, with company source code as input, no amount of realm hygiene helps. Nothing about that transaction touches your identity provider.
That is the real case for what Okta announced, and it is a fair one.
The inverse is also true, and it is the part vendors are quieter about. Discovery tells you an agent exists. It does not, by itself, stop the agent from doing anything. Enforcement still happens where the credential is issued and where the API is called, which for most teams means the identity provider and the gateway in front of their services. A discovery rollout that is not paired with credential hygiene produces a documented list of agents you still cannot control.
For teams running Keycloak, including on managed Keycloak like Skycloak, the sequencing that tends to work is unglamorous: get every agent onto a client with an owner, get lifetimes down, wire both event streams to something that alerts, and only then go shopping for endpoint visibility on the residue.
Frequently asked questions
Which Keycloak signals show an AI agent I did not register?
Three, across two streams: CLIENT_REGISTER login events for dynamically registered clients, admin events with operation CREATE on the CLIENT resource type for anything made through the admin API or console, and CLIENT_LOGIN volume changes on existing clients. A caller that never requests a token produces none of them.
Does dynamic client registration make shadow agents more likely?
It can, because it allows a client to be created without an administrator opening the console. If you enable it, restrict it with initial access tokens or a trusted-hosts policy and alert on CLIENT_REGISTER. Many realms have no reason to expose it at all, in which case leaving it off is the simpler control.
What is the difference between shadow IT and shadow AI?
Shadow IT is unsanctioned software and services. Shadow AI is the subset involving AI models and agents, and it splits again: ungoverned model use is a data-loss problem, while agents holding credentials are an identity problem. The second kind is visible to your identity provider, the first usually is not.
Is Okta’s Shadow AI Agent Discovery for Endpoints available now?
As reported by SiliconANGLE on 22 September 2026, it was described as planned at announcement, alongside Agent Gateway, while Agent SSO, Agent-to-Agent Connections and Resource Access Certifications were generally available. Endpoint discovery through the CrowdStrike Falcon connector was already documented before Oktane. Check Okta’s release notes before planning around either.
What should I inventory first?
Confidential clients with service accounts, sorted by token volume. High-volume clients with no named owner are where the risk concentrates, and the list is usually shorter than teams expect, which makes it a realistic first pass rather than a quarter-long project.
Sources
- SiliconANGLE, “Okta adds AI agent runtime gateway, forms Blueprint Alliance with AWS and CrowdStrike,” 22 September 2026, https://siliconangle.com/2026/09/22/okta-adds-ai-agent-runtime-gateway-forms-blueprint-alliance-with-aws-and-crowdstrike/
- Okta, “Endpoint AI agent discovery,” Okta Help Center, https://help.okta.com/en/programs/ai-agents/content/topics/ai-agents/endpoint-ai-agent-discovery-through-crowdstrike.htm
- Okta, “Identity Security Posture Management adds AI agent discovery for every customer,” Okta blog, https://www.okta.com/blog/identity-security/okta-ispm-ai-agent-discovery/
- Keycloak,
EventTypeandResourceTypeat release tag 26.7.4, https://github.com/keycloak/keycloak/releases/tag/26.7.4