Update to MailChannels

{
  "name": "mailchannels-safe-automation",
  "description": "Build controlled MailChannels outbound email for AI agents, autonomous workflows, user-generated content, or customer-managed senders. Use when a semi-trusted actor can choose recipients, sender identity, content, or volume and the system needs authorization, consent checks, budgets, approvals, audit trails, suppressions, signed delivery feedback, credential isolation, or independent suspension. This skill adds application safeguards; it does not claim MailChannels alone enforces them.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 266
    },
    {
      "relative_path": "references/safety-controls.md",
      "size_in_bytes": 2398
    }
  ],
  "skill_md_contents": "---\nname: mailchannels-safe-automation\ndescription: Build controlled MailChannels outbound email for AI agents, autonomous workflows, user-generated content, or customer-managed senders. Use when a semi-trusted actor can choose recipients, sender identity, content, or volume and the system needs authorization, consent checks, budgets, approvals, audit trails, suppressions, signed delivery feedback, credential isolation, or independent suspension. This skill adds application safeguards; it does not claim MailChannels alone enforces them.\n---\n\n# Safe Automated Email with MailChannels\n\nKeep the MailChannels credential behind a trusted application control plane.\nNever expose it to the actor requesting the email.\n\nRead [references/safety-controls.md](references/safety-controls.md) before\nimplementing an autonomous, user-generated, or downstream-customer send path.\n\n## Enforce the control flow\n\n1. Authenticate the human, service, tenant, and automated actor.\n2. Authorize the sender, recipient scope, message class, and requested volume.\n3. Resolve consent and suppression state before rendering.\n4. Render an allowlisted template or validate user-generated content.\n5. Reserve budget atomically before submission.\n6. Require approval for policy-defined risk. Bind the approval to rendered\n   content, recipients, sender, volume, and expiration.\n7. Create an immutable send intent and let a trusted worker claim it once.\n8. Load the provider credential only inside that worker and submit the message.\n9. Record the request identifier without logging secrets or unnecessary\n   message content.\n10. Verify signed webhooks and update delivery, suppression, and risk state\n    idempotently.\n\n## Use provider controls precisely\n\nMap a sub-account to a meaningful downstream trust boundary when operationally\nappropriate. Sub-accounts do not require a minimum monthly-send plan. Use their\nseparate credentials, send limit, usage, suppression list, and webhooks for\nrevocation and attribution. Keep application authorization and atomic budgets\nbecause the provider limit is only a backstop and the parent ceiling still\napplies.\n\nIf a deployment chooses not to use sub-accounts, preserve the same\napplication-level identity, budget, suspension, and audit boundaries.\n\n## Fail closed\n\n- Reject missing authorization, consent, budget, approval, or sender ownership.\n- Reject unverified webhook events.\n- Reconcile ambiguous submissions before retrying.\n- Stop future sends after applicable complaints, opt-outs, or hard failures.\n- Revoke the narrowest credential and suspend the affected boundary after a\n  suspected compromise.\n\nTest recipient-scope bypass, approval tampering, concurrent budget exhaustion,\nduplicate work, webhook replay, cross-tenant access, and independent\nsuspension.\n"
}