Why Machine-to-Machine Auth Breaks in the Age of AI Agents
Jun 8, 2025
2 mins
Matt (Co-Founder and CEO)
TL;DR
Machine-to-machine (M2M) tokens were designed for stable, backend service communication — not dynamic, user-delegated AI agents. As platforms integrate with agents acting on behalf of users, traditional auth models break. What's needed now is scoped, ephemeral, auditable identity — and M2M just isn't built for it.
The Old World: Machine-to-Machine Auth
Before AI agents, service-to-service authentication was relatively straightforward. Backend services needed to talk to each other. You'd issue a client ID and secret, generate a bearer token, and grant it access via OAuth 2.0 or a similar protocol. These tokens were static, long-lived, and scoped to the service — not the user.
This worked for:
Microservices inside the same company
Internal APIs
Scheduled batch jobs or CRON workflows
The assumptions:
Identities are relatively fixed
Permissions are long-lived
There's no need for delegation or audit at the per-request level
Then agents showed up.
Enter: AI Agents
Agents don't look like backend services. They're dynamic, sometimes transient, often external to your product. Crucially, they act on behalf of users, not as backend systems or internal processes.
Here's what makes agents different:
Autonomous: They make decisions without direct user prompts.
Delegated: They often execute tasks with user-level intent.
Ephemeral: Some are spun up per session, task, or interaction.
Multi-system: They often move between APIs, products, and workflows.
Customer-owned: Your customer may be deploying agents against your API.
In this world, a static token shared across services won't cut it. You need dynamic trust and scoped control per agent, per task, per user.
Why M2M Auth Breaks
M2M Model Assumption | Why It Breaks in Agent Context |
|---|---|
One service, one token | Agents are many — per customer, per task |
Long-lived credentials | Short-lived agents need expiring, revocable identity |
Static access scopes | Agents need granular, task-specific permissions |
No user context | Agents often act on behalf of a human user |
No audit trail per actor | Agents must be traceable and attributable |
M2M tokens are like master keys — if you lose control of one, you've lost everything. With agents, what you need is a visitor badge that says who, what, when, and why — and automatically expires.
What Agent Auth Actually Needs
1. Scoped, Ephemeral Identity
Every agent needs its own unique identity — not one shared across agents or users. That identity should be:
Tied to a customer and user
Temporary (minutes to hours)
Strictly scoped to specific actions or resources
2. Delegation with Provenance
It should be easy to trace an agent's authority back to the user who granted it. Think OAuth, but nested:
"Agent A was authorized by User X to access Resource Y for Purpose Z"
And that authorization can be revoked by the user, the admin, or the platform
3. Audit and Observability
It must be clear what each agent did, on whose behalf, and when:
Every token should carry identity and intent metadata
Every action should be logged with full traceability
4. Policy as Code
You shouldn't be managing access logic in a UI. Agent access must be:
Declarative
Version-controlled
Integrated with CI/CD and testable before deploy
Infrastructure as code has won. Access control should follow.
What's Next
The shift to agent-driven software isn't theoretical. It's happening now:
Businesses are connecting OpenAI or LangChain agents directly to their CRMs, ERPs, and internal tools.
SaaS platforms are fielding requests for third-party agent support from their customers.
Internal product teams are using agents to extend workflows, build copilots, and reduce manual load.
If those agents can't authenticate securely — scoped, revocable, and auditable — the risk compounds fast.
Agent auth is not just auth. It's identity, access, and trust — redesigned for a new class of actor.
And it's coming whether you're ready or not.