Identity-provider agent additions in October 2026

A dated change log rather than a platform replacement guide

The identity-provider context page is the broad reference for these features. This article narrows the task to what the October sources add and how a buyer should record their status. A new identity type, a newly available registration mechanism and a preview gateway addition are different changes. A dated comparison should retain those differences instead of treating all three as equivalent production controls.

The evaluation can keep an existing IdP in place while asking whether a particular agent workflow needs more inventory context, delegated access or action-level governance. That is especially important when the identity-provider announcement and a specialist platform describe different boundaries. The buyer should first establish what the existing provider supplies, then test any remaining requirement. The presence of a new agent feature does not by itself establish coverage of every runtime, tool or approval path.

The registration additions from the October post

The Okta post dated 22 October 2026 adds import integrations for Cursor, Snowflake, Databricks, Workato and Tines. It states that Multi-Source Agent Schema and AI Agent Registration with CIMD are generally available. These facts belong in a registration and inventory change log. They identify specific new ways to bring agent records into the platform rather than establish that all unregistered agents throughout an estate have been found. [f3]

The same post states general availability for the Okta Integration Network MCP Server Catalog, MCP Server Registration with Dynamic Client Registration and Multi-MCP Custom Auth Servers. A buyer should map those additions to the servers and authorisation arrangements it intends to use. The useful test is whether the target workflow can register the correct server, retain the relevant agent metadata and use the intended authorisation configuration. The announcement is a starting point for that test, not a substitute for exercising it. [f3]

The September baseline and its stated availability

The earlier Okta announcement dated 22 September 2026 states that Agent SSO, Agent-to-Agent Connections and Resource Access Certifications were generally available that day. It describes Agent Gateway and Shadow AI Agent Discovery for Endpoints as planned for general availability in Q3. Configuration Designer and expanded Kill Switch capabilities at the runtime layer were planned for Q4. The source does not specify whether those quarter labels are fiscal or calendar. [f2]

Okta records these as planned states, and a later Okta source would be needed to show any change. Agent Gateway is described as sitting between agent and tool call, enforcing policy and logging interactions at runtime. That architectural description does not convert its planned availability into confirmed availability. The registry also retains Human-in-the-Loop and task-level intent as roadmap items. The buyer should record an explicit deployment confirmation rather than infer completion from the passage of time or from an unrelated October addition. [f2] [f4]

The additional agent patterns and shared context

The Microsoft post dated 19 October 2026 describes an expansion of Entra Agent ID to additional agent patterns. These include local agents and previously unknown agents discovered through security sensors. It introduces Project Perception, sharing signals, context and a unified registry with Microsoft Agent 365, together with new Playbooks and Guardian Agents. The post summary refers to capabilities in Microsoft 365 E7. [f7]

The held facts do not verify prices or availability dates for those additions. A comparison should therefore retain the descriptive change without adding a procurement entitlement or a delivery deadline. The practical follow-up is to ask which patterns are supported in the proposed environment, how a sensor-discovered agent becomes a managed identity record and where the shared context appears in an investigation. Those are questions for validation, not further product behaviour established by the current source. [f7]

The stated governance scope for unique identities

The Google Cloud post dated 22 October 2026 introduces Agent Compute Engine and extends agent governance across its runtimes, other clouds, on-premises environments and client devices. It states that each agent receives a unique identity based on SPIFFE. Agent Registry is described as a central repository of approved agents, tools, MCP servers, skills, models and endpoints. The approved population should not be conflated with a claim to discover every unknown agent. [f8]

The post describes Agent Gateway governing client-to-agent and agent-to-anywhere traffic. The additional capabilities, including token and cost governance, model routing policies, extensible policies and simpler agent-to-tool connectivity, are coming in preview this quarter. The comparison should preserve that relative timing and preview qualification, rather than assign a new general-availability date. A buyer can then test identity assignment, registry use and gateway policy as related but separate parts of the proposed workflow. [f8]

The governance layer alongside the IdP

The NewCore record positions it as an agent governance layer alongside the existing IdP. The product’s documentation describes per-action checks and human approval, while the sourced interview describes session- and task-specific identities and an audit trail distinguishing policy approval from human approval. These are relevant when the buyer needs to examine how an identity-provider workflow connects to an action decision. They do not make NewCore an identity-provider replacement. [newcore-c3-1] [newcore-c7-1] [n1]

The NewCore announcement also claims continuous discovery of unregistered agents, task-scoped credentials and immediate revocation. The product’s product record retains limits, including direct command-line tool calls outside the MCP gateway and no published list price. A buyer should test the required workflow and request the commercial details separately. The later Okta collaboration headline is not used here to infer additional features or terms; the held record verifies only its headline and date. [n2] [newcore-c8-1] [f6]

• The change log keeps the source date separate from an availability date.
• The status field preserves generally available, planned, preview and roadmap wording.
• The workflow field identifies registration, identity, discovery or action enforcement.
• The follow-up field records the specific deployment question still unanswered.

What readers ask