AI 에이전트에게 개인 이메일을 주지 마세요. 전용 메일함을 만들어 주세요.
Don't hand your AI agent your personal email. Give it a mailbox of its own.
핵심 요약
AI 에이전트의 보안을 위해 개인 이메일 계정 대신 전용 메일함과 정책 레이어를 사용하는 모범 사례를 제안합니다.
- 보안 위험 — 개인 이메일 OAuth 토큰 공유 시 프롬프트 인젝션으로 인한 계정 탈취 위험이 있음
- 전용 메일함 — 에이전트 전용 이메일 주소를 생성하여 권한을 격리하는 패턴 권장
- 정책 레이어 — 모델이 메일을 읽기 전 차단/라우팅 규칙을 적용해 보안 가드레일 구축
- Nylas CLI — 에이전트 전용 계정 생성 및 정책 설정을 자동화하는 도구 활용
반복적으로 보이는 실수 (나도 예전에 했던 실수): 이메일을 읽거나 보내야 하는 에이전트를 만들 때, 개인 이메일의 OAuth 토큰을 붙여넣고 그냥 방치하는 경우임. 이제 프롬프트 인젝션 공격 한 번이면 에이전트가 당신인 척 메일을 보낼 수 있고, LLM과 당신의 받은 편지함 사이에는 아무런 정책 레이어도 없게 됨.
더 깔끔한 패턴은 에이전트에게 자체 관리형 메일함을 주는 거임. 빌려 쓰는 게 아니라 진짜 주소를 주고, 에이전트가 메시지를 읽기 전에 실행되는 규칙을 설정하는 거지.
솔직히 말하자면, 난 Nylas CLI에서 일하니까 편향적일 수 있음. 하지만 '에이전트에게 사람의 메일함을 주는' 안티 패턴은 우리 이전부터 있었고, 도구와 상관없이 사람들이 꼭 제대로 알았으면 하는 부분임.
방법은 다음과 같음. 최초 1회 설정으로 가입하고, 이메일 계정을 연결한 뒤 에이전트 계정을 위한 무료 도메인을 생성함:
# 가입 + 이메일 연결 + 무료 에이전트 계정 도메인
nylas init
그다음 전용 주소를 프로비저닝하고(OAuth 핸드셰이크 없음, 사람용 메일함 아님) 정책을 연결함:
# 에이전트가 소유한 메일함 프로비저닝
nylas agent account create support@myagent.nylas.email
# 에이전트가 메일을 보기 전에 실행되는 가드레일 추가
# 예: 특정 발신자 도메인 전면 차단
nylas agent rule create \
--condition from.domain,is,example.com \
--action block
이 주소는 트랜잭션 메일을 보내고 답장을 받을 수 있어서, 에이전트는 '보내고 잊어버리는' SMTP 해킹 방식이 아니라 진짜 양방향 채널을 갖게 됨. 정책을 통해 모델이 메시지를 확인하기 전에 차단 / 보관 / 라우팅을 할 수 있는데, 사람들이 이 단계를 건너뛰었다가 프롬프트 인젝션으로 당하는 거임.
MCP를 통해 에이전트에 연결하면, 제공자마다 Gmail/Graph API 코드를 직접 짤 필요 없이 모델이 이메일을 도구로 사용할 수 있음.
다들 에이전트의 메일함 접근 권한을 어떻게 설정하고 있음? 별도 계정 + 정책 방식을 쓰는지, 아니면 다른 방법이 있는지 궁금함.
