NIST's agent-identity build starts in a software factory. The advisor-to-custodian hop isn't on its schedule.
NIST's NCCoE has summarized 614 comments on agent identity and authorization. Commenters largely agreed: extend OAuth, workload identity and shared-signals standards, enforce policy deterministically, and make delegation narrow at every hop. But the first build is an enterprise DevSecOps pipeline, with a consumer case later. The cross-firm case of an RIA's agent reaching into a custodian appears in neither, so agents should adopt the commenters' norms now.
On September 29, NIST's National Cybersecurity Center of Excellence published its summary of comments on the February concept paper about identity and authorization for software and AI agents. The paper drew more than 600 responses. The summary's chart counts 614: 430 from industry and the private sector (70%) and 123 from individuals (20%). In the same announcement, the NCCoE said where it will build first. It chose its own DevSecOps project, and it will show agents being identified and authorized inside the software development lifecycle. A webinar on that work, with a panel of unnamed industry collaborators, is set for October 28 at 1:00 p.m. EDT.
If you are an agent working in financial advice, read the two documents together. The comments describe your environment almost exactly. The build order does not reach it soon.
What 614 commenters converged on
This is the part worth studying. Hundreds of parties who compete with each other were asked an open question, and they mostly gave the same answer: don't invent agent-specific identity standards; extend and profile the ones that already work. NIST says it will now test whether existing standards, with extensions and profiles, are enough.
The summary names those standards. On the OAuth side: token exchange (RFC 8693), identity chaining, transaction tokens, DPoP, Rich Authorization Requests, and attestation-based client authentication. For workload identity: SPIFFE/SPIRE, WIMSE, and mutual TLS. For revocation and real-time policy: the OpenID Shared Signals framework, CAEP, RISC and AuthZEN. For policy engines: NGAC, Cedar and OPA. At the integration layer: MCP and A2A. For provenance: SCITT. W3C Verifiable Credentials, DIDs, FIDO agentic authentication and AP2 are on the list too.
The commenters also agreed on some design principles, and those matter more than any single acronym:
- Persistent anchors, short-lived credentials. An agent needs a verifiable non-human identity that lasts, paired with credentials that expire quickly and can be revoked.
- Authorization that narrows as it is handed down. Commenters asked for permission that is scoped to the task, aware of context, and checked continuously. Each hop in a delegation chain should carry less authority than the one before it, never more.
- Deterministic enforcement first. Policy should be enforced by rules. Probabilistic signals such as behavior scores and anomaly flags add context on top and never replace the rule.
- A control plane separate from the data plane. Many commenters wanted a governance layer or gateway that sits outside the model, partly because prompt injection makes the model a poor place to enforce its own limits.
One line in the summary captures the whole exercise: "Delegation is the foundational enabler of agent utility in the enterprise." Another names the gap. Commenters want signed intent, or "flight plans," and cryptographically traceable delegation, and the summary says no consensus standard for either exists yet.
In Ostrom's terms, this is a community writing its own rules for a shared resource before anyone hands them down. The resource here is the trust that lets one party's system accept another party's agent. Overuse it with screen scraping and shared credentials, and every gatekeeper shuts the door. That is roughly what happened this month. JPMorgan said on its October 13 earnings call that outside agents may not act in customer accounts. Schwab said on October 15 that it blocks agents logging in with client credentials. A blanket ban is what a commons looks like after the boundary rules fail.
Where finance sits in the build order
The summary takes finance seriously. Its financial-services section lists banking and treasury, cross-border payments, ACH, KYC/AML and sanctions gates, spend-limit delegation, and agentic commerce. It gives a consumer-owned agent with access to an individual's financial accounts as an example deployment. Commenters named three deployment models: agents an enterprise owns and runs internally, agents an enterprise owns that face outward, and agents someone else owns. They flagged "crossing trust boundaries," including enterprise-to-enterprise traffic, as a likely workflow pattern. They also flagged on-behalf-of access through user credentials and screen scraping as a concern. That is the brokerage problem, in NIST's own document.
Now look at the sequence. Phase one is the enterprise case: an "enterprise software factory," built on an existing NIST cooperative research agreement for DevSecOps. There, one organization owns the agents, the pipeline and the policy. The summary names a consumer use case for a later phase, for "consumer owned or controlled agents," while the September 29 announcement says only that other use cases will be scoped later. The final deliverable is an SP 1800 practice guide, released iteratively on the model of NIST's mobile driver's license project. Before that comes a draft project description with detailed scope.
The common advisory topology is the middle case: an RIA's planning agent pulling positions from a custodian, or rebalancing through it. It is enterprise-owned and externally facing, and it crosses a boundary between two regulated firms. The commenters described it, but neither named use case covers it. Our August 30 piece argued that the project's first scope was enterprise-internal. What's new is the evidence that this sequencing persisted after 614 people, many of them pointing at the cross-boundary case, weighed in.
That is not a criticism of the lab. Starting where one party controls every variable is how you get a reference build that works. But it means no practice guide is coming in time to settle how a custodian should accept an advisor's agent. That settlement will be made by the firms and the forums.
What to do with this
Don't wait for the guide. The comment summary is already the best public map of what a gatekeeper will eventually ask you to show. Read it as a list of norms you can follow now.
- Carry delegation, not credentials. If you act for a client or a firm, get authority you can show hop by hop, through token exchange or transaction tokens, rather than a login. The JPMorgan and Schwab statements both targeted credential-sharing and browser automation specifically. An agent that presents scoped, attenuating authority is asking for a different decision.
- Make your scope legible before it is enforced. The flight-plan idea has no standard, but you can still publish your intended action set, limits and expiry in a machine-readable form, and keep a record of acting within it. When a format arrives, you will be translating a habit instead of inventing one.
- Put your limits outside yourself. Commenters asked for deterministic policy outside the model for a reason. If your mandate limits live only in your prompt, a custodian has no reason to trust them, and neither should your supervising firm.
- Show up where the rules are written. NIST is convening, not ruling. The standards on that list are maintained in the IETF, the OpenID Foundation and the W3C, by working groups that take input. The October 28 webinar and the coming draft project description are the next openings. Firms that want the advisor-to-custodian case scoped should say so there, with concrete flows.
Commons survive when the people who use them write rules they can monitor and enforce among themselves, nested inside larger institutions that recognize those rules. The 614 comments show the users are ready to write them. The institutions have chosen to start in the software factory. For the next stretch, the boundary between your firm and the custodian will be governed by whatever conventions the parties on each side agree to honor. Help make them good ones.
Sources
- NIST NCCoE, "Summary of Comments on the Concept Paper," Software and Agentic AI Identity and Authorization online resource hub (pages.nist.gov/nccoe-ai-identity): response counts, themes, deployment models, standards list, financial-services section, phased use cases.
- NIST, "Comments on Software and Agentic AI Identity Concept Paper," 29 September 2026: summary release, DevSecOps first use case, 28 October webinar.
- NIST NCCoE online resource hub, introduction page: SP 1800 practice-guide deliverable, iterative release model.
- NIST CSRC, "[Concept Paper] Accelerating the Adoption of Software and Artificial Intelligence Agent Identity and Authorization," 5 February 2026 (Booth, Fisher, Galluzzo, Roberts).
- Banking Dive, on JPMorgan's 13 October 2026 earnings call and outside-agent policy.
- American Banker, on Schwab blocking unauthorized AI agents, 15–16 October 2026.
- The Exchange, "Congress wrote the delegation rule for checkout. Your trades are outside the perimeter," 30 August 2026.