Standards watch: delegated access and agent identity

A workflow ledger rather than another standards matrix

The existing standards article explains why a sourced claim is not a verified integration. This watch takes a narrower approach: placing the current claims at the points where a buyer would need to test them. A registration mechanism can help establish how a client becomes known. An identity mechanism can identify a workload. A delegated access mechanism can connect an authorising context to a resource request. None of those labels alone proves a policy decision at every tool invocation.

The resulting ledger should retain the named mechanism, the party making the claim and the workflow boundary. A buyer can then ask what evidence would establish the next step rather than treat a collection of acronyms as a complete architecture. The sources support specific claims about registration, delegated access and unique agent identity. They do not justify filling an undocumented link simply because the adjacent steps have familiar standards names.

Registration additions have a defined scope

The Okta post dated 22 October 2026 states that AI Agent Registration with CIMD and Multi-Source Agent Schema are generally available. It also states general availability for MCP Server Registration with Dynamic Client Registration, the MCP Server Catalog and Multi-MCP Custom Auth Servers. Those are concrete registration and server-management additions. The source should be read at that scope rather than turned into a statement that every registered client receives the same runtime controls. [f3]

The same post names import integrations for Cursor, Snowflake, Databricks, Workato and Tines. A buyer can use those names to form an integration checklist, while asking separately how imported metadata is reconciled with locally registered records. The evaluation should establish which component holds the agent record, which server is being registered and which authorisation server issues the relevant grant. A successful registration step is necessary evidence for that workflow, not evidence that every later tool request has been mediated. [f3]

Delegated access claims need a complete exchange

The NewCore source describes Enterprise-Managed Authorization and an Identity Assertion JWT Authorization Grant, identified as ID-JAG, obtained during SSO and exchanged at each MCP server. The sourced record treats this as a vendor claim. The product’s description of specification status and its list of implementers are not verified. This is sufficient to discuss the claimed delegation path, but not to assert universal adoption, final standard status or tested interoperability. [newcore-ema]

The buyer should ask to see the original authorising context, the assertion or grant presented for exchange and the resource-specific access that results. The important comparison is whether that context survives to the server that performs the requested operation. NewCore remains a governance layer alongside the existing IdP, not a replacement for it. The product’s claimed exchange should therefore be evaluated as part of a workflow with that provider and the destination servers, with the exact supported configuration made explicit. [newcore-ema] [newcore-c5-1]

The watch does not expand an unsupported label

This watch covers cross-app access as a topic, but the sources cited here do not establish a separate cross-app access specification or an implementation claim under that name. The two announcements do not state a protocol relationship, availability state or vendor support for the phrase. A buyer can retain it as an open evidence question while comparing the documented registration and exchange mechanisms above. This avoids converting a topic heading into an unsupported standards fact.

The same discipline applies when two mechanisms appear in one architecture diagram. Their proximity is not evidence that a given platform implements the same flow, accepts the same assertion or preserves the same delegation context. The worksheet should quote the mechanism named in the cited vendor source, then list the missing exchange evidence. A future sourced update can resolve that gap without forcing the present comparison to imply compatibility that has not been documented.

The separate role of unique agent identity

The Google Cloud source dated 22 October 2026 describes Agent Compute Engine assigning each agent a unique SPIFFE-based identity. It also describes Agent Registry as a central repository of approved agents, tools, MCP servers, skills, models and endpoints. These are relevant identity and governance facts, but a unique agent identity should not be treated as proof of a user-on-behalf delegation chain or proof that an unknown agent has been discovered. [f8]

The source also describes Agent Gateway governing client-to-agent and agent-to-anywhere traffic, with additional capabilities coming in preview this quarter. Google's post gives only a relative quarter, with no fiscal or calendar basis. A buyer should separate the identity claim, the approved registry population and the stated preview additions in its notes. Each can matter to a deployment without implying that the other two answer the same question or share an identical availability state. [f8]

Design tenets guide the test without certifying it

The NIST post dated 27 October 2026 proposes ten design tenets as a starting point and guideposts for demonstrations. It is not a product certification. The tenets address distinct identification, delegation, least privilege, short-lived authorisation, human triggers, mandates, separation of policy from reasoning, deterministic decisions, monitoring and immutable evidence. The detailed reporting also notes that existing standards and technologies may not support every tenet. [f1] [f1-detail]

The undated Okta checklist maps its product to those tenets. The source remains undated here and should not acquire an invented publication day. A buyer can use the design guidance to ask sharper questions about a documented protocol flow without treating a vendor mapping as a conformance result. The resulting review should preserve both the claimed mechanism and the unresolved deployment test. [f4]

• The registration test records how the client or server becomes known.
• The identity test records which distinct agent principal is represented.
• The delegation test follows the authorising context to the resource exchange.
• The enforcement test checks the decision before the requested action executes.

What readers ask