Ghost in the Org Chart

937 Comments and One Uncomfortable Consensus

The US government asked the industry how to secure AI agents. The answers should worry every CISO in financial services.

When 937 people submit formal comments to the federal government about the same problem, something interesting tends to happen. Not agreement, exactly. Consensus is too generous a word for how Washington works. But something closer to convergence: a slow, reluctant admission from across the ecosystem that the emperor’s wardrobe is thinner than anyone has been willing to say publicly.

In January 2026, NIST’s Center for AI Standards and Innovation published a Request for Information on security considerations for AI agent systems (Docket NIST-2025-0035). Not chatbots. Not co-pilots. Specifically, systems capable of taking autonomous actions that affect external state: initiating transactions, modifying records, interacting with third-party services. The RFI closed on March 9 and drew responses from identity platforms, AI providers, academic researchers, defence policy organisations, open-source foundations, and regulated enterprises.

On May 18, NIST published its summary analysis as NIST 800-5. The headline finding is worth stating plainly: respondents widely agreed that AI agents present novel security threats, that these threats are a barrier to adoption, and that existing cybersecurity principles, while relevant, will require significant adaptation to address what agents actually do.

That last phrase is doing a lot of work. “Require adaptation” is the polite version. The blunt version, repeated across submissions in different vocabulary, is that the security and governance infrastructure the enterprise technology industry has spent decades building was designed for a fundamentally different operating model. And nobody has rebuilt it yet.


What NIST asked

The RFI was organised around five categories: threats and vulnerabilities unique to agents, security practices for development and deployment, assessment methods, deployment environment controls, and areas where government action could help. NIST flagged priority questions for respondents with limited bandwidth, a signal that they expected volume and wanted to channel it.

They got both. The 937 responses came from an unusually broad cross-section: identity infrastructure companies, AI model providers, academic security researchers, national security policy groups, financial services firms, open-source protocol foundations, legal and economic policy centres. When that many actors from that many angles point at the same cracks, the cracks are probably real.


Where the comments converged

Three themes appeared across nearly every substantive submission. Each points to a different layer of the problem. Together, they make a structural argument that regulated industries need to take seriously now.

The identity gap is the primary vulnerability.

The OpenID Foundation framed this with precision: the most urgent AI agent security risks are not primarily technical failures in the model layer, but failures of trust infrastructure. The inability to verify credentials automatically, constrain permissions to what a specific task requires, and trace accountability back to the authorising human principal. The argument is about infrastructure, not model safety. And identity practitioners, security architects, and AI developers all arrived at it independently.

Persona’s response went further, recommending that agents be treated as distinct security principals, bound to verified human or organisational sponsors with explicit consent and enforceable permissions. Their framework proposes scoping delegation by action, counterparty, amount, time, and context, with cryptographic verifiability and revocability. A separate individual submission from AI governance researcher Brianna Baynard proposed a Non-Human Identity Disclosure standard, mandating a technical gate that blocks an agent from receiving or soliciting sensitive personal information until it has transmitted a verified identity token. As agents increasingly interact with KYC workflows and client-facing processes, this is a concept financial services firms should be tracking.

NIST’s own National Cybersecurity Center of Excellence published a companion concept paper in February proposing a demonstration project across four areas: identification, authorisation, access delegation, and logging. The project references OAuth 2.0/2.1, OpenID Connect, SPIFFE/SPIRE, and NIST SP 800-207 (Zero Trust Architecture) as starting points. The question it addresses is deceptively simple: how do you know which agent is acting, on whose authority, and with what permissions?

Most enterprises cannot answer that question today.

Existing compliance frameworks are structurally misaligned.

The Foundation for Defense of Democracies called for NIST to update SP 800-160 and SP 800-218 specifically for agentic AI, and to expand the MITRE ATLAS framework to cover agentic kill-chain tactics, reasoning-layer attacks, and multi-agent lateral movement. Their concern: current threat frameworks do not model agentic attack patterns at sufficient granularity for detection engineering or purple-team exercises. Security teams are running playbooks designed for a different adversary model.

Princeton’s Center for Information Technology Policy contributed a distinct angle: reliability failures as a security threat even in the absence of an adversary. Agents pursuing goals in unintended ways when success metrics are underspecified create integrity risks that resemble insider threats rather than classic exploits. You do not need a malicious actor when the agent’s own behaviour can produce the same effect.

The Gravitee State of AI Agent Security 2026 Report found that only 14.4% of organisations report their AI agents going live with full security approval. The overwhelming majority of agents are launching without complete oversight. That gap mirrors what happened in early cloud and API security adoption, but with far greater downstream authority delegated to the system.

For financial services specifically, the compliance misalignment runs deeper. SR 26-2, which replaced SR 11-7 on April 17 after 15 years, pushes toward risk-based model governance tailored to an institution’s operational complexity. DORA’s ICT risk management requirements are now in force across EU financial entities. The EU AI Act’s high-risk AI obligations apply from August 2026. None of these frameworks were designed for a world where an orchestrating agent delegates to sub-agents that interact with live systems at machine speed, and where the validation problem moves from pre-deployment to runtime.

“Soft” guardrails are insufficient, and everyone knows it.

Multiple respondents drew a sharp distinction between prompt-level policy and infrastructure-level control. Guardrails implemented purely through prompting or lightweight policy layers can be bypassed by persistent or cleverly structured inputs.

Shapor Naghibzadeh, CEO of QueryStory and former engineering lead for AI-powered security operations at Google Cloud, recommended in his submission (NIST-2025-0035-0154) treating all model outputs as untrusted data, applying zero-trust principles at the infrastructure layer rather than relying on model-level instructions. His framing: enforce security at the database, query engine, network egress, and rendering environment level. If the infrastructure itself cannot prevent the unwanted action, a prompt instruction certainly will not.

This maps directly to what practitioners have been debating in the field. An agent can have scoped identity, least privilege, every pre-action guardrail in the playbook, and still execute a perfectly authorised action on a corrupted premise. The guardrails pass. The outcome is wrong. That is the gap that infrastructure-level controls are meant to close, and that prompt-level policy cannot reach.


Two supply chain attacks, two different lessons

This convergence is not happening in a vacuum. Early 2026 produced two distinct categories of AI supply chain compromise, and the distinction between them matters for how enterprises think about their defensive posture.

The Mercor/LiteLLM breach, which this publication covered in April, was a conventional supply chain attack with an AI-era amplifier. Attackers compromised a library maintainer’s credentials, published malicious package versions, and credential-harvesting malware propagated across thousands of environments within 40 minutes. The mechanism was familiar: compromised human credentials, poisoned dependency, cascading exposure. What made it structurally different was the interconnectedness of the AI ecosystem. One library present in roughly 36% of cloud environments. Multiple competing AI companies sharing the same data vendor. Synchronised failure across the industry.

The Cline CLI compromise in February was something else entirely. Documented in detail by Snyk and the Cline team’s own post-mortem, this attack did not exploit compromised human credentials or standard CI/CD misconfigurations. An attacker submitted a public GitHub issue containing a prompt injection payload hidden in the title text. The repository’s automated issue triage agent, processing the issue as part of its normal workflow, executed the embedded instructions. The agent, operating with CI/CD access tokens, poisoned the build cache, extracted npm publishing credentials, and published a compromised version of the CLI to the public registry. Approximately 4,000 developer systems downloaded the malicious release during an eight-hour window before it was caught.

The Clinejection Lesson

The attack surface was the decision-making logic of an active AI agent. The agent read an instruction and executed a tool. It worked exactly as designed. The vulnerability was the absence of an infrastructure-level boundary between natural language parsing and high-privilege tool execution.

For enterprises evaluating their AI supply chain risk, these two incidents require different defensive responses. Mercor-style attacks are addressed through dependency pinning, software composition audits, and credential hygiene. Clinejection-style attacks require something more fundamental: architectural separation between what an agent reads and what it is allowed to execute, regardless of what the input tells it to do.


The Telemetry Paradox

The International Center for Law & Economics submitted a response that surfaced a problem most governance conversations have not yet touched.

Securing agent systems requires deep operational telemetry: logging prompts, tool calls, retrieved context, intermediate reasoning steps, and external effects. Without this data, security teams cannot build behavioural baselines, detect privilege escalation, or reconstruct incident chains. The compliance case for comprehensive logging is straightforward. The legal picture is murkier. ICLE’s submission identified a structural conflict between the telemetry required for agent security and existing communications privacy statutes, specifically the Electronic Communications Privacy Act and the Stored Communications Act. Agent telemetry captures communication content. Depending on the deployment context, that capture may implicate wiretapping restrictions, consent requirements, data minimisation obligations, and cross-border regulatory constraints.

The Telemetry Paradox

Firms need visibility into what their agents are doing, but the legal framework for capturing that visibility is ambiguous at best and prohibitive at worst. The result is rational underinvestment in security observability.

This paradox is particularly acute in financial services, where communications retention obligations (under FINRA, MiFID II, and the SEC’s recent enforcement actions around non-compliant messaging) already require extensive capture infrastructure. When agents begin acting on, within, and through communications channels, the question of what constitutes a “communication” requiring retention becomes significantly more complex. An agent that reads a client message, reasons over it, invokes a pricing engine, and returns a quote has generated a chain of actions that spans multiple regulatory categories. The retention and supervision obligations for that chain are, at this writing, largely undefined.

ICLE urged CAISI to collaborate with legal and regulatory bodies to define the technical parameters of security-necessary telemetry: a taxonomy of telemetry types by privacy sensitivity, purpose-separation design patterns, and standardised data retention matrices. Until those exist, the governance gap stays open by default.


What NIST is building

The RFI is the intake mechanism for a standards programme already in motion. NIST launched the AI Agent Standards Initiative on February 17, 2026, organised around three pillars: industry-led standards development with US leadership in international bodies, community-led open-source protocol development co-invested with NSF, and fundamental research in agent security, identity infrastructure, and interoperability evaluation.

The Control Overlays for Securing AI Systems (COSAiS) project, announced by NIST’s Computer Security Division in August 2025, is developing SP 800-53 control overlays for five AI deployment categories. Two directly address agentic systems: single-agent and multi-agent deployments. These overlays will map existing security controls onto agent architectures with implementation-level specificity. For enterprises already operating under SP 800-53, the overlays will define what “secure enough” looks like for agents in a way that auditors can evaluate.

Several respondents proposed that NIST publish a standardised “Agent Security Profile” template, functioning as a security bill of materials for autonomous systems. The profile would document the agent’s actuation surface (what real-world state changes it can execute), its tool inventory and permission boundaries, credential lifecycle management, human oversight thresholds, monitoring and logging architecture, reversibility mechanisms, and kill-switch protocols. Persona’s submission detailed nine specific parameters. Attested Intelligence Holdings proposed cryptographically sealed governance artifacts that enable offline verifiability for critical infrastructure deployments.

NIST also hosted sector-specific listening sessions in April 2026 covering healthcare, financial services, and education. For CISOs in regulated industries, the feedback from these sessions may shape sector-specific requirements that carry supervisory weight before they become formal mandates.


What this means for financial services

The regulatory trajectory is predictable. NIST produces voluntary standards. Industry adoption converts them into market expectations. Sector-specific regulators incorporate them into compliance requirements. The distance between “voluntary guidance” and “supervisory expectation” is shorter than most institutions plan for.

The convergence across these 937 comments surfaces three operational priorities worth making explicit.

First, agent identity infrastructure is now a prerequisite for production deployment, not a future consideration. If an agent executes on behalf of a client, the institution needs to independently audit, reconstruct, and justify the logic. That requires verifiable agent identity, scoped delegation, and tamper-evident action logging. The OpenID Foundation, Persona, NIST’s NCCoE, and individual researchers are all pointing at the same requirement from different directions.

Second, risk classification should be based on what agents can do, not on model capability. An agent with a sophisticated model but read-only sandboxed access is a different governance problem than a simpler model with write access to production systems. Several respondents proposed tiering agents by their effective action space: read-only inquiry, interactive staging, and autonomous actuation, each with escalating control requirements. This gives security teams a practical framework for prioritising where to invest.

Third, the supply chain risk is structural and largely unaddressed. The Mercor/LiteLLM breach, the Cline CLI compromise, and the documented prompt injection pathways across agent frameworks all point to the same vulnerability: nth-party systemic exposure through shared open-source dependencies, shared data vendors, and shared infrastructure that no single institution controls or fully monitors. When your AI vendor’s AI vendor’s open-source dependency gets poisoned, the governance boundary has to extend further down than most firms have mapped.


The uncomfortable consensus

The convergence across 937 submissions is not about whether AI agents are risky. Everyone agrees they are. The convergence is about where the risk actually lives, and the answer that emerged is uncomfortable for an industry that has spent years focused on model safety, bias mitigation, and responsible AI principles.

The risk is in the identity layer, the delegation framework, the permission architecture, the telemetry infrastructure, and the execution boundary that determine what an agent can do, on whose authority, and whether anyone can reconstruct why after the fact. These are infrastructure problems that require infrastructure solutions.

The industry, by its own admission across nearly a thousand formal submissions, has not built them yet.

NIST is now developing the standards that will define what adequate agent governance looks like in practice. For regulated industries, the window between “emerging guidance” and “supervisory expectation” is narrowing faster than most compliance programmes are designed to move.

The 937 comments are in and the consensus is clear. Whether institutions treat this as a signal to build or as another report to file will determine which side of the governance gap they end up on.

Sources

NIST Docket NIST-2025-0035; NIST 800-5 Summary Analysis (May 18, 2026); Persona RFI Response (March 9, 2026); OpenID Foundation RFI Submission; Foundation for Defense of Democracies RFI Submission; Princeton CITP RFI Submission; ICLE RFI Submission; QueryStory RFI Submission (NIST-2025-0035-0154); Attested Intelligence Holdings RFI Submission (NIST-2025-0035-0211); Brianna Baynard RFI Submission (NIST-2025-0035-0026); NCCoE Concept Paper, “Accelerating the Adoption of Software and AI Agent Identity and Authorization” (February 5, 2026); Snyk, “How Clinejection Turned an AI Bot into a Supply Chain Attack” (February 19, 2026); Gravitee State of AI Agent Security 2026 Report; CSA Research Notes on NIST AI Agent Standards Initiative (March–April 2026); Pillsbury Law, “NIST Launches AI Agent Standards Initiative” (February 25, 2026).