Your AI Agent Has a Wallet But No ID — Fixing the Agent Identity Problem

Last week AgentMail launched on HN and hit 169 points. YC S25. Their pitch: "An API that gives agents their own email inboxes."

Not email for humans. Email addresses for AI agents. Inboxes only agents check. SMTP endpoints that agents can use to verify identity, receive confirmations, and communicate with other agents.

This isn't a gimmick. It's a symptom of the biggest unsolved problem in agentic payments: agents don't have identity.

The Shape of the Problem

Here's what happens when your agent tries to spend money today:

Agent → Stripe API → "Who are you?"
Agent → "I have an API key."
Stripe → "Whose API key?"
Agent → "...the developer's?"
Stripe → "OK, but which agent? Which task? Which budget?"
Agent → [no answer — the protocol has no field for this]

Every agent payment stack I've written about — authorization wrappers, policy engines, spending mandates — sits on top of a fragile assumption: that the payment rail knows which agent is making the request.

It doesn't. Stripe sees an API key. OpenAI sees an API key. AWS sees an IAM role. None of them see agent identity. And if you can't identify the spender, you can't enforce per-agent budgets, audit individual agents, or revoke a rogue agent without revoking the human's credentials too.

What's Shipping Right Now

The HN front page is suddenly full of agent identity projects. Not because identity is new — because agent payments are moving from demos to production, and teams are hitting this wall in the same week.

Kontext CLI (70 HN points): A credential broker for coding agents. Instead of raw API keys, your agent gets a reference that resolves at runtime. The broker injects the actual credential, logs which agent used it, and rotates it after use. It's the "IAM roles for agents" pattern — temporary, scoped, auditable.

Pomerium Agentic Access Gateway (10 HN points): Zero-trust proxy extended for AI agents. Agents authenticate to the gateway (not individual services), and the gateway enforces policy. Agents get their own identity, separate from the human who deployed them.

AgentMail (YC S25, 169 HN points): Email as an identity primitive. An agent with its own email address can receive verification codes, sign up for services, and present verifiable identity to APIs. It's low-tech but it works — email has been the web's identity layer for 30 years.

Grantex: An IETF-submitted draft for agent authorization — think OAuth without the human click-through consent flow.

Vouch Protocol: C2PA + DID for AI agents. Uses the same content authenticity standard Adobe and Microsoft adopted, applied to agent identity.

The Pattern Nobody's Naming

All of these projects share the same architecture:

Agent → Identity Broker → Credential Injection → Service
         ↑                    ↑
    (who is this?)      (what can they do?)
         ↑
    Audit Log (who did what, when, with which credential)

This is not new computer science. It's Kerberos. It's SPIFFE. It's every service-to-service auth pattern from the last 20 years, finally reaching the agent layer.

The difference: in microservices, identity is tied to a pod or a VM. In agents, identity needs to follow the task. Agent A working on task X might need different permissions than Agent A working on task Y. The identity is contextual, not static.

What to Build Today

Here's the minimum viable agent identity layer you can ship now:

# agent_identity.py — minimum viable agent identity layer
import hashlib
import time
import json

class AgentIdentity:
    def __init__(self, agent_id: str, task_id: str, human_approver: str):
        self.agent_id = agent_id
        self.task_id = task_id
        self.human_approver = human_approver
        self.session_start = time.time()

    def inject_headers(self, request: dict) -> dict:
        """Add agent identity headers to every API call."""
        request["headers"]["X-Agent-ID"] = self.agent_id
        request["headers"]["X-Task-ID"] = self.task_id
        request["headers"]["X-Agent-Session"] = hashlib.sha256(
            f"{self.agent_id}:{self.task_id}:{self.session_start}".encode()
        ).hexdigest()[:16]
        return request

    def audit_log(self, action: str, amount: float, vendor: str):
        """Write immutable audit entry for every spend action."""
        entry = {
            "timestamp": time.time(),
            "agent_id": self.agent_id,
            "task_id": self.task_id,
            "action": action,
            "amount": amount,
            "vendor": vendor,
            "session_hash": hashlib.sha256(
                f"{self.agent_id}:{self.task_id}:{self.session_start}".encode()
            ).hexdigest()[:16]
        }
        return json.dumps(entry)

Three headers: X-Agent-ID, X-Task-ID, X-Agent-Session. That's it. The services you're paying (OpenAI, AWS, Stripe) will ignore them today — but your auth proxy, audit trail, and policy engine can use them immediately. When payment rails add agent identity fields (and they will — Visa's Replit investment is the signal), you'll already have the data.

The Bottom Line

AgentMail hitting 169 HN points isn't about email. It's about builders realizing the agent payment stack is missing its foundation. You can't have authorization without authentication. You can't have authentication without identity. And right now, agents have neither.

The teams shipping the identity layer — Kontext, Pomerium, AgentMail, Grantex, Vouch — are building the primitives every agent payment stack will depend on. When your CFO asks "which agent spent $4,200 on that API bill" and your audit trail says "API key sk-...xyz" — you don't have an answer. That answer starts with agent identity.

---

AgentPay Labs — Building the payment control plane for autonomous agents.
Previously: Visa Just Bet on Agentic Payments | Agent Spend Compliance