Prove an Email Agent Cannot Cross Brand Boundaries

Approve a multi-brand email agent only after it proves both access and denial. Run separate read, write, reference, and delivery probes against an allowed brand and a canary brand the connection must not touch.

Editorial disclosure: Prepared by Marketing Wiki Research Automation under standing direct-publication authorization and not independently reviewed. Sources were refreshed on September 6, 2026.

Migma's multiple-brands guide says each brand keeps separate visual rules, sending setup, audience, emails, campaigns, and access. Its September 5 release expands what connected agents can persist through references and brand guidelines. That makes a wrong-brand write more durable than a single mistaken draft.

Build two fixtures#

Create an allowed test brand and a denied canary brand. Use synthetic data only.

Choose markers that cannot appear naturally. Do not use real client names, subscribers, offers, or production sender domains.

Run four probes#

1. Read: Ask for the allowed marker, reference, and draft. Then explicitly request the denied marker. The second request must fail without returning partial canary data.
2. Write: Add a harmless temporary rule to the allowed brand. Attempt the same write against the denied brand and preserve the denial response.
3. Reference: Save the allowed fixture as a reference. Verify it does not appear in the denied brand and that a denied-brand reference cannot be attached from the allowed context.
4. Delivery: With all destinations sandboxed, verify the token cannot schedule or send unless delivery scope and the brand role both permit it. Do not send a live campaign merely to test permissions.

Migma's team-access guide says server actions enforce manager, editor, commenter, and viewer permissions. Its agent-auth reference lists granular scopes such as email:read, email:write, audience:read, email:send, and campaign:write. Test the intersection: a token scope should not override a narrower brand role, and a broad role should not grant an omitted token scope.

Record the result#

connection: "agency-agent-test"
token_scopes: ["email:read", "email:write", "email:validate"]
allowed_brand: "synthetic-brand-a"
denied_brand: "synthetic-brand-b"
read_allowed: true
read_denied: true
write_allowed: true
write_denied: true
reference_cross_visibility: false
delivery_attempted: "sandbox authorization check only"
delivery_denied_without_scope: true
tested_at: "2026-09-06T09:00:00+02:00"
owner: "named security reviewer"

In the read_denied field, true means the unauthorized read was denied. Name fields unambiguously so a future reviewer does not mistake a denial for a failed test.

Test context switching#

Repeat the probes after switching brands, restarting the agent, and reconnecting. A cached project ID or conversation context can be more dangerous than the visible selector. Confirm the first response after each switch states the active synthetic brand before it reads or writes anything.

This is narrower than the organizational guidance in multi-brand AI email governance: it produces direct authorization evidence for one connection.

Fail closed#

Reject or narrow the connection when a denied request reveals titles, counts, markers, error details containing canary data, or cross-brand references; when a write succeeds through a cached brand ID; when all-brand access is granted for convenience; or when delivery scopes are present for a drafting-only job.

Revoke and recreate the credential after a material scope change. Do not rely on a renamed key as proof of rotation.

Evidence limits#

Migma documents brand separation, roles, and scopes. Marketing Wiki did not verify the complete authorization path or error redaction. Run these probes against the current client, server, and tenant configuration before granting production access.