The Top 5 Problems with M2M Tokens in Agent Workflows

Machine-to-machine (M2M) tokens, often used for service-to-service communication, seem like a natural fit for AI agents at first glance. After all, agents are machines, right? Not quite. While M2M tokens work well for predictable, static service interactions, they fall apart when applied to dynamic, delegated AI agent access. Here’s why relying on M2M tokens for your agent workflows is a recipe for security headaches and operational nightmares:

1. Lack of User Context and Delegation Chain

M2M tokens are designed for a service to act on its own behalf. They carry no inherent information about a human user who might have authorized an agent's actions. This creates a massive blind spot. When an agent performs an action using an M2M token, your system can't tell who ultimately initiated or approved that action. This breaks the delegation chain, making it impossible to audit user-attributed actions or enforce user-specific policies.

2. Over-Permissioning and Blast Radius

To ensure an agent can perform its diverse tasks, you'll likely grant its M2M token broad permissions. This leads to over-permissioning. If that token is compromised, an attacker gains access to everything it's authorized for, not just the scope of a single user's delegated task. This dramatically increases the blast radius of a security breach, turning a minor incident into a major data exposure.

3. Static and Infrequent Rotation

M2M tokens are typically long-lived and rotated infrequently. For a stable backend service, this might be acceptable. For dynamic AI agents that are spun up, perform tasks, and then potentially de-provisioned, this is a huge problem. You end up with a proliferation of persistent, powerful tokens that are difficult to track and even harder to revoke in a timely manner. This creates an ever-growing attack surface.

4. No Support for Ephemeral or Context-Specific Access

Many AI agents are ephemeral; they're created for a specific task and then disappear. M2M tokens, designed for persistent services, don't align with this lifecycle. You can't easily grant a token just for a single, short-lived operation. Furthermore, M2M tokens lack the ability to dynamically adjust permissions based on the specific context of an agent's task, leading back to the over-permissioning problem.

5. Auditability and Compliance Nightmares

Without a clear link to the authorizing user and the specific delegated intent, auditing agent actions becomes incredibly challenging. When you see an action performed by an M2M token, you can't trace it back to a human user for accountability. This makes it nearly impossible to meet regulatory compliance requirements that demand clear audit trails of user-initiated actions, especially in sensitive domains.