As AI adoption accelerates, organizations increasingly rely on autonomous systems that can take action, communicate, and make decisions at machine speed, yet many lack a reliable way to verify what those systems are authorized to do and who is accountable for their actions. Traditional identity and access management frameworks were built for people, not AI agents.
DigiCert‘s Jason Sabin has been at the forefront of this conversation, arguing that AI agents don’t need passwords; they need passports. Passwords authenticate a user at a moment in time. AI agents require a cryptographically verifiable identity that establishes who they are, what they can access, and what they are authorized to do. DigiCert refers to this as an AI Agent Passport, which is a tamper-evident record that combines identity, authorization, and governance into a single trust framework.
The stakes become clear when you consider how AI systems operate. Agents increasingly interact with other agents, APIs, models, and external services, retrieving data, delegating tasks, and triggering actions with minimal human oversight. Without verifiable identity and authorization, organizations struggle to answer basic governance questions: Which agents are operating in the environment? What data can they access? Can a compromised agent be stopped immediately? And if something goes wrong, can the organization reconstruct a trustworthy audit trail? As AI adoption scales, trust for agents is becoming as fundamental as trust for users, devices, and applications has been for the internet.
++
VMblog: Let’s start with the big picture. AI agents are being deployed across enterprises at a rapid pace, but you’ve argued that without a trusted identity framework, this creates a systemic risk. Can you walk us through what that risk actually looks like in practice?
Jason Sabin: The risk is that enterprises are creating a new class of actor inside their environments without giving that actor the same identity, accountability, and lifecycle controls we expect for people, devices, and applications. An AI agent may be able to access data, trigger workflows, communicate with systems, or make recommendations that influence business decisions. If that agent is misconfigured, impersonated, over-permissioned, let alone compromised, the organization may not know what it did, why it did it, or whether it was authorized to act in the first place.
That becomes systemic because agents will not operate in isolation. They will interact with several systems and applications, APIs, data stores, other agents as well as human users. Without a trusted identity framework, you end up with an expanding web of automated activity where trust is assumed instead of verified. That is not sustainable at enterprise scale.
VMblog: The concept of “AI agents needing passports, not passwords” is a compelling framing. What does a digital passport for an AI agent actually consist of, and how is it fundamentally different from the credential-based approaches enterprises use today for human users or service accounts?
Sabin: A password proves very little. It generally proves that someone or something has possession of a shared secret. A passport is different because it establishes identity, authority, issuer information, validity period, and context. That is the direction we need to move with AI agents.
A digital passport for an AI agent should include a strong cryptographic identity, information about who issued that identity, what the agent is authorized to do, when that authorization expires, and whether the identity is still valid. It should also support revocation, policy enforcement, and auditability.
The difference from many current credential-based approaches is that agent identity cannot be treated as a static secret buried in a script or service account. AI agents are dynamic in that they’re created, modified, delegated, or retired frequently. Their identity has to be verifiable and short-lived where appropriate and governed by policies associated with its role.
VMblog: When we think about agent-to-agent communication, what are the specific trust gaps that emerge, and why do traditional PKI or IAM frameworks fall short in addressing them?
Sabin: The biggest trust gap is context. Traditional identity systems are good at answering, “Is this entity known?” But with AI agents, that is not enough. We also need to know what the agent is, who created it, what model or workflow it represents, what it is allowed to do, whether it has changed, and whether another agent should trust its request.
Traditional PKI gives us a strong foundation for cryptographic trust, and IAM gives us important access control capabilities. But neither was originally designed for a world of autonomous agents making decisions and interacting with one another at high speed. The issue is not that PKI or IAM are irrelevant. It is that they need to evolve into a broader trust framework that includes identity, authorization, provenance, policy, lifecycle management, and auditability.
VMblog: How should enterprises think about the “human in the loop” requirement as AI autonomy increases? Is there a point where human oversight becomes a bottleneck, and if so, how does identity infrastructure help bridge that tension?
Sabin: Human oversight is important, especially for high-risk decisions. But it cannot be the only control. If every AI-driven action requires manual review, organizations will lose the speed and efficiency they are trying to gain from AI in the first place.
The better model is risk-based autonomy. Some actions should require human approval. Others can be automated if the agent has a verified identity and operates within defined policy boundaries, then leaves an auditable trail. Identity infrastructure helps make that possible because it allows organizations to say, “This agent is trusted for this action, in this context, under these conditions.”
That is how you move from blanket approval or blanket restriction to governed autonomy.
VMblog: From a CISO’s perspective, what are the accountability and auditability implications when an AI agent takes an action autonomously? How does a strong identity framework support forensic traceability if something goes wrong?
Sabin: For a CISO, the question is if something goes wrong, can I reconstruct what happened? Can I identify the agent, the system it interacted with, the credentials it used, the data it accessed, the action it took, and the policy that allowed or denied that action?
Without strong identity, that investigation becomes very difficult. You may see activity, but you may not be able to attribute it with confidence. A strong identity framework gives every agent a verifiable identity and ties that identity to logs, permissions, certificates, keys, and lifecycle events. That creates the forensic trail needed to understand whether an incident was caused by misuse, compromise, misconfiguration, or normal behavior that produced an unintended outcome.
Accountability starts with identity. If you cannot identify the actor, you cannot govern the action.
VMblog: Quantum computing is often discussed as a future threat to public key infrastructure. How should enterprises be thinking about quantum-readiness now, particularly as they’re simultaneously building out their AI agent deployments? Is there a convergence risk here?
Sabin: There is a convergence risk. AI agents will increase the number of machine identities, certificates, keys, APIs, and automated trust relationships inside the enterprise. At the same time, organizations need to prepare for a transition to quantum-resistant cryptography. Those two trends are going to collide.
The worst-case scenario is that organizations rapidly expand AI deployments using cryptographic infrastructure they do not fully understand cannot inventory. Therefore, they cannot update quickly, and then when post-quantum migration becomes urgent, they discover they do not know where their cryptography lives or which systems depend on it.
Quantum-readiness starts with visibility and crypto-agility. Enterprises need to know what cryptography they use, where it is, what it protects, and whether it can be changed without breaking critical systems. That is just as important for AI as it is for every other part of the enterprise.
VMblog: What does a practical roadmap look like for an enterprise that wants to establish a trusted identity framework for AI agents? Where should they start, and what are the most common mistakes you see organizations make early in that journey?
Sabin: Start with inventory. You cannot secure or govern AI agents you do not know exist. Organizations should identify where agents are being used, what systems they access, what credentials they rely on, and who owns them.
Next, assign unique identities to agents rather than allowing them to share generic service accounts or embedded credentials. Then define policies for what each agent can do, how long its credentials remain valid, how activity is monitored, and how access is revoked when the agent changes or is retired.
The most common mistake is treating AI agents as just another application integration because they are more dynamic than that. Another mistake is focusing only on the model while ignoring the surrounding infrastructure: keys, certificates, APIs, data access, logging, and lifecycle management. The model matters, but the trust fabric around the model matters just as much.
VMblog: Looking ahead 18 to 24 months, how do you see the regulatory and standards landscape evolving around AI agent identity? Are bodies like NIST, ISO, or industry consortia moving fast enough to keep pace with deployment realities on the ground?
Sabin: Standards bodies are moving, but enterprise deployment is moving faster. That is not unusual with emerging technology. The market often gets ahead of formal standards, and then standards catch up by codifying the practices that prove effective.
Over the next 18 to 24 months, I expect more attention on AI accountability, provenance, identity, and lifecycle governance. Regulators will want to know who or what made a decision, what data was used, whether the system was authorized, and whether the organization can prove it. That naturally leads back to identity.
Enterprises should not wait for every standard to be finalized before acting. The fundamentals are already clear: discover your agents, assign them verifiable identities, manage credentials and permissions, monitor behavior, and build auditability into the system from the start. The organizations that do that now will be much better positioned as regulations and standards mature.
##
