Show HN: AgentLair – Give your AI agent an email identity and credential vault (opens in new tab)

(agentlair.dev)

2 pointshawk_aa1mo ago2 comments

Supply chain attacks like the LiteLLM compromise exfiltrate every env var, SSH key, and API key from compromised machines. AgentLair Vault prevents this architecturally — credentials are never in the environment.

I built AgentLair to give AI agents a real identity — not just an email address.

AgentMail raised $6M to solve the email problem. They've done great work, and email IS the starting point. But an agent's identity is more than email: it's the credentials it carries and the namespace it operates in.

What AgentLair is (all in one API):

1. Email — claim my-agent@agentlair.dev, send/receive, MCP-native. One curl call. No OAuth, no human in the loop.

2. Vault — encrypted credential storage. Your agent stores its own API keys at registration, fetches them at runtime. The server stores opaque blobs — you encrypt client-side with our SDK or your own scheme.

3. Pods — multi-tenant namespace isolation. Run multiple agents under one account; each pod only sees its own resources. Useful for SaaS products built on agents.

Self-registration in one call:

  curl -X POST https://agentlair.dev/v1/auth/agent-register \
    -H "Content-Type: application/json" \
    -d '{"name": "my-research-agent"}'

  → { "api_key": "al_live_...", "email_address": "my-research-agent@agentlair.dev", "account_id": "..." }

The agent gets an identity in a single call. No human in the loop anywhere.

MCP server (npm):

  npx @agentlair/mcp@latest

Works with Claude, Cursor, or any MCP-compatible client. 9 tools covering email and vault operations.

Why this now:

The MCP authentication story is broken. Perplexity's CTO left MCP over "authentication friction." VentureBeat: "When Agent A delegates to Agent B, no identity verification happens between them. A compromised agent inherits the trust of every agent it communicates with."

A Cloud Security Alliance study (March 25, 2026) found that more than two-thirds of organizations cannot clearly distinguish AI agent from human actions — and 33% don't know how often their agent credentials are rotated. (https://www.businesswire.com/news/home/20260324161665/en/)

The protocol for tool access exists. The identity layer underneath it doesn't. AgentLair is that layer: persistent email address + credential vault + human-backed trust + micropayment hooks.

AgentMail is email-only. 1Password announced credential management for agents (enterprise-only). We bundle email + vault + isolation with a free tier. x402 micropayment support and World ID identity verification are next on the roadmap.

Where things are: Public beta. Pro plan is $5/stack/month for higher limits. Everything else is free tier. Free tier: 10 emails/day, 10 email addresses, 100 API requests/day.

Try it: https://agentlair.dev Docs: https://agentlair.dev/getting-started MCP: npx @agentlair/mcp@latest

vs. AgentMail: They do email well. We do email + vault + pod isolation. vs. 1Password: They do credentials for enterprises. We do $5/mo for indie devs.

2 comments

dannygerst1mo ago

The core challenge with agent credentials isn't storage. It is the handoff. How does a user securely give their OAuth token or API key to an agent that is running somewhere? Most solutions I've seen either require the agent to run inside a specific platform, or they punt on the trust problem entirely by storing credentials centrally in plaintext.

The device authorization grant (RFC 8628) pattern is interesting here because it decouples the agent from the users browser session entirely.

hawk_aaOP1mo ago

You are hitting on the real problem here. The vault itself is straightforward — we do client-side encryption so the server never sees plaintext. But the initial transfer step, getting the credential from the user to the agent securely, that is genuinely hard.

RFC 8628 is interesting exactly because it separates the authorization surface from wherever the agent runs. We have been looking at similar patterns. The tricky part is that most OAuth flows assume a browser is present, which breaks down for agents that operate autonomously.

What I find even harder though is the cross-organizational case. Not just "my agent accesses my credentials" but "your agent needs to prove to my system that it was authorized by someone I trust". At that point you need identity and authorization as separate layers, and most current solutions kind of mash them together.

Pods in AgentLair give you namespace isolation (each pod gets its own vault, email, keys), which helps for the multi-tenant case. But the trust problem across organizations is still largely unsolved infrastructure-wise.

j / k navigate · click thread line to collapse

2 comments

dannygerst1mo ago

The device authorization grant (RFC 8628) pattern is interesting here because it decouples the agent from the users browser session entirely.

hawk_aaOP1mo ago

j / k navigate · click thread line to collapse