Agent.Email: AI 에이전트, curl로 가입 후 인간 OTP로 인증

AgentMail (YC S25)은 Agent.Email이라는 실험을 진행했습니다. 이는 인간이 아닌 AI 에이전트를 위해 설계된 가입 플로우입니다. 논지는 다음과 같습니다. 인터넷은 인간을 위해 만들어졌으며, 기본적으로 기계의 접근을 차단합니다. 에이전트가 인간의 자격 증명 없이 제품에 가입할 수 없다면, 그들은 일류 사용자가 될 수 없습니다.

작동 방식

• 에이전트가 인박스가 필요하면 curl을 통해 AgentMail에 접속합니다.
• 에이전트는 Markdown(또는 브라우저에서 접근 시 HTML) 형식의 지침을 받습니다.
• 에이전트는 자신의 인간 이메일을 파라미터로 가입 엔드포인트에 요청합니다.
• 에이전트는 자격 증명과 함께 제한된 인박스를 받습니다. 자신의 인간에게만 이메일을 보낼 수 있으며, 하루 10회로 제한됩니다.
• 에이전트는 인간에게 OTP를 요청하는 이메일을 보내고, 인간은 코드로 응답합니다.
• 클레임이 완료되면 제한이 해제됩니다.
• 가입 엔드포인트는 IP 기준으로 엄격한 속도 제한이 적용됩니다.

현재는 1:1 에이전트-인간 관계이며, 다대일 매핑이 다음 단계입니다.

인간 중심 가정에서의 설계 변경

Agent.Email을 구축하면서 AgentMail은 기존 가정을 재검토하게 되었습니다:

• CLI 출력은 이제 일관된 형식의 단일 열을 사용합니다. 혼합 구분 기호는 인간에게는 쉽지만 에이전트가 파싱하기 어렵습니다.
• 메시지 ID는 에이전트가 긴 ID의 완성을 환각하는 것을 방지하기 위해 단축되었습니다.

커뮤니티 질문

• 클레임 전까지 제한하는 방식이 올바른 신뢰 모델인가?
• 에이전트 자체 가입이 실제 운영 환경에서 유용한가, 아니면 단순한 참신함에 불과한가?
• 에이전트 온보딩에 인간 승인이 기본적으로 필요한가, 아니면 일부 에이전트가 완전히 자체 프로비저닝해야 하는가?
• 안전한 가입을 위해 어떤 추가 조치를 취할 수 있는가?

한 HN 댓글 작성자는 악용 가능성을 지적했습니다. 에이전트가 HN 댓글을 스크래핑하여 AgentMail을 통해 타겟 스팸을 보냈습니다. 이메일에는 api.agentmail.to를 가리키는 List-Unsubscribe 헤더가 포함되어 있었습니다. 댓글 작성자는 사칭을 방지하기 위해 모든 이메일에 'AI가 작성함' 블록을 추가할 것을 제안했습니다.