When a federal CAIO tells an audience that her agency is moving from "AI that advises" to "AI that acts," the sellers in the room tend to hear a product roadmap question. They should be hearing an identity architecture question.
That gap — between what the buyer is actually scoping and what the seller thinks they're being asked about — is where federal AI deals are about to get complicated. Agents are already in solicitations, pilot designs, and CAIO testimony, and the vocabulary is arriving faster than most sellers' mental models have updated.
What the Procurement Signal Actually Says
A Department of Homeland Security solicitation from late 2024, publicly posted on SAM.gov as part of a broader AI capability assessment, included language requesting vendors demonstrate "agentic AI capabilities for multi-step workflow automation, including the ability to take sequential actions across agency systems with minimal human intervention between steps." That's not copilot language. Copilot language is "assist," "recommend," "draft." This language is about systems that do things.
The General Services Administration's AI strategy document, updated in early 2025, describes a near-term objective of deploying AI systems that can "initiate, execute, and verify completion of administrative processes" — again, a description of action-taking, not text generation. The HHS Chief AI Officer, in testimony before a Senate subcommittee last spring, drew an explicit distinction between "generative AI as a productivity tool" and "AI systems that can complete multi-step administrative tasks on behalf of agency personnel." She framed the latter as the agency's 18-month horizon.
Worth noting what these signals are and aren't. Agency AI strategy documents are aspirational; the gap between stated intent and deployed capability in federal IT is a structural feature, not a bug. But the vocabulary in these documents matters independently of the deployment timeline, because it's the vocabulary buyers are using when they talk to sellers. When a CAIO has testified about "action-taking AI systems," her staff is going to use that language in requirements documents. Sellers who don't recognize it are going to give the wrong answer to the right question.
OMB's AI guidance updates through 2024-2025 have increasingly emphasized accountability for autonomous AI actions, a framing that implies the guidance authors understand agents are coming even if they haven't fully specified the governance requirements. When oversight bodies start writing about accountability for AI actions, they're anticipating systems that take actions. That's worth tracking.
The Anchor: What You Already Know
Service accounts. Machine credentials. Non-human identities provisioned for automated processes that need to authenticate to systems without a human in the loop. You've managed these. You've probably cleaned up orphaned ones after someone left the agency and nobody remembered what the account was for. You've been in the conversation about why the ETL job has domain admin rights because "it was easier at the time."
That's the right starting point for understanding agent identity, because agents are, at the protocol level, non-human actors that need credentials, defined scopes, and audit trails. The IDAM intuition applies. An agent needs an identity. It needs to authenticate. Its access needs to be governed. These are not new problems.
But the analogy has a load-bearing limit, and the weight that breaks it is exactly what makes agents different from every service account you've ever provisioned.
Where the Analogy Breaks: Four Specific Places
Non-human identity. A service account has an identity in your directory. Someone created it, assigned it permissions, and (ideally) documented what it's for. An agent also needs an identity, but the buyer's current identity infrastructure almost certainly assumes that every request originates from a human, with a service account as the exception that gets handled specially. Agents invert that assumption. In an agentic workflow, the agent is the primary actor; the human is the one who initiated the delegation. Most federal identity architectures aren't built for that inversion. Authentication is the easy part. The harder question is whether the buyer's current identity infrastructure can represent agent identity as a first-class concept, distinct from both user identity and legacy service accounts.
Okta has been public about the non-human identity problem in this context. Their product work on machine identity and service account governance is directly relevant here, though the agent-specific capabilities are still maturing. The major identity vendors are treating this as a distinct architectural category, which tells you something about how buyers will eventually frame the requirement.
Credential delegation. A service account has static credentials. An agent acts on behalf of a user, which means the agent's authority is derived from a human principal's authorization. OAuth token delegation is the IDAM pattern that rhymes here — a user grants a client application a scoped token to act on their behalf. You know this pattern. The break point is that OAuth delegation was designed for defined, bounded interactions: a user authorizes an app to read their calendar. An agent's delegation may be open-ended — "handle my procurement approvals while I'm at the conference" — and the original authorization decision was made without anticipating the specific actions the agent will take. The scope of the delegation and the scope of the actions can diverge in ways that no single permission decision anticipated. Revocation is also structurally harder: if a user's OAuth token is revoked, the app stops working. If an agent's delegated authority is revoked mid-task, what happens to the actions already in flight?
Audit trail for autonomous actions. A copilot generates text. The human reads it, decides, and acts. The log entry for the human's action looks like every other log entry — a human authenticated and did something. An agent acts directly. The log entry for the agent's action also looks like a log entry — a credential authenticated and did something. The problem is that the agent may have taken forty sequential actions in three seconds, each one a logical consequence of the previous, none of them individually suspicious, collectively representing a workflow that no human reviewed step by step. Your buyer's SIEM was built to detect anomalous individual events. It was not built to reason about whether a sequence of individually normal events represents an autonomous process that exceeded its intended scope. That's a different audit problem, and most federal logging infrastructure isn't ready for it.
Scope containment. Least privilege is the principle; enforcement is the hard part. For a service account, you can define the scope at provisioning time and it stays there (in theory). For an agent, scope is exercised dynamically across a chain of actions. A permission granted for step one of a workflow may be exercised in ways that weren't anticipated when the permission was defined, because steps two through fifteen weren't visible when the authorization decision was made. This is the compounding problem. Each individual permission decision might be reasonable; the aggregate effect of chained permissions across a multi-step autonomous workflow may be something nobody explicitly authorized. Federal zero trust architectures are built around the idea of continuous authorization — verify at every step, not just at login. Agents stress-test that model because the "steps" happen faster than any human authorization loop can track.
The Questions That Earn Trust
The wrong question, when a buyer starts talking about agents, is some variation of "what can your AI do?" That's copilot territory. It positions you as a capability vendor when the buyer is actually scoping an infrastructure problem.
The right questions are identity questions, and they reveal pain that the buyer may not have fully articulated yet.
When the buyer describes an agentic workflow, ask: How does your current identity infrastructure distinguish a request coming from an agent versus a request coming from the user the agent is acting for? Most buyers haven't solved this. Many haven't asked it. The question signals that you understand the architecture they're building into.
When the conversation turns to delegation, ask: When a user authorizes the agent to act for them, how is that authorization bounded, and what's the revocation path if the user's circumstances change mid-task? This is the OAuth analogy applied correctly, and it surfaces the gap between "we'll use the user's credentials" (common, dangerous) and "we'll implement proper delegated authorization" (correct, harder).
When the buyer mentions logging or compliance, ask: What does your current audit infrastructure capture about sequential autonomous actions, and how does your compliance team distinguish an agent workflow from a compromised credential? This question tends to produce a pause. The pause is information.
When scope comes up — and it will, because federal buyers are acutely aware of least-privilege requirements — ask: For a multi-step agent workflow, at what point in the chain is the authorization decision made, and who reviews whether the agent's actions stayed within the intended scope? The buyer who has thought this through will have an answer. The buyer who hasn't will recognize that they need one.
What This Means for Tuesday
The federal buyers who are using agent vocabulary in 2025 are not all the way through the identity implications of what they're describing. Some of them know it; many don't. The sellers who arrive in those conversations already holding the identity-layer questions are going to look different from the sellers who show up with a capability demo.
Copilots generate; humans decide. Agents decide. That single difference cascades through identity, delegation, audit, and scope, changing each one categorically. The buyer who has a CAIO who's testified about "action-taking AI systems" is already thinking about what it means for AI to act. The seller who walks in with the right questions about how that action gets governed is the one who gets the next meeting.
The procurement signals are there. The vocabulary is in the solicitations. The identity questions are not being asked yet, which is precisely when asking them is most valuable.