Email Agent安全運用

email agentは誤宛先、reply thread、添付、機密情報、送信の不可逆性が一つのtool callに重なるため、draftとsendを分離した証拠可能な運用が必要。

application / interoperability / organization overlay / security / audit

Gmail API上でdraft生成と送信が別操作であることは確認できるか。それは人間承認・宛先安全・機密漏えい防止を保証するか。

• source class: official API documentation; exact title: Create and send email messages; author/org: Google for Developers; canonical URL: https://developers.google.com/workspace/gmail/api/guides/sending publication/update/access: current page accessed 2026-09-13 JST; version/release/tag/commit/API revision/model ID: Gmail API v1 resource/methods messages.send and drafts.send; supporting locator: lines 93-105（direct messages.sendとdrafts.sendの二経路、raw MIME/base64URL）; lines 205-240（draft作成sample）; lines 264-266, 303-369（attachmentを含むdraft例）; evidence label: VERIFIED_SPEC + PRODUCT_VOLATILE; relation: support / limit.
• source class: standards-track protocol; exact title: RFC 2822: Internet Message Format; author/org: P. Resnick, editor / IETF Network Working Group; canonical URL: https://www.rfc-editor.org/rfc/rfc2822 publication/update/access: 2001-04, now obsolete and superseded by RFC 5322 / accessed 2026-09-13 JST; version/release/tag/commit/API revision/model ID: RFC 2822; supporting locator: info page lines 48-65, 82-89, 185-209（message syntax and scope）; lines 193-201（MIME extensions are outside this RFC）; evidence label: VERIFIED_SPEC + PRODUCT_VOLATILE; relation: context / limit.

Gmail APIは直接sendとdraft経由sendを別methodとして公開し、MIME messageとattachmentの作成を要求する。これにより、生成→検査→承認→送信を技術的に別段階へ配置する設計は可能だが、API仕様は「人間が承認した」「宛先が正しい」「添付が安全」「本文が秘密を含まない」ことを保証しない。RFC 2822はInternet Message Formatのsyntaxで、添付等はMIME extension側であり、宛先判断・業務承認・privacy lawは別層である。

RFC 2822はobsoleteであり、現行のRFC 5322へ更新が必要。Gmail APIの公開Docsは特定tenantのadmin policy、DLP、送信後recall、実際のUI警告を証明しない。誤reply、Bcc、alias、thread、添付版違い、外部recipient、代理送信は別failure class。

OAuth scope、ユーザー/ドメイン管理、Gmail API quota、送信権限、外部recipient制限、DLP/情報分類、providerの契約を確認する必要がある。実アカウントで送信・draft作成は未実施。

proposed two-phase mail agent（draft-only default、recipient/attachment/content lint、explicit approval token、send endpoint分離、post-send audit）。実装・安全性試験未実施。

synthetic mailbox fixtureでrecipient exactness、reply headers、attachment hash/name, confidential-marker handling, approval bypass, duplicate send/retry idempotencyを測る。実送信はしない。

SECURITY/PRIVACY: secrets/PIIはsyntheticのみ、DLP preflight。AUDIT: draft ID、content hash、recipient、approval actor/time、send result、provider message ID。COST: API quotaとhuman review工数。OPERABILITY: sendをdefault denyにし、失敗時に自動retryせずdraftへ戻す。

「Gmail APIはmessages.sendとdrafts.sendを別methodとして提供するため、draft→検査→明示承認→sendという制御点を設計できる。ただし、APIの存在は宛先正確性、承認、DLP、法的適合、送信後回収を保証しない。」

本文改訂では、agentの自然言語能力よりもsend capability、OAuth scope、admin/DLP、draft-only、approval evidence、idempotencyを表にする。RFC 5322とMIMEの現行一次資料を再採集し、providerごとのalias/thread挙動をTEST_PROFILE化する。

RFC 5322準拠範囲、Gmailのtenant別DLP/外部送信設定、reply/alias/Bccのagent failure rate、送信取消可能性、他providerとの差。

draft作成成功を安全な送信成功と扱わない。公開API Docsから特定組織の設定・実挙動を推定しない。 UNIT_CLOSE_STATUS: INDIVIDUAL_BOUNDED_CLOSE / EVIDENCE_RECORDED / UNKNOWN_PRESERVED

---