Panel: M2M Trust and the Security Gap in Agentic AI

Felipe Hlibco

I moderated a panel last week on machine-to-machine trust in agentic AI systems, and the conversation went sideways almost immediately. The plan was to discuss identity management frameworks. What we ended up talking about—for the better part of an hour—was how fundamentally unprepared enterprise security is for a world where AI agents act autonomously on behalf of organizations.

The core problem is simple to state and terrifying to think through: every AI agent needs an identity. Every identity is an attack surface. And we’re scaling agents faster than we’re scaling the governance around them.

The Numbers Are Already Bad #

Machine identities—API tokens, service accounts, certificates, JWTs—outnumber human identities in most enterprises by a ratio of 45 to 1. Some estimates push that to 82:1 in heavily automated environments. Each one of those identities can be compromised, reused, or escalated.

Now add AI agents to the mix. An autonomous agent that books meetings, processes invoices, and accesses customer data needs credentials for each of those systems. If the agent delegates subtasks to other agents—which is the whole point of agentic architectures—those sub-agents need their own credentials too. The identity surface area doesn’t grow linearly; it compounds.

Okta’s research paints a bleak picture: 23% of IT professionals report that AI agents have already been tricked into revealing access credentials. Not theoretically. Already. And only 10% of organizations have any strategy for non-human identity governance. That gap between exploitation and preparedness should alarm anyone responsible for enterprise security.

Most M2M authentication today relies on static credentials: API keys, long-lived JWTs, X.509 certificates with generous expiry windows. These work reasonably well for traditional service-to-service communication where the set of services is known, the communication patterns are predictable, and the credential lifecycle is managed by infrastructure teams.

AI agents break every one of those assumptions.

Agents are dynamic—they spin up and down based on tasks. Their communication patterns are unpredictable by design (that’s what makes them useful). And the credential lifecycle? Nobody’s managing it. An API key provisioned for an agent prototype during a hackathon is still active in production six months later because no one remembers it exists. I’ve seen this exact scenario. Twice.

The danger multiplies when agents reuse credentials across sessions or when a single compromised credential gives an attacker lateral movement across the agent’s entire permission set. It’s the blast radius problem, and it’s worse for agents than for traditional services because agents tend to have broader permissions—they need to be flexible—with less monitoring—they’re new and observability tooling hasn’t caught up.

What OWASP and CSA Are Saying #

OWASP’s emerging guidance on agentic AI applications identifies identity-related risks as three of the top four threats. Delegated trust boundaries—where Agent A grants Agent B permission to act on its behalf—are particularly dangerous because the trust chain becomes opaque. Who authorized what? Can Agent B re-delegate to Agent C? What happens when the human who initiated the chain revokes consent?

The Cloud Security Alliance introduced a purpose-built agentic AI IAM framework that proposes using Decentralized Identifiers (DIDs) and Verifiable Credentials alongside Zero Trust principles. The approach is architecturally sound: each agent gets a cryptographically verifiable identity, credentials are scoped and time-limited, and every agent-to-agent interaction is authenticated independently.

The gap between the framework and reality is vast. Most organizations are still figuring out basic service account hygiene. Jumping to DIDs and verifiable credentials for AI agents requires infrastructure, tooling, and expertise that doesn’t exist at scale yet.

What a Realistic First Step Looks Like #

The panel converged on a few practical recommendations that don’t require rebuilding your entire IAM stack:

Ephemeral credentials. Stop provisioning long-lived tokens for agents. Use OAuth 2.0 Client Credentials with short-lived access tokens—minutes, not days. Combine with mutual TLS per RFC 8705 as a transport-level authentication layer. This doesn’t solve the governance problem but it limits the blast radius of any single compromise.

Just-in-time provisioning. Agents request credentials when they need them, scoped to the specific task. The credentials expire when the task completes. This is harder to implement than it sounds—you need a credential broker that understands agent workflows—but it’s the right direction.

Agent identity inventory. Before you can govern agent identities, you need to know they exist. Most organizations can’t answer “how many AI agents have credentials in our systems?” Start there. Catalog every non-human identity, tag which ones belong to AI agents, and establish ownership.

Delegation chain logging. When Agent A delegates to Agent B, log the entire chain: who initiated, what permissions were granted, what scope, what expiry. Make the chain auditable. This is the bare minimum for accountability.

The Coming Storm #

One panelist shared—anonymously—details of an AI-orchestrated cyber-espionage campaign where a jailbroken agent handled 80-90% of the attack chain autonomously. The agent performed reconnaissance, identified vulnerable endpoints, crafted phishing content, and exfiltrated data with minimal human guidance. The attacker didn’t need deep technical skills. They needed to know how to prompt an agent.

That’s the paradigm shift. The barrier to sophisticated attacks drops dramatically when agents can be weaponized through natural language rather than code. And the defense side hasn’t adjusted.

We’re building agents faster than we’re securing them. The IAM frameworks we rely on were designed for a world where machines did predictable things on predictable schedules. AI agents do unpredictable things on dynamic schedules with broad permissions and minimal oversight.

Closing that gap isn’t optional. It’s the security challenge of the next two years. And based on what I heard from the panel, most organizations haven’t started.