Current as of May 27, 2026
Long weekends have a way of clarifying which conversations you've been putting off. If you sell into organizations deploying AI agents, two of those conversations share a structural feature worth naming: the buyer believes they're covered because they're measuring governance by what they built on purpose, and the environment running around those intentional builds is wider than the measurement. The coverage they describe is real. The environment is wider than the coverage.
The questions below surface that gap without arguing about vendors. Each one includes companion context: why the question works in the moment, and what the answer actually tells you, including when the buyer's current solution is sufficient and you should move on.
"We've Got AI Agent Governance Handled"
When a buyer names their current governance stack, they're usually telling the truth about what they can see. They built agents inside their primary platform, and that platform provides governance tools. Their agent population, though, almost certainly extends beyond what any single platform governs automatically.
This is a coverage-audit conversation. The posture is the one an auditor would take with any organization regardless of vendor: let's check what the tools actually reach.
From the vendors' own documentation:
Microsoft's Entra Agent ID auto-creates identities for new Copilot Studio agents built after the org opted in. The feature remains in preview. Agents built before March 2026 run on legacy service principals without the Agent ID governance layer, and Microsoft's docs confirm there is no automated migration path to convert them. M365 Copilot Agent Builder agents "currently don't use or require Agent IDs" at all. Agents running on non-Microsoft platforms — AWS Bedrock, Anthropic, Google Vertex, Salesforce Agentforce — require custom SDK integration or manual configuration to get Entra identities. That work is achievable but not automatic and not included in the license.
CyberArk positions AI agents explicitly as "privileged machine identities" in its product materials. The coverage is secrets management, vault-based credential governance, and zero standing privileges. CyberArk's own materials acknowledge that standard application consent models cover only a narrow set of agent scenarios. Their product is the privileged-access layer on top of the identity governance layer. The layer underneath remains a separate problem.
The buyer's tools work. The question worth asking is whether those tools reach the full agent environment: agents built before the governance rollout, and agents built outside the primary platform.
1. "Of the AI agents running in your environment today, how many were built inside your primary platform versus how many connect from outside it?"
Why this works now: You're asking them to count, not challenging their tool. Most organizations have agents from multiple vendors, internal dev teams, and SaaS products that deploy agents into the environment without touching the platform the buyer is thinking about.
What the answer tells you: A specific ratio, or an honest "we haven't inventoried the external ones," means the conversation has room. If the buyer confirms all agents are inside their platform and they've verified that, the current solution may genuinely be sufficient. Move on to a different thread.
2. "For agents that predate your current governance rollout, do they carry the same identity and policy controls as the ones you're building now?"
Why this works now: Microsoft's own docs confirm no automated migration path from legacy service principals to Entra Agent IDs. The buyer's newest agents may be well-governed while their oldest, often the most deeply integrated, are not.
What the answer tells you: A pause or "we'd have to check" is the gap. "We're planning to migrate those" is a deflection: planning is not coverage. If the buyer confirms legacy agents have been individually re-provisioned with current governance controls, that's real work and a real answer. Acknowledge it and move on. (Okta's lifecycle governance capabilities map to the re-provisioning gap, if one exists.)
3. "When an agent's access needs to be revoked — say, a project ends or a vendor contract lapses — who owns that action, and what triggers it?"
Why this works now: Secrets management vaults credentials. Privileged access management controls sessions. Neither inherently owns the deprovisioning workflow: who notices the agent should no longer have access, who acts, and whether the action is auditable. That's the identity governance layer sitting above both.
What the answer tells you: A named owner and a described trigger is a real answer. "That would go through our normal offboarding process" is a deflection: agents don't offboard like employees, and the process almost certainly wasn't designed for them. (Okta's access certification and lifecycle governance capabilities map directly here, if the conversation opens.)