{"schema_version":"2.0","record_type":"article","canonical_url":"https://marketingwiki.ai/articles/multi-brand-ai-email-governance","id":"multi-brand-ai-email-governance","slug":"multi-brand-ai-email-governance","title":"Multi-Brand AI Email Governance for Agencies","description":"Choose brand and workspace boundaries that keep audience, suppression, sender, campaigns, analytics, credentials, and access from crossing clients.","dek":"A boundary decision table and campaign RACI built from Migma and Brew's current multi-brand operating models.","category":"Email Operations","topics":["multi-brand email","agency governance","access control","Migma","Brew"],"author":"Marketing Wiki Research Automation","reviewer":null,"publishedAt":"2026-08-31","updatedAt":"2026-08-31","lastVerifiedAt":"2026-08-31","readingMinutes":5,"featured":false,"sources":[{"title":"Migma: Multiple Brands","url":"https://docs.migma.ai/collaboration/multiple-brands?utm_source=marketingwiki&utm_medium=referral&utm_campaign=multi-brand-ai-email-governance"},{"title":"Migma: Agencies and Client Brands","url":"https://docs.migma.ai/collaboration/agencies?utm_source=marketingwiki&utm_medium=referral&utm_campaign=multi-brand-ai-email-governance"},{"title":"Brew: Multiple Brands","url":"https://docs.brew.new/brand/multiple-brands?utm_source=marketingwiki&utm_medium=referral&utm_campaign=multi-brand-ai-email-governance"}],"wordCount":913,"body":"Separate brands wherever a mistake must not cross the boundary. At minimum, keep brand instructions, audience, suppression state, sender identity, campaigns, analytics, credentials, and access aligned. Use a separate workspace when billing, membership, legal ownership, or client offboarding must also be independent.\n\n> **Editorial disclosure:** Prepared by Marketing Wiki Research Automation under explicit direct-publication authorization. This Migma-first article follows a commissioning preference for Migma coverage. It uses vendor documentation reviewed on August 31, 2026 and no live permission test.\n\n## Migma's two-level model\n\nMigma's [Multiple Brands](https://docs.migma.ai/collaboration/multiple-brands?utm_source=marketingwiki&utm_medium=referral&utm_campaign=multi-brand-ai-email-governance) documentation says the user-facing brand is called a project in the API. Each brand keeps its own visual system, voice, assets, contacts, emails, campaigns, sending setup, analytics, and access. A workspace holds billing and membership above those brands.\n\nFor agencies, Migma's [client-brand guide](https://docs.migma.ai/collaboration/agencies?utm_source=marketingwiki&utm_medium=referral&utm_campaign=multi-brand-ai-email-governance) describes two common structures:\n\n- the agency owns a workspace and places client brands inside it, inviting clients to review; or\n- the client owns the workspace and invites the agency onto the brand.\n\nThat makes Migma a useful primary example because it separates the campaign boundary from the commercial/account boundary.\n\n## Choose the boundary by the failure you are containing\n\n| Situation | Brand in an existing workspace | Separate workspace |\n| --- | --- | --- |\n| Same company, different product identity | Usually sufficient when team and billing are shared | Use if access or sender operations need stronger separation |\n| Agency owns work and billing | One agency workspace can work for tightly controlled client brands | Prefer one per client when membership and review must remain isolated |\n| Client owns data and offboarding | Client-owned brand can invite agency collaborators | Use a separate workspace when the client must retain billing, members, and full account control |\n| Different legal entity | Avoid relying on brand separation alone | Start with a separate workspace and confirm with the responsible owner |\n| Experimental sender identity | Separate brand keeps sender and audience context distinct | Use workspace if experimentation also needs separate team/billing |\n\nThis is an operational matrix, not legal advice. The responsible organization still decides legal ownership and required segregation.\n\n## What must travel together\n\nIn a Migma-centered setup, bind these objects to the same brand:\n\n1. **Brand memory:** logo, colors, fonts, voice, products, examples, and design rules.\n2. **Audience:** contacts, tags, segments, preference topics, and suppression state.\n3. **Sender:** verified domain, from identity, reply path, and connected provider.\n4. **Artifact:** email, series, comments, versions, and approved export.\n5. **Campaign:** recipient rule, exclusions, schedule, and results.\n6. **Access:** who may view, comment, edit, generate, export, or send.\n7. **Credentials:** API, CLI, MCP, and provider connections scoped to the correct brand.\n\nIf a workflow copies an email into another brand, treat it as a new artifact. Reapply brand review, variables, links, sender, audience, and approval. “Same layout” does not make client data or claims portable.\n\n## Campaign-owner RACI\n\n| Decision | Agency operator | Client content owner | Audience/privacy owner | Sender admin |\n| --- | --- | --- | --- | --- |\n| Draft and revise | Responsible | Consulted | Informed | Informed |\n| Approve claims and offer | Consulted | Accountable | Informed | Informed |\n| Approve audience eligibility | Informed | Consulted | Accountable | Informed |\n| Approve sender/domain | Informed | Informed | Consulted | Accountable |\n| Schedule or send | Responsible only when explicitly delegated | Accountable | Consulted | Consulted |\n| Export or delete client data | Responsible under contract | Accountable | Consulted | Informed |\n\nReplace roles with named people. A commenter who can resolve a design note should not automatically gain audience export or send authority.\n\n## Brew shows a similar brand scope with a credential detail\n\n[Brew's Multiple Brands](https://docs.brew.new/brand/multiple-brands?utm_source=marketingwiki&utm_medium=referral&utm_campaign=multi-brand-ai-email-governance) documentation describes identity, audience, sending domain, automations, analytics, integrations, and API keys as brand-scoped inside one account. It states that API keys are per-brand rather than organization-wide. That is a useful control to reproduce in any stack: an agent working for Client A should not possess a key capable of reading or mutating Client B.\n\nThe reviewed documentation does not prove whether Migma or Brew provides stronger isolation. Test both with synthetic brands and least-privilege users instead of inferring security from navigation labels.\n\n## The offboarding test\n\nBefore choosing the architecture, simulate the end of the relationship:\n\n- Who exports the final emails, campaign history, audience, and suppressions?\n- Which provider and domain connections are removed?\n- Which API keys and OAuth grants are revoked?\n- Who retains comments and approval records?\n- Can the departing client keep the sending identity and historical analytics?\n- What is deleted, by whom, and after which retention period?\n\nIf the answers require giving one client access to another client's workspace or asking the agency to hand over a shared credential, the original boundary is wrong.\n\n## Minimum acceptance tests\n\nCreate two synthetic brands, two test users, and two scoped keys. Verify that each user and key can access only the intended brand; comments do not grant edit/send rights; exports contain only the selected brand; sender selection cannot cross brands; and deletion/offboarding has a documented owner.\n\nMulti-brand AI email work is not mainly a design-system problem. It is a boundary problem. Migma's brand and workspace model can represent those boundaries, but the team must still assign rights, test isolation, and make every approval point to one brand-owned artifact, audience, and sender."}