Keycard as Agent Integration Catalog
Keycard
The real moat here is not token issuance, it is becoming the default place where agent access gets packaged, approved, and discovered. Identity provider catalogs became sticky because every new app made the platform more useful to admins, and every new enterprise customer made it more valuable for app vendors to integrate. A Keycard marketplace could work the same way, if SaaS vendors publish pre-scoped agent connectors and enterprises adopt them instead of building one-off policies for every tool.
-
In identity, the catalog matters because it turns messy custom setup into a searchable menu of prebuilt options. Okta says admins browse the OIN catalog for app integrations, and Microsoft positions its app gallery the same way, as a place customers can quickly find verified integrations. That distribution loop is what Keycard is trying to recreate for agent access.
-
The workflow is concrete. A SaaS vendor would publish a connector that says which agent can call which API actions, under what scopes, with what consent and audit trail. That mirrors the OAuth delegation model used by Google style identity servers, and it fits the shift Stytch describes, where more apps now need fine grained delegated access for agents, not just human login.
-
Comparable infrastructure vendors show why this can compound. WorkOS sells one integration that supports dozens of identity providers, which reduces implementation work for developers. If Keycard becomes the normalization layer for agent credentials across many SaaS apps, each additional connector lowers adoption friction for the next buyer and the next software vendor.
The next step is a land grab for the agent app directory. The winning product will not just verify agents, it will define the default connector templates, review workflow, and policy surface that enterprises trust. If Keycard gets there early, the marketplace becomes both a revenue layer and the control point for how agent access is turned on across SaaS.