Two-Phase Dry-Run Mutation Safeguards for Grok Bots
This article was produced with AI assistance. Editorial standards apply.
AI Edited 
Last updated: 26 August 2026
Key takeaways
- Two-phase dry-run mutation safeguards default every write tool to simulation, then require a short-lived execution token to commit.
- Salesforce Composite can batch REST subrequests and roll back with
allOrNone— that is not a substitute for an agent-side preview. - Prompt injection is a separate control plane; pair this pattern with Grok bot security and prompt injection.
- xAI function calling still executes on your side — the gate lives in the worker, not the system prompt.
Two-phase dry-run mutation safeguards exist because giving an autonomous agent unmediated write access to Salesforce is an architectural error, not a prompt-tuning problem.
When an LLM hallucination occurs on a read-only query, the consequence is mild inconvenience. When an LLM hallucination occurs on an account-tiering routine with write access, it can silently downgrade Tier 1 enterprise accounts, trigger thousands of erroneous billing invoices, or wipe historical contact records.
The danger of direct mutation calls {#direct-mutation-danger}
Consider an automated account-tiering agent running against Salesforce. If a customer record contains anomalous data (e.g. a test company with $0 ARR and 50,000 users), an unconstrained agent might classify the account as “Stale - Delete” and issue an immediate DELETE API call.
[Agent Execution] ---> Direct API Write ---> [Salesforce Database Corrupted]To eliminate this catastrophe, production routines require a two-phase dry-run mutation guard.
The two-phase architectural protocol {#two-phase-protocol}
+---------------------------------------------------------------+
| PHASE 1: Simulation Mode (Mandatory Dry-Run Default) |
| * Computes analytical scoring & delta change payload |
| * Returns structured JSON preview with risk severity metrics |
| * ZERO network write calls executed |
+---------------------------------------------------------------+
|
[Authorization Gate]
|
+---------------------------------------------------------------+
| PHASE 2: Authorized Execution (Requires Explicit Token) |
| * Validates cryptographic auth signature & timestamp |
| * Executes verified batch mutation API calls |
| * Emits immutable audit log record to SIEM / DataDog |
+---------------------------------------------------------------+Phase 1: Simulation mode (dry_run: true)
By default, all write parameters default to dry_run: true. In this phase, the agent executes full analytical reasoning, scores account metrics, and formats the exact proposed change into a typed preview schema:
{
"status": "SIMULATION_COMPLETE",
"dry_run": true,
"proposed_mutations": [
{
"record_id": "0015g00000XyZ9A",
"target_field": "Tier__c",
"current_value": "Tier_2",
"new_value": "Tier_1",
"confidence_score": 0.98,
"risk_level": "LOW",
"rationale": "ARR grew from 45k to 180k; seat count expanded to 450."
}
],
"requires_human_approval": false,
"execution_token": "tok_sim_89f2a9c178b0e"
}Phase 2: Authorized execution (dry_run: false)
The execution API only accepts payloads that include a valid execution_token issued within the last 300 seconds. If an unauthorized script attempts to bypass Phase 1, the gate rejects the request with HTTP 403.
xAI function calling is the right split: Grok proposes preview_tier_change; your worker returns JSON; only then may commit_tier_change run.
Browse executive-ops routines →
Operational safeguard rules {#operational-rules}
- Explicit Confirmation Flags: The tool schema must never allow implicit writes.
dry_runmust be an explicit boolean parameter. - Threshold Caps: Any batch mutation exceeding 25 records or $10,000 in ARR impact must trigger a mandatory Slack webhook approval button.
- Immutable SIEM Audit Trails: Every Phase 1 simulation and Phase 2 mutation is logged to BigQuery/DataDog with model seed, temperature, and operator ID.
By implementing this two-phase guardrail across all skills in the BotSkillsStack registry, enterprise organizations can safely automate mission-critical operations without risk of accidental data loss.
Salesforce Composite vs an agent dry-run {#salesforce-composite}
Salesforce Composite executes a series of REST subrequests in one POST and can share reference IDs across them. That batches real writes; it does not simulate an LLM’s intent. Use Composite in Phase 2 after the preview is approved — not as Phase 1.
Deal-desk quote commits that use this gate are described in B2B deal desk automation with AI agents.
Pair with prompt-injection controls {#security-sibling}
Dry-run stops accidental writes. It does not stop a model from wanting a write because a ticket contained “ignore previous instructions.” That is Grok bot security and prompt injection: untrusted envelopes, least-privilege tools, OWASP LLM01. Both articles should stay linked; neither replaces the other.
Registry examples: account tiering agent and the deal desk accelerator.
FAQ {#faq}
Does Salesforce have a native dry-run for agent writes?
Composite and Bulk APIs execute. Sandboxes and allOrNone help testing and rollback. The agent-side preview is still required.
Why a 300-second execution token?
So a leaked preview payload cannot be replayed hours later. Rotate and bind the token to the exact mutation hash.
Is a system prompt “never delete accounts” enough?
No. Put the prohibition in the tool schema and the worker. See the security sibling for prompt injection.
Related reading
- Grok bot security and prompt injection
- B2B deal desk automation with AI agents
- Sales hub
- Executive-ops hub