Overview
Expose account suggestion, direct send, semantic send and template send to authorized workspace apps and Bridge clients without giving callers direct mailbox credentials.
Problem
Applications need a stable email service boundary that preserves caller identity, sender ownership and message/template policy.
Solution
Use Email Hub capabilities with operation grants, resource authorization, delegation checks and trusted Handler/RCP or scoped Bridge v2 transports.
How it works
Callers discover system capabilities, receive only authorized operations, and invoke Email Hub through canonical runtime execution. Sender accounts, drafts, templates, versions, message bindings and Bridge resources are checked before mutating actions proceed.
Who is this for
Expected outcomes
- Mailbox secrets remain inside the governed Email Hub boundary
- Application email calls retain trusted provenance and resource authorization
Key metrics
Security impact
- Caller application identity, operation/scopes, sender/template/message resources, recipients and request metadata · PII: yes where email addresses, message content, attachments, recipients, or integration payloads contain personal data
Compliance
- Trusted execution provenance
- Operation, delegation and resource authorization