OMB M-24-10, issued in March 2024, required every federal agency to designate a Chief AI Officer, publish an AI use case inventory, and implement a governance framework for AI risk management. Most of the coverage treated this as a workforce story — agencies need AI literacy, CAIOs need authority, employees need training. That framing captures something real, but it misses the part that matters for anyone selling AI tools into the federal market.
The governance frameworks M-24-10 mandated are now functioning as the primary procurement gate for AI tool approvals. A tool that can't satisfy an agency's responsible AI framework requirements — specifically its auditability, access control, and human oversight provisions — doesn't get approved. The pilot dies in the governance review, not in the technical evaluation. And the reason it dies there, consistently, is not a training gap or a policy gap. It's an identity architecture gap that nobody named correctly during the procurement conversation.
That's the translation problem this piece addresses.
What a Responsible AI Framework Is Actually Doing
Agency responsible AI frameworks are governance documents written by policy teams, legal counsel, and risk officers. They use the vocabulary of accountability, transparency, human oversight, and data stewardship. They do not use the vocabulary of identity infrastructure. But if you read them through a protocol lens — asking who is the principal, what are they accessing, who authorized it, and what happens when the answer should be no — they resolve into something recognizable: a gap inventory of the identity infrastructure the agency doesn't yet have.
This is not a metaphor. The requirements that appear in these frameworks under headings like "auditability" and "accountability" are, in operational terms, requirements for audit logs with principal attribution, for authorization policies that inherit from existing IAM systems, and for delegation chains that map AI-assisted decisions back to accountable human identities. The policy team wrote a governance requirement. The identity team needs to build the infrastructure that satisfies it. The AI vendor needs to demonstrate that their tool can operate inside that infrastructure. Most of them can't, because most of them were built for enterprise commercial environments where those requirements don't exist in this form.
A 2025 GAO review of agency AI implementations found that fewer than 30 percent of pilots in agency use case inventories had documented access control architectures consistent with the agency's existing IAM policies. The other 70 percent were running on provisioning schemes — API keys, shared credentials, vendor-managed user databases — that are structurally incompatible with what the frameworks require. Those pilots aren't failing because the AI doesn't work. They're failing because the AI was built outside the identity envelope the framework demands.
The Translation Mechanic
Take policy language from a responsible AI framework, render it in identity infrastructure terms, identify the gap it reveals, and derive the discovery question it opens. Three requirement types appear most consistently across M-24-10 and published agency AI strategies.
Auditability and logging. M-24-10 requires agencies to maintain records sufficient to support after-the-fact review of AI system outputs, particularly for rights-impacting and safety-impacting applications. The policy framing is about accountability and transparency. The identity framing is about principal attribution in audit logs.
What this actually requires: every AI system output needs to be traceable to the specific user session that generated it, in a format the agency's SIEM or audit infrastructure can consume. Not "a user was logged in." The specific credential, the specific session, the specific timestamp, the specific output — linked in a chain that survives the AI system itself. This means the AI tool needs to be integrated with the agency's identity infrastructure at the session level, not just authenticated at the perimeter. Most commercial AI tools authenticate a service account at the API level and log activity against that account. That's one principal for potentially thousands of users. It satisfies nobody's audit requirement.
The discovery question: "When your AI system produces an output, what does the audit record look like, and which identity does it attribute the action to?"
Access control and authorization. Agency AI strategies consistently require that access to AI systems be governed by role and need-to-know, consistent with existing data classification requirements. The policy framing is about data stewardship and least privilege. The identity framing is about whether the AI tool's authorization model federates with the agency's existing ABAC or RBAC policies, or runs a shadow authorization scheme of its own.
The gap is structural. Most AI tools come with their own user management — their own roles, their own groups, their own permission model. In a commercial enterprise, that's manageable. In a federal agency with an existing identity governance infrastructure, a classification scheme, and a mandate to apply consistent access controls across systems, a shadow authorization model is a compliance problem before the tool processes a single query. The AI system needs to consume the agency's identity attributes — clearance level, organizational role, data access entitlements — and enforce authorization decisions based on those attributes. That requires federation with the agency's IdP, not a parallel user database.
This is where a FedRAMP-authorized identity provider matters concretely: the question isn't whether the AI tool has user management, but whether it can subordinate that user management to the agency's existing identity governance. Vendors who've thought about this have federation documentation. Vendors who haven't will describe their user management as "flexible" and "customizable," which is the tell.
The discovery question: "Does your authorization model federate with our existing IdP, or does it maintain its own user database? And if we need to enforce attribute-based access controls based on our classification scheme, where does that policy live?"
Human oversight and accountability. This is the requirement type that generates the most confident-but-wrong takes in the market. M-24-10 requires human review for high-stakes AI decisions, with clear accountability chains. The policy framing is about human control and organizational responsibility. The identity framing is about delegation and supervisory binding.
"Human oversight," operationally, requires a recorded relationship between an AI-assisted output and the human principal who is accountable for it. Not just a human who reviewed it — a specific, identified human whose identity is bound to that output in the system of record. This is a delegation problem. The AI system needs a concept of "this output was reviewed and approved by [identity]" that maps to an actual, verifiable identity in the agency's system, not a checkbox in the AI tool's own interface. When an AI-assisted decision gets challenged in an audit, in litigation, in an Inspector General review, the accountability chain needs to resolve to a human identity that the agency's HR and IAM systems recognize.
AI tools commonly have approval workflows. Almost none of them bind those workflows to external identity systems in a way that produces the evidence chain a federal audit requires. The approval lives in the AI tool's database. The identity lives in the agency's IAM system. Those two records don't talk to each other, which means the accountability chain has a gap exactly where the auditor will look.
The discovery question: "If an AI-assisted decision gets challenged in an IG review, what's the evidence chain from the decision back to the human accountable for it, and where does that chain live?"
Where the Change Management Instinct Misleads
The natural response to responsible AI framework requirements is to treat them as change management problems. Train the workforce. Update the policies. Designate the accountable officials. Run the pilots with appropriate human review. This instinct is sound about what the frameworks require at the organizational level. It breaks down on the question of why pilots fail to clear the frameworks.
Pilots fail the governance review because they were provisioned outside the identity and compliance envelope the framework requires. The training happened. The policy was written. The human reviewer was designated. But the AI tool is running on a service account that doesn't map to individual users, with its own authorization model that doesn't inherit the agency's classification policies, producing audit records that don't satisfy the principal attribution requirement. No amount of organizational change fixes an architecture that can't produce the evidence the framework demands.
This is the specific insight that earns discovery access with a CAIO or CIO. The conversation most vendors are having is about governance maturity — does the agency have the right policies, the right training, the right oversight structure? What actually matters is identity architecture: does the AI tool operate inside the agency's existing identity envelope, or does it create a parallel identity universe that the framework can't govern? The CAIO who has watched three pilots die in governance review knows the answer is usually the latter. They're looking for a vendor who diagnosed the problem correctly.
The Partnership for Public Service's 2025 federal AI adoption survey found that agency leaders consistently cited "governance and compliance infrastructure" as the primary barrier to AI deployment — ahead of workforce readiness, budget, and technical capability. That's the policy framing. Translated: agencies can't deploy AI tools that don't fit inside the identity and audit infrastructure they're required to maintain.
Reading the Next Framework
The interpretive move is transferable; the specific examples are just practice. Pick up any agency AI strategy — the Department of Labor's AI governance framework, HHS's responsible AI policy, the emerging Defense agency implementations — and read every requirement through three questions: Who is the principal in this requirement? What authorization decision is implied? What audit evidence does this require, and where does it need to live?
Every "auditability" requirement is a principal attribution question. Every "access control" requirement is a federation and authorization architecture question. Every "human oversight" requirement is a delegation and identity binding question. The policy team wrote it in governance language. The infrastructure team needs to build it in identity language. The vendor needs to demonstrate that their tool can satisfy it in both.
The frameworks are aspirational documents — the gap between what M-24-10 requires and what agencies have actually implemented is real and documented. CAIO public statements about AI governance progress are signals about priorities, not evidence of completion. But the frameworks are also the procurement gate, which means the gap between aspiration and implementation is exactly where the conversation lives. The agency knows what it needs. The question is whether the vendor can operate inside the envelope that "what it needs" describes.
That envelope is an identity architecture. The frameworks just don't say so in those words. Now you can read them as if they do.