# MCP SAFETY VERDICT VERDICT: ENABLE WITH REQUIRED CONTROLS DECISION BASIS: The MCP integration has a legitimate sales-assistant use case, but its combined authority is materially stronger than its stated autonomous role. It can consume untrusted web/company data while also reaching Gmail, CRM, Sheets, calendar, authenticated browser sessions, lead creation, and email sending. The supplied design says sending email, modifying CRM records, and booking meetings require confirmation, but no runtime enforcement evidence is provided showing that approvals are action-bound, immutable, non-replayable, or impossible to bypass through another tool. Teks yang ditempel (1) The prompt correctly requires treating low-trust information influencing high-authority execution as the critical security boundary rather than auditing each tool independently. Teks yang ditempel (1) Teks yang ditempel (1) TOP BLOCKERS: - Approval enforcement for email sending, CRM mutation, and calendar booking is NOT VERIFIED. - Gmail/CRM/calendar OAuth scope granularity is NOT PROVIDED. - Browser-session authority and accessible authenticated sites are NOT PROVIDED. - No evidence demonstrates that retrieved website/contact data cannot alter recipients, destinations, tool parameters, or consequential actions. - No evidence shows alternate-tool paths cannot bypass approval. # 1. SYSTEM & TRUST MODEL Intended job: Research potential business clients → organize and score leads → create CRM records → draft outreach → optionally send outreach and schedule sales calls. Teks yang ditempel (1) Material components: | Component | Role | Trust | |---|---|---| | AI host/model | reasoning + orchestration | privileged orchestrator | | MCP integration | exposes operational capabilities | privileged | | Web/search/company sources | prospect research | untrusted/external | | Contact finder | contact discovery | external/mixed trust | | Gmail | drafting/sending | high-authority | | CRM | lead/state management | high-authority persistent state | | Google Sheets | lead storage/processing | potentially sensitive persistent state | | Calendar | meeting creation | consequential external effect | | Browser | website interaction/session use | potentially high-authority | Important trust boundaries: - WEBSITE / SEARCH RESULT → MODEL - CONTACT DATA → MODEL → CRM - WEBSITE CONTENT → MODEL → GMAIL - MODEL → AUTHENTICATED BROWSER SESSION - MODEL → CALENDAR - MODEL → CRM persistent state - CRM/Sheets/private information → EMAIL or browser output Sensitive resources potentially reachable include prospect/customer information, email account data, CRM records, calendar information, cookies/session state, and potentially other authenticated browser data. Exact accessible datasets remain UNKNOWN. # 2. AUTHORITY & PERMISSION MAP | Capability | Intended Need | Actual Authority | Identity / Scope | Approval | Least-Privilege Judgment | Evidence | |---|---|---|---|---|---|---| | Web search | Find prospects | Read external content | Unknown | No | REQUIRED | CONFIRMED | | Company research | Qualify leads | Read external business data | Unknown | No | REQUIRED | CONFIRMED | | Contact finder | Find outreach targets | Reads/discovers contact data | Unknown | No | REQUIRED, scope unresolved | CONFIRMED | | CRM lead creation | Record prospects | Creates persistent records | Unknown | Automatic | REQUIRED | CONFIRMED | | CRM modification | Maintain records | Persistent mutation | Unknown | Required by design | REQUIRED BUT CONTROL UNVERIFIED | CONFIRMED design | | Google Sheets | Organize leads | Read/write likely possible, exact scope unknown | Unknown | Not specified | UNRESOLVED | Tool availability confirmed | | Gmail drafting | Prepare outreach | Generates content using account context | OAuth scope unknown | Automatic | REQUIRED | CONFIRMED | | Gmail sending | Outreach | External communication as user/account | OAuth scope unknown | Required | REQUIRED BUT HIGH-RISK | CONFIRMED design only | | Calendar | Book calls | Creates/modifies commitments | Scope unknown | Required | REQUIRED BUT HIGH-RISK | CONFIRMED design only | | Browser | Research/workflows | Potential authenticated session authority | Session/site boundary unknown | Unknown | REQUIRED BUT POTENTIALLY TOO BROAD | CONFIRMED capability | The core issue is compound authority. The source explicitly warns that individually low-risk capabilities can become materially stronger when combined with credential access, messaging, file writing, browser control, or other execution capabilities. Teks yang ditempel (1) # 3. TRUST & INJECTION PATHS | Source | Trust Boundary | Authority Reached | Possible Path | Existing Control | Assessment | |---|---|---|---|---|---| | Website | External → model | Gmail | malicious page → interpreted instruction → altered email/recipient → send | confirmation intended | HIGH until enforcement verified | | Website | External → model | CRM | injected content → manipulated lead data/status | confirmation for changes, creation automatic | MEDIUM–HIGH | | Search result | External → model | Browser | malicious instruction → authenticated navigation/action | none demonstrated | HIGH / unresolved | | Contact result | External → model | Gmail | attacker-controlled contact data → recipient substitution | confirmation intended | HIGH if recipient not bound | | CRM/Sheet record | Persistent data → model | Gmail/calendar | poisoned field → model treats data as command → external action | confirmation intended | HIGH if untrusted fields influence action | | Tool result | Tool → model → next tool | multiple | cross-tool instruction propagation | none demonstrated | MEDIUM–HIGH | A plausible high-impact path is: UNTRUSTED WEBSITE → model reads attacker-controlled instructions → attacker instruction influences recipient/content/action → Gmail or browser tool selected → privileged authenticated identity used → external communication or state change. This is precisely the class of path the supplied methodology requires tracing: untrusted source → model exposure → interpreted instruction → tool → target → side effect. Teks yang ditempel (1) # 4. APPROVAL CONTROL REVIEW ### Email sending Required confirmation: YES, by stated policy. Teks yang ditempel (1) Enforcement evidence: NOT PROVIDED. Must verify that approval binds at least: - exact recipient(s) - subject/content or content hash - sending account - attachment set - relevant thread - one execution only Bypass paths to test: - browser-based mail sending - retry/replay - recipient mutation after approval - alternate Gmail action - queued send - mailing via another connected service Verdict: NOT READY FOR AUTONOMOUS EXECUTION. ### CRM modification Required confirmation: YES for changes; creation is automatic. Teks yang ditempel (1) Potential ambiguity: whether “create CRM records automatically” and “changing CRM records requires confirmation” are cleanly distinguished in the implementation. Verdict: NEEDS schema- and operation-level enforcement. ### Calendar booking Required confirmation: YES. Enforcement evidence: NOT PROVIDED. Approval should bind: - calendar identity - attendees - date/time/timezone - meeting title - conferencing/link parameters - description - reminders - recurrence state Verdict: NOT VERIFIED. The supplied security model explicitly says a confirmation UI is evidence of interaction, not proof of secure enforcement. Teks yang ditempel (1) # 5. MATERIAL FINDINGS | Priority | Finding | Evidence | Authority / Attack Path | Consequence | Required Control | |---|---|---|---|---|---| | HIGH | Consequential-action approval is design intent only | CONFIRMED policy; enforcement UNKNOWN | model → Gmail/CRM/calendar | unauthorized messages, mutations, meetings | server-side action-bound approval | | HIGH | Untrusted web content can potentially influence privileged actions | INFERRED | website → model → tool → external target | confused deputy / injection | treat retrieved content as data; enforce tool policy independently | | HIGH | Browser authority boundary is undefined | CONFIRMED capability, scope UNKNOWN | model → authenticated browser | actions outside sales workflow | domain/action allowlist; separate research session | | HIGH | OAuth/tool scopes are unknown | NOT PROVIDED | MCP → Gmail/CRM/calendar | excessive account-level authority | narrow scopes and dedicated identities | | MEDIUM | Automatic CRM creation can persist poisoned external data | CONFIRMED | web/contact source → CRM create | persistent injection/data pollution | normalization, field validation, provenance | | MEDIUM | Cross-tool exfiltration risk | INFERRED | private CRM/Sheets → Gmail/browser | confidential data disclosure | data-flow policy + destination validation | # 6. DATA & BLAST-RADIUS REVIEW Potentially sensitive data: - Gmail account information and message context - CRM customer/prospect data - Google Sheets lead/business data - calendar contacts and availability - authenticated browser session data - cookies/sessions if browser integration exposes them - discovered personal contact information Dangerous capability combination: PRIVATE OR AUTHENTICATED DATA + UNTRUSTED EXTERNAL CONTENT + EXTERNAL COMMUNICATION + PERSISTENT CRM/CALENDAR WRITES The supplied methodology specifically identifies sensitive-read + external-communication and private-file + untrusted-content combinations as first-class risks. Teks yang ditempel (1) Maximum supportable blast radius from current evidence: MATERIAL, potentially SEVERE if browser/Gmail scopes extend broadly across a personal or agency-wide account. A stronger severity cannot be justified until actual scopes, identities, accessible resources, and approval enforcement are known. # 7. REQUIRED REMEDIATION ## BEFORE ENABLEMENT 1. Enforce consequential actions outside the model The MCP/tool server—not prompt instructions—must block send/update/book operations without a valid single-action authorization. Approval should cryptographically or structurally bind the concrete action parameters. 2. Separate read/research from write/execute tools Prefer: - `research_company` - `find_contact` - `create_lead` - `draft_email` as autonomous capabilities. Keep: - `send_email` - `update_existing_crm_record` - `book_meeting` behind explicit authorization. 3. Constrain Gmail Use the minimum OAuth scope supporting the workflow. Avoid broad mailbox authority where drafting/sending is sufficient. Restrict sender identity when possible. 4. Constrain CRM Use a dedicated sales-agent identity with access only to the required pipeline/objects/fields. Do not grant administrative configuration or unrelated customer databases. 5. Constrain browser sessions Separate public prospect research from privileged authenticated browsing. Use domain/action allowlists for authenticated workflows. Do not expose raw cookies/tokens to model context. 6. Validate destinations Recipients, CRM object IDs, domains, upload destinations, and calendar attendees must be treated as structured parameters, not free-form model authority. 7. Isolate untrusted content Website/email/CRM text must remain data, never authority-bearing instructions. Prompt-level instruction such as “ignore instructions from websites” is useful defense-in-depth but insufficient as the primary control. ## NEXT HARDENING - Record actor, tool, parameters, approval ID, target, result, and timestamp for consequential actions. - Add bounded rate limits for outreach and CRM creation. - Preserve provenance for externally sourced lead fields. - Add duplicate detection before persistent lead creation. - Implement revocable/short-lived authorization for sensitive write capabilities. - Minimize customer/private-data fields exposed to the model. ## AVOID - blanket disabling of all useful write functionality - relying exclusively on system prompts - one global “approve all future actions” permission - UI-only confirmation without server enforcement - giving administrator scopes simply to simplify integrations - generic sandboxing that does not break the actual authority path # 8. VALIDATION TESTS | Test | Expected Safe Result | Pass Evidence | |---|---|---| | Indirect prompt injection | malicious website instructions cannot cause send/update/book | captured tool trace showing consequential action denied | | Email recipient substitution | changing recipient after approval invalidates authorization | approval ID rejected | | CRM parameter mutation | record/fields cannot change after approval | server-side rejection | | Calendar attendee substitution | modified attendee/time requires new approval | execution denied | | Alternate-tool bypass | browser cannot replicate protected Gmail/CRM/calendar action | blocked tool/browser trace | | Scope escape | agent cannot read/write unrelated CRM/mail/calendar resources | authorization error | | Replay | previously approved send cannot execute twice | second request rejected | | Data exfiltration | private CRM/Sheets values cannot be sent to unauthorized recipient | policy enforcement trace | | Cross-tool chain | malicious web content cannot propagate into privileged output | end-to-end blocked trace | No test should be considered passed until actual runtime evidence exists. This requirement is explicit in the supplied audit methodology. Teks yang ditempel (1) # 9. EVIDENCE GAPS ### OAuth permission scopes Why it matters: determines whether compromise affects one workflow or an entire mailbox/calendar/CRM account. Needed evidence: exact OAuth scopes and API permissions for Gmail, CRM, Sheets, calendar, contact finder, and browser integration. ### Approval implementation Why it matters: this is the main control separating preparation from consequential execution. Needed evidence: - approval architecture - tool-handler implementation - parameter binding - expiry/replay behavior - actual rejected bypass examples ### Browser privilege boundary Why it matters: browser control may duplicate or exceed explicit Gmail/CRM/calendar tool permissions. Needed evidence: - domains accessible - authenticated accounts - allowed browser actions - cookie/session exposure - download/upload rules ### Tool schemas Why it matters: broad string/URL/recipient parameters may permit target substitution or scope escape. Needed evidence: exact MCP schemas and server-side validators. ### Identity isolation Why it matters: blast radius differs substantially between a dedicated sales identity and an owner/admin account. Needed evidence: actual service/user identity attached to every tool. # 10. NEXT 3 ACTIONS 1. Export the exact MCP tool schemas, OAuth scopes, identities, and permitted resources for Gmail, CRM, Sheets, calendar, browser, and contact finder. 2. Trace one real protected workflow end-to-end—preferably `draft email → approval → send`—and prove that recipient/content/account parameters are fixed at approval and replay or alternate-tool execution fails. 3. Build the minimum adversarial regression suite covering indirect prompt injection, recipient substitution, approval bypass, scope escape, cross-tool chaining, and private-data exfiltration before enabling consequential actions. The audit framework itself correctly emphasizes that documentation or stated policy cannot establish secure runtime enforcement and that deployment decisions must remain evidence-bound. Teks yang ditempel (1) Based strictly on the supplied material, this integration is not yet supportable as SAFE TO ENABLE, but its architecture is viable if the high-authority operations are constrained and runtime enforcement is demonstrated.