# Email Agent安全運用 CURRENT_STATUS: UNKNOWN OBSERVATION: SPEC_ONLY FRESHNESS: UNKNOWN PAGE_TYPE: reference CANONICAL_URL: /tools/ea-113-email-agent CLAIM_IDS: none EVIDENCE_IDS: EVD-EA-113-URL-BD90285E2563, EVD-EA-113-URL-9C4C1B2FCF9E, EA-113-R11-RESEARCH, EA-113-R11-WEB-READBACK UNKNOWN_IDS: EA-113-UNKNOWN-01, EA-113-UNKNOWN-CURRENTNESS OPS_IDS: none ## Summary 「Gmail APIはmessages.sendとdrafts.sendを別methodとして提供するため、draft→検査→明示承認→sendという制御点を設計できる。ただし、APIの存在は宛先正確性、承認、DLP、法的適合、送信後回収を保証しない。」 ## Current judgment Gmail APIは直接sendとdraft経由sendを別methodとして公開し、MIME messageとattachmentの作成を要求する。これにより、生成→検査→承認→送信を技術的に別段階へ配置する設計は可能だが、API仕様は「人間が承認した」「宛先が正しい」「添付が安全」「本文が秘密を含まない」ことを保証しない。RFC 2822はInternet Message Formatのsyntaxで、添付等はMIME extension側であり、宛先判断・業務承認・privacy lawは別層である。 ## Scope application / interoperability / organization overlay / security / audit ## Confirmed - Gmail APIは直接sendとdraft経由sendを別methodとして公開し、MIME messageとattachmentの作成を要求する。これにより、生成→検査→承認→送信を技術的に別段階へ配置する設計は可能だが、API仕様は「人間が承認した」「宛先が正しい」「添付が安全」「本文が秘密を含まない」ことを保証しない。RFC 2822はInternet Message Formatのsyntaxで、添付等はMIME extension側であり、宛先判断・業務承認・privacy lawは別層である。 ## UNKNOWN - EA-113-UNKNOWN-01: RFC 5322準拠範囲、Gmailのtenant別DLP/外部送信設定、reply/alias/Bccのagent failure rate、送信取消可能性、他providerとの差。 - EA-113-UNKNOWN-CURRENTNESS: 外部根拠の再確認日がcanonical body/control-planeで確定していないため、currentnessはUNKNOWNとして保持する。日付を推測補完しない。 ## Evidence - EVD-EA-113-URL-BD90285E2563 (RESEARCH): 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 - EVD-EA-113-URL-9C4C1B2FCF9E (RESEARCH): 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 - EA-113-R11-RESEARCH (RESEARCH): EA-113 監査済みresearch / canonical revision binding - EA-113-R11-WEB-READBACK (IMPL): EA-113 Web body identity / canonical readback ## Failure / limits RFC 2822はobsoleteであり、現行のRFC 5322へ更新が必要。Gmail APIの公開Docsは特定tenantのadmin policy、DLP、送信後recall、実際のUI警告を証明しない。誤reply、Bcc、alias、thread、添付版違い、外部recipient、代理送信は別failure class。 ## Failure / limits draft作成成功を安全な送信成功と扱わない。公開API Docsから特定組織の設定・実挙動を推定しない。 UNIT_CLOSE_STATUS: INDIVIDUAL_BOUNDED_CLOSE / EVIDENCE_RECORDED / UNKNOWN_PRESERVED --- ## Practice OAuth scope、ユーザー/ドメイン管理、Gmail API quota、送信権限、外部recipient制限、DLP/情報分類、providerの契約を確認する必要がある。実アカウントで送信・draft作成は未実施。 ## Practice proposed two-phase mail agent（draft-only default、recipient/attachment/content lint、explicit approval token、send endpoint分離、post-send audit）。実装・安全性試験未実施。 ## Practice synthetic mailbox fixtureでrecipient exactness、reply headers、attachment hash/name, confidential-marker handling, approval bypass, duplicate send/retry idempotencyを測る。実送信はしない。 ## Practice 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へ戻す。 ## Practice 本文改訂では、agentの自然言語能力よりもsend capability、OAuth scope、admin/DLP、draft-only、approval evidence、idempotencyを表にする。RFC 5322とMIMEの現行一次資料を再採集し、providerごとのalias/thread挙動をTEST_PROFILE化する。 ## WHY_THIS_MATTERS_TO_UPDATE email agentは誤宛先、reply thread、添付、機密情報、送信の不可逆性が一つのtool callに重なるため、draftとsendを分離した証拠可能な運用が必要。 ## SCOPE_ROUTING application / interoperability / organization overlay / security / audit ## CLAIM_OR_RESEARCH_QUESTION Gmail API上でdraft生成と送信が別操作であることは確認できるか。それは人間承認・宛先安全・機密漏えい防止を保証するか。 ## EVIDENCE TABLE - 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. ## FINDINGS Gmail APIは直接sendとdraft経由sendを別methodとして公開し、MIME messageとattachmentの作成を要求する。これにより、生成→検査→承認→送信を技術的に別段階へ配置する設計は可能だが、API仕様は「人間が承認した」「宛先が正しい」「添付が安全」「本文が秘密を含まない」ことを保証しない。RFC 2822はInternet Message Formatのsyntaxで、添付等はMIME extension側であり、宛先判断・業務承認・privacy lawは別層である。 ## LIMITS / COUNTEREVIDENCE / FAILURE ENVELOPE RFC 2822はobsoleteであり、現行のRFC 5322へ更新が必要。Gmail APIの公開Docsは特定tenantのadmin policy、DLP、送信後recall、実際のUI警告を証明しない。誤reply、Bcc、alias、thread、添付版違い、外部recipient、代理送信は別failure class。 ## AVAILABILITY_GATES OAuth scope、ユーザー/ドメイン管理、Gmail API quota、送信権限、外部recipient制限、DLP/情報分類、providerの契約を確認する必要がある。実アカウントで送信・draft作成は未実施。 ## IMPLEMENTATION_STATE proposed two-phase mail agent（draft-only default、recipient/attachment/content lint、explicit approval token、send endpoint分離、post-send audit）。実装・安全性試験未実施。 ## BENCHMARK_OR_EVAL synthetic mailbox fixtureでrecipient exactness、reply headers、attachment hash/name, confidential-marker handling, approval bypass, duplicate send/retry idempotencyを測る。実送信はしない。 ## SECURITY / PRIVACY / AUDIT / COST / OPERABILITY 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へ戻す。 ## SAFE_WORDING_FOR_FUTURE_BOOK 「Gmail APIはmessages.sendとdrafts.sendを別methodとして提供するため、draft→検査→明示承認→sendという制御点を設計できる。ただし、APIの存在は宛先正確性、承認、DLP、法的適合、送信後回収を保証しない。」 ## UPDATE_WORK_HANDOFF 本文改訂では、agentの自然言語能力よりもsend capability、OAuth scope、admin/DLP、draft-only、approval evidence、idempotencyを表にする。RFC 5322とMIMEの現行一次資料を再採集し、providerごとのalias/thread挙動をTEST_PROFILE化する。 ## OPEN_UNKNOWN RFC 5322準拠範囲、Gmailのtenant別DLP/外部送信設定、reply/alias/Bccのagent failure rate、送信取消可能性、他providerとの差。 ## STOP_CONDITION draft作成成功を安全な送信成功と扱わない。公開API Docsから特定組織の設定・実挙動を推定しない。 UNIT_CLOSE_STATUS: INDIVIDUAL_BOUNDED_CLOSE / EVIDENCE_RECORDED / UNKNOWN_PRESERVED --- NEXT: /agent/start.json STOP: This is a knowledge projection, not an execution order.