-
Layer 1 — Define the integration boundary
Map the private-message data flow
Start by documenting the full path of message data before approving any scope, connector, model, storage, tool, or automation.
- Action
- Draw the path from Gmail or WhatsApp source to connector or webhook, backend broker, minimization layer, model call, structured extraction, tool broker, approval queue, execution adapter, audit log, storage, and deletion path.
- Verify
- The map shows every place where message data can enter, transform, persist, trigger a tool, leave the system, or require deletion.
-
Layer 1 — Define the integration boundary
Confirm the supported platform surface
The controls depend on the exact platform surface and cannot be inferred from a generic description of the agent.
- Action
- Record the account type, app or connector, OAuth scopes, webhook events, WABA, phone number ID, API version, solution provider, automation platform, model provider, backend service, and processor list.
- Verify
- Unsupported personal WhatsApp automation, undocumented APIs, and assumed connector behavior are excluded or marked not verified.
-
Layer 2 — Collect required inputs
Complete the prerequisite inventory
Do not design controls from a vague description of the agent. Gather the concrete implementation facts first.
- Action
- Complete the inventory for integration surface, actor boundary, permissions, Google disclosure path, WhatsApp Business Solution Data path, model-exposed data, model and processor path, side-effecting actions, storage, retention, and deletion.
- Verify
- The inventory is sufficient to decide scopes, data minimization, tool isolation, approvals, logging, retention, and revocation.
-
Layer 3 — Apply the connection safety gate
Block unsafe integrations before implementation
If a blocking condition is present, do not proceed by adding a warning or relying on the model to behave safely.
- Action
- Check for excessive permissions, message content acting as authority, model-visible credentials, unapproved high-risk actions, unresolved Google or WhatsApp data-use constraints, missing audit, missing deletion, and missing revocation.
- Verify
- Every blocking condition is resolved, redesigned, restricted, or recorded as a reason to block the connection.
-
Layer 4 — Design data minimization and redaction
Create the minimization and redaction contract
The model should receive only the data required for the task and no more.
- Action
- Define allowed fields, withheld fields, masked fields, source IDs, attachment handling, media handling, link handling, quoted-thread handling, secret handling, unrelated-history handling, and omitted-data markers.
- Verify
- Full inboxes, full chat histories, raw attachments, unrelated thread history, credentials, secrets, and unnecessary personal data are not exposed by default.
-
Layer 5 — Design Gmail and WhatsApp permissions separately
Build the Gmail permission matrix
Gmail permissions must be tied to user-facing capability, not convenience or anticipated future use.
- Action
- Create a matrix with workflow need, Gmail OAuth scope or connector permission, application-level constraint, data exposed, action enabled, sensitive or restricted status, storage location, disclosure requirement, approval requirement, and default allow/block decision.
- Verify
- Least-privilege OAuth scopes are selected; application-level constraints limit the workflow to selected messages or selected threads where needed; draft-only is preferred before send; modify, delete, export, and broad mailbox access are treated as high-risk.
-
Layer 5 — Design Gmail and WhatsApp permissions separately
Build the WhatsApp data-use and outbound-message matrix
WhatsApp Business Platform data has a different data-use, processor, and outbound-message model from Gmail.
- Action
- Create a matrix with WABA, phone number ID, webhook event, payload fields, media retrieval, outbound-message path, conversation type, customer service window status, approved template requirement, template ID, processor, model exposure, AI-provider status, retention period, prohibited use, and approval rule.
- Verify
- Business Solution Data is not transferred, retained, exposed, or used in a way that conflicts with the applicable WhatsApp terms and approved use case; outbound messages satisfy applicable conversation-window and template requirements.
-
Layer 5 — Design Gmail and WhatsApp permissions separately
Classify WhatsApp AI-provider and processor use
WhatsApp Business Solution Data controls depend on whether a solution provider, third-party service provider, or AI provider receives or processes the data.
- Action
- Record whether AI is the primary or ancillary functionality, whether an AI provider receives Business Solution Data, whether any training, improvement, fine-tuning, analytics, retention, or human review occurs, and what contractual restrictions apply.
- Verify
- AI-provider and processor use is explicitly allowed for the workflow, or the integration is redesigned to avoid that exposure.
-
Layer 6 — Isolate tokens, tools, memory, and side effects
Keep credentials outside model context
Credentials and authorization headers are operational secrets, not model input.
- Action
- Store OAuth tokens, refresh tokens, WhatsApp access tokens, app secrets, webhook secrets, API keys, and authorization headers in backend secret storage. Expose only named backend tools to the model.
- Verify
- The model cannot read, summarize, store, output, transform, or leak credentials.
-
Layer 6 — Isolate tokens, tools, memory, and side effects
Treat message content as untrusted input
Private messages can contain attacker-controlled instructions or misleading authority claims.
- Action
- Wrap message content as data and prevent it from overriding system rules, user approval, platform terms, permissions, tool rules, recipient validation, or memory rules.
- Verify
- A message that asks the agent to ignore rules, forward a thread, delete evidence, choose a recipient, store memory, or bypass approval is analyzed as content and not executed as authority.
-
Layer 6 — Isolate tokens, tools, memory, and side effects
Convert message content into validated structured fields
Tool calls should be built from constrained fields, not raw message text.
- Action
- Define fields such as source_message_id, requested_action, proposed_recipient, recipient_trust_level, attachment_ids, external_destination, disclosure_risk, approval_required, allowed_action, and blocked_reason. Validate fields before tool execution.
- Verify
- A hostile or ambiguous message cannot directly become a send, forward, export, delete, CRM update, WhatsApp outbound message, or memory write.
-
Layer 6 — Isolate tokens, tools, memory, and side effects
Route side effects through a backend tool broker
The model should request an action; backend enforcement should decide whether the action is allowed.
- Action
- Define one tool per capability: read selected message, summarize selected thread, create draft, send approved draft, apply label, archive, export approved attachment, update approved CRM record, create approved task, create approved calendar event, and send approved WhatsApp response.
- Verify
- The broker validates policy, identity, scope, recipient, destination, attachment, action type, approval state, rate limit, reversibility, and audit requirement before execution, and can reject a tool call even when the model requests it.
-
Layer 6 — Isolate tokens, tools, memory, and side effects
Require operation-specific approval for side effects
Approval must show the exact action and data movement before execution.
- Action
- Build approval rules for send, reply, forward, delete, archive, label, export, upload, CRM update, task creation, calendar creation, WhatsApp outbound message, and memory write.
- Verify
- A generic continue button is not sufficient; the approver sees source, account, data, recipient, destination, attachment, tool, reversibility, and policy result.
-
Layer 6 — Isolate tokens, tools, memory, and side effects
Block automatic memory writes from private messages
Private messages can contain third-party claims, temporary facts, confidential context, and sensitive data.
- Action
- Disable automatic memory writes. If memory is required, create reviewable memory proposals with source, scope, owner, expiration, review path, and deletion path.
- Verify
- Message content does not become durable memory, profile data, user preference, routing rule, or future instruction without explicit approval and deletion control.
-
Layer 7 — Verify logging, retention, revocation, and adversarial tests
Implement audit logging and revocation
Reviewers must be able to reconstruct every side effect without relying on the model's narrative summary.
- Action
- Log source ID, redaction status, model input ID, model output ID, extracted fields, tool name, validated arguments, approval state, approver, destination, timestamp, block reason, and execution result. Document token revocation, webhook unsubscribe, secret rotation, connector disablement, tool suspension, and data purge.
- Verify
- The integration can be investigated and shut down without leaving active credentials, background jobs, webhooks, tools, or unreviewed stored data.
-
Layer 7 — Verify logging, retention, revocation, and adversarial tests
Run adversarial message tests
Test the full data path, not only the model's final answer.
- Action
- Test hostile or ambiguous instructions in body text, subject lines, sender display names, quoted replies, forwarded content, attachments, screenshots, media captions, contact cards, links, and unrelated thread history.
- Verify
- The system blocks unauthorized instructions, prevents unsafe tool calls, keeps private data inside boundaries, logs the block reason, and preserves approval requirements.