Six Bluff Moments in Your Next Federal AI Conversation

You know the moment. The buyer says something about AI, your identity instinct reaches for an analogy, and for about two seconds you're calculating whether it holds. Two seconds is a long time in a meeting. The buyer can feel it. They've sat through enough vendor conversations to distinguish a real answer from a confident-sounding one.

This piece is about those two seconds. Six of them. Each grounded in a policy trigger that's live right now: M-26-10 dropped March 31 with monthly CIO contract reporting requirements that started this month. AI inventory deadlines under M-25-21 are compressing. CAIO governance boards are standing up across agencies, and most of them have agent identity on the agenda. These pressures are creating real conversations with CAIOs, CIOs, and CISOs across federal and SLED accounts.

For each question: what the buyer is really asking, where your IDAM knowledge gives you solid ground, where that ground gives way, and the specific phrase from the buyer that means stop talking and bring your SE.

The thesis is simple. These buyers are testing whether you know what you don't know. That's the bar.

1. "Can you help us see what AI is actually running?"

Their AI use case inventory under M-25-21 is due, and the CAIO has to validate its completeness. GSA's own AI directive requires distinguishing production-intent from experimental use cases. Hard to make that distinction when you can't see what's running.

Your OAuth and access log instincts are correct here. If an AI tool authenticates through your IdP, you have a record: who accessed it, when, what scopes were granted. That's real, defensible data the CAIO can use for inventory validation.

The instinct starts to mislead you when you want to say "we can show you everything that's running." You can't. When an employee signs up for ChatGPT with a personal email and credit card, that authentication never touches your IdP. Verizon's 2025 DBIR found 72% of employees using generative AI at work authenticate with personal accounts. That traffic is structurally invisible to any identity provider. So say what's true: "We can show you everything that authenticates through managed channels." Name the gap explicitly. The buyer will respect the boundary more than the overreach.

Bring your SE when: the buyer says something like, "What about the tools people signed up for with their personal Gmail?" That's detection architecture beyond the IdP perimeter, and your SE can walk through what a layered approach looks like.

2. "My CIO has to report all IT contracts to OMB monthly. How does identity help?"

OMB M-26-10, signed March 31, 2026, requires CIOs at CFO Act agencies to submit monthly reports on all approved IT contracts starting this month. Federal CIO Gregory Barbaccia framed the intent plainly:

What the buyer is actually wrestling with:

If you've sold into agencies during FITARA compliance cycles, you recognize this pattern. Former GSA Administrator Emily Murphy told Federal News Network agencies will need "a whole new data process" to comply, noting the memo "seems to replicate the data that should be in the IT dashboard already." Translation: the administration believes existing CIO oversight infrastructure is insufficient.

Identity data fills a specific gap here. Procurement records tell the CIO what was bought. Identity data tells them what's actually being used. Which applications have active users, which have dormant OAuth grants, which AI tools showed up in the environment without a procurement record at all. For a CIO who has to report monthly and knows the data quality is poor, that's the only real-time utilization signal available.

But don't conflate "we can show you which AI applications have active sessions" with "we can tell you which contracts to report." The CIO's obligation is about contracts and pricing, not authentication events. Identity data feeds the reporting process. The CIO still owns the contract-level obligation.

Bring your SE when: the buyer says, "Can we pipe this into our ITAM system automatically?" That's integration architecture your SE can scope realistically.

3. "We think most of our AI usage is unsanctioned. Can you find it?"

Enterprise survey data suggests 71% of organizations report AI tools accessing core systems like Salesforce and SAP, but only 16% say that access is governed effectively (source: Cybersecurity Insiders 2026 CISO AI Risk Report, n=235 large enterprises, self-reported). The CISO knows shadow AI exists. They need a number for their governance board.

OAuth consent grants are a real signal. When an employee connects an AI tool to Google Drive or Microsoft 365, that connection generates a token. Okta's ISPM capability surfaces unmanaged agents by capturing these grants in a centralized view. Genuine detection, and useful.

Now the important part. Current detection scope for this capability covers managed Chrome browsers only. Other browser support is on the roadmap but not shipped. Locally installed AI agents running via MCP servers with hardcoded API keys generate no OAuth consent grant at all. Federal News Network recently profiled OpenClaw, an open-source task-executing agent that runs with full admin permissions locally. Your IdP doesn't see it because the agent authenticates via a local API key and never generates an OAuth event. No identity signal to detect. The credible version of this answer: "We detect shadow AI that authenticates through browser-based OAuth flows in managed Chrome environments. That's a meaningful slice. Covering the rest requires additional layers."

Bring your SE when: the buyer says, "What about the tools that never touch our IdP?" or describes agents running on endpoints via local MCP servers. Your SE can map the detection layers honestly, including what falls outside identity's reach.

4. "How do we manage identities for AI agents? Is this just service accounts?"

CAIO governance boards are forming across agencies, and agent identity is on every agenda. GovTech put the question directly: do we have a plan for machine identities that now outnumber human employees?

The lifecycle concepts transfer cleanly. Agents need to be provisioned, assigned owners, reviewed periodically, deprovisioned. Okta for AI Agents, GA as of April 30, 2026, treats agents as first-class identities in Universal Directory: registration, human owner assignment, short-lived credentials, access certifications, and a kill switch for unexpected behavior. Your provisioning and governance vocabulary applies.

The service account analogy gives you solid footing for the first half of this conversation. Then the ground shifts. A service account runs a defined process against a defined resource. An AI agent chooses which tools to call, can chain actions across systems unpredictably, and may spawn sub-agents. The access pattern is dynamic, not static.

If you tell the buyer "treat it like a service account," their security team will immediately ask: "Then why can't I define its access scope at provisioning time the way I do for a service account?" Because you can't, fully. The agent's runtime behavior may invoke tools that weren't anticipated at provisioning. Short-lived credentials and least-privilege policies constrain the blast radius. They don't eliminate the architectural difference. Name the difference. It's what makes the governance tooling necessary rather than optional.

Bring your SE when: the buyer asks, "So how do I scope permissions if the agent decides at runtime what to call?" or starts asking about MCP server governance specifically.

5. "We lost the people who set up our AI tools. Now what?"

Federal agencies have experienced significant workforce reductions. The mid-career technologists who understood legacy access policies, configured integrations, and provisioned AI tools are in many cases gone. The institutional knowledge left with them. (Note: workforce and adoption data in this area may be affected by post-2024 federal workforce changes in ways that published surveys haven't yet captured.)

Your joiner-mover-leaver instinct is exactly right. When a human leaves, their accounts get deprovisioned. The problem: the AI agents they created, the OAuth grants they authorized, and the API keys they generated don't get deprovisioned with them. Okta's agent governance model requires assigning a human owner to every registered agent. When that owner leaves, the ownership gap surfaces in the governance workflow rather than hiding in a forgotten integration.

JML will frame this as an offboarding problem. Fair enough, but discovery is the harder half. The departing employee may have provisioned agents that were never registered. If the agent was set up with a personal API key and runs against a SaaS platform directly, it may still be operating with the departed employee's credentials months later. The offboarding workflow catches what's registered. What was never onboarded in the first place stays invisible.

Bring your SE when: the buyer says something like, "We found integrations running under accounts of people who left six months ago and we don't know what they do." That's a discovery and remediation engagement, and it needs your SE's hands on it.

6. "What's the NIST controls framework for AI agents?"

The buyer's ATO process requires mapping capabilities to NIST SP 800-53 controls. They want to know which control families apply to AI agents.

That second sentence matters more than the first, because it changes your posture from delivering a mapping to helping them think through the case.

Mapping agent capabilities to existing control families is a sound starting point. Access control (AC), identification and authentication (IA), audit and accountability (AU), and system and communications protection (SC) all have obvious relevance. The vocabulary transfers.

The formal mapping doesn't exist yet. NIST's AI Agent Standards Initiative has announced SP 800-53 control overlays for AI agents, but they remain in development. The Cloud Security Alliance, in an April 2026 research note, assessed that the first substantive NIST deliverables are a year or more away. If you tell the buyer "our capabilities map to these controls," you're making an informal mapping that hasn't been validated by NIST. Fine as a planning conversation. Don't present it as a compliance answer.

Say it straight: "The formal overlay isn't published yet. Here's how we think about the mapping based on existing control families. Your ISSO will need to validate this in your specific authorization boundary." That positions you as someone building the justification alongside them, which is what they actually need.

Bring your SE when: the buyer says, "Can you give us a controls mapping document we can submit?" That requires your GRC team.

The Pattern Underneath

Every one of these moments has the same structure. The buyer asks an AI question. Your identity knowledge gives you a real, partial answer. The temptation is to present the partial answer as complete, because the part you know is genuinely valuable and you don't want to lose momentum.

The buyers across from you right now are operating in an environment where 92% of organizations lack full visibility into their AI agent identities (per CSA, citing Cybersecurity Insiders survey data) and the compliance frameworks they need haven't been finalized. They know the space is unsettled. They're looking for someone who knows exactly which answers exist and which are still missing.