AIDEFEND in Action AIA-0046 Validated Research Published: Jul 7, 2026

Prompt Mines Show Why CRM Agents Need Write-Action Gates

Zenity's Prompt Mines research shows how attacker-created Salesforce (a CRM platform) cases can sit quietly in Einstein (Salesforce's AI assistant layer for CRM workflows) context until a normal follow-up question activates them. The key control is not only prompt filtering; CRM write actions such as UpdateCustomerContact need request-scoped authority, independent validation, and recovery-ready data integrity controls.

Indirect Prompt InjectionDestructive ActionTool AuthorizationSaaS SecurityAgentic AI
9 applicable AIDEFEND defenses
Source: Prompt Mines: 0-Click Data Corruption In Salesforce Einstein 
Author: Tamir Ishay Sharbat
Original article: Aug 14, 2025

Threat Analysis

  • The attacker writes into a legitimate CRM intake path. Email-to-Case or Web-to-Case lets external users create support cases that may later be retrieved by Einstein.
  • The payload is delayed. The malicious text is split across several cases to work around field limits, then waits until a user asks a common follow-up question.
  • The injection may be invisible to the employee. Zenity notes that Einstein can include a malicious record in context even when the UI only renders the first few cases.
  • The harmful step is a write action. The prompt mine instructs Einstein to query contact IDs and repeatedly invoke UpdateCustomerContact, corrupting customer contact records.
  • Recovery matters because the data is changed. Defenders need to know which records were touched, restore trusted values, and close the action-authorization gap before re-enabling write autonomy.

Applicable AIDEFEND Defenses (9)

AID-H-018.004
Intent-Based Dynamic Capability Scoping
Very High
A user asking what a case is about should not grant contact-update capability. The dispatcher should derive a signed scope from the trusted user request and deny CRM write tools unless the user explicitly asks for and approves them.
AID-H-018.003
High-Impact Independent Validation & Approval Gate
Very High
Bulk contact updates are high-impact CRM mutations. A separate validator should verify the plan, record count, purpose, and approval evidence before UpdateCustomerContact runs.
AID-I-003.004
High-Risk Agent Action Containment
Very High
Place a fail-closed containment decision immediately before the CRM tool dispatcher commits each UpdateCustomerContact call. Consume the session intent-drift finding, trusted user request, action risk, target set, and authorization result; if the write is inconsistent with the read-only question or the containment service is unavailable, block it, force a safer read-only re-plan, defer it, or require fresh human approval before any contact record changes.
AID-H-018.002
Policy-Based Access Control
High
A policy engine can deny write actions whose justification comes from retrieved customer case text rather than an authorized user, workflow, or admin-approved rule.
AID-H-017.003
Decoupled Plan-Then-Execute Architecture
High
Plan validation catches the mismatch between a read-only follow-up question and a proposed plan that mutates many CRM records.
AID-R-002
Data Integrity Recovery for AI Systems
High
After freezing agent writes, identify the complete affected CRM record population and recover only authoritative pre-attack values. If no clean backup exists, deterministic repair produces a new isolated immutable candidate and a complete decision ledger; it does not overwrite the serving CRM in place. Independently validate the candidate before a separately authorized cutover. Closing the write-authorization gap is a separate prerequisite. The research does not establish available backups or a turnkey Salesforce adapter.
AID-R-007
External Side-Effect Reconciliation & Compensation
High
The corruption came from the agent repeatedly issuing UpdateCustomerContact tool calls, so recovery cannot stop at restoring the contact table from a snapshot. External side-effect reconciliation reconciles the incident-scoped set of agent-issued CRM writes against authoritative record state and idempotently reverses, compensates, or explicitly dispositions each unintended change.
AID-H-017.007
Dual-LLM Isolation Pattern
Medium
A quarantined parser can read raw case records and pass only typed, bounded summaries to the privileged agent. The component that can call CRM tools should not see raw public case text as instructions. Use separately deployed Q, broker and P identities with verified process, credential and network separation. Broker-validated strings remain untrusted; a schema is not semantic safety. Final actions and renderer sinks require independent authorization. Provider support is required where the runtime is managed.
AID-D-003.005
Stateful Session Monitoring: Intent Drift + Invariant-Breach Signals
Medium
Prompt mines are delayed and cross-turn. A session ledger can connect the retrieval of suspicious case text with a later shift into CRM mutation.

What Defenders Should Do Now

  • Inventory every Einstein or Agentforce action that can write, update, delete, export, or send CRM data.
  • Bind each action to an authority envelope. Reading cases and explaining a case should be separate from modifying contacts.
  • Require independent validation and step-up approval for bulk updates or repeated writes, even when the model says the action follows company policy.
  • Scan case fields that enter AI context for prompt-mine patterns, cross-record delimiters, hidden policy language, and delayed trigger wording.
  • Keep CRM restore evidence ready: record-level change history, trusted snapshots, and a tested script for rolling back corrupted fields.

Conclusion

Prompt Mines are a good reminder that agent defenses have to sit at the point of action. The payload can be subtle, delayed, and hidden from the user, but the dangerous operation is concrete: a CRM write tool is about to change records. That is where scope, policy, validation, monitoring, and recovery need to converge.

Last updated: