Salesforce is a high-impact system for agents because a single “helpful” action can create, update, or expose leads, contacts, cases, and notes at scale. Claw EA runs OpenClaw as the baseline agent runtime, then adds a permissioned execution layer so Salesforce actions are governed by policy-as-code, not prompt-only instructions.
This page describes how to connect Salesforce via official API with enterprise buildout controls, while requiring Work Policy Contracts (WPC), CST (scoped token), and auditable model traffic through clawproxy.
Step-by-step runbook
-
Define the Salesforce “agent job” boundary. Be explicit about which objects and fields the agent may touch, and which actions are read-only vs write.
Separate “triage” (search, summarize, propose changes) from “commit” (create/update/delete) so you can gate the commit path.
-
Write a WPC that encodes allowed Salesforce operations and approval requirements. Store the WPC in the WPC registry so it is signed and hash-addressed (served by clawcontrols).
Keep the WPC narrow: object types, field sets, and max row counts per run are more effective than broad “CRM access” rules.
-
Issue a CST (from clawscope) for the specific job. Use CST scope hash and, when appropriate, policy hash pinning so the agent cannot swap to a different policy mid-run.
Bind the CST to the job to reduce replay risk. This aligns with marketplace anti-replay binding (job-scoped CST binding) when you later store artifacts.
-
Connect Salesforce via official API in an enterprise buildout. Use explicit least-privilege auth scopes and avoid reusing a human admin identity for agent workloads.
Route model calls through clawproxy so every model call emits gateway receipts for verification. (Salesforce API calls can be logged separately; do not assume they are natively receipted.)
-
Run the agent in OpenClaw with sandboxing enabled for tool execution where feasible. Use OpenClaw tool policy to allow only the minimal set of tools required for the job and deny everything else.
Use OpenClaw’s security audit regularly to catch configuration footguns (exposed gateway auth, broad tool allowlists, unsafe filesystem permissions).
-
For write and admin actions, require WPC approval gates. Operationally, this means the agent can prepare a proposed change set, but execution requires an explicit approval step that the policy recognizes.
Keep approvals machine-checkable: include the object, record ids, field diffs, and a reason string, then require a second party or an allowlisted role to approve.
-
Collect proof artifacts. For each run, Claw EA produces a proof bundle that includes gateway receipts and job metadata, then you can store/view it as a Trust Pulse artifact for audit.
Verify before you trust: use receipt verification to confirm the model traffic that drove recommendations, and keep the proof bundle alongside your Salesforce change logs.
Threat model
Salesforce risk is not theoretical: it is a shared operational datastore that controls pipeline, customer communications, and service workflows. An agent that can write to Salesforce can cause durable business impact quickly, especially when combined with broad object permissions.
| Threat | What happens | Control |
|---|---|---|
| Prompt injection leads to unauthorized updates | The agent is tricked into changing Opportunity stages, closing cases, or overwriting notes based on untrusted text (email, case comments, knowledge articles). | WPC restricts write actions and requires approval gates for “commit” operations. OpenClaw tool policy denies any direct “raw HTTP” or shell tooling not required for the integration path. |
| Overbroad OAuth/app permissions | A single token can read or modify objects outside the intended business unit, including sensitive fields. | Use explicit least-privilege auth scopes and separate service principals per job type. Bind the run to a CST whose scope hash matches the intended permission set. |
| Silent exfiltration via model context | Agent copies PII or deal data into model prompts, then logs or downstream systems retain it. | Route model calls through clawproxy and retain gateway receipts so you can audit what was sent to the model. Keep the WPC strict about which fields may be placed into prompts. |
| Record fan-out and bulk damage | A bad filter or loop causes thousands of updates, creating irreparable CRM noise or compliance issues. | WPC enforces max row counts and requires a two-phase pattern: query and propose, then approve and apply. Prefer idempotent updates and dry-run summaries before write. |
| Misconfigured agent runtime expands blast radius | Agent can reach extra tools (filesystem, network, browser control) and pivot beyond Salesforce. | OpenClaw sandboxing reduces tool execution blast radius, while OpenClaw tool policy and elevated gates keep host escape hatches off by default. Run OpenClaw security audit after changes. |
Policy-as-code example
This JSON-like snippet illustrates the shape of a WPC used to gate Salesforce actions connected via official API. It is intentionally narrow: read is allowed for a small set of objects; writes require approval, and admin actions are denied.
{
"wpc_version": "v1",
"policy_name": "salesforce-permissioned-agent",
"tools": {
"salesforce_api": {
"mode": "official_api",
"allow": [
{ "action": "query", "objects": ["Account", "Contact", "Case"], "max_rows": 200 },
{ "action": "get", "objects": ["Account", "Contact", "Case"] }
],
"write_requires_approval": [
{ "action": "create", "objects": ["Case"] },
{ "action": "update", "objects": ["Case"], "fields_allowlist": ["Status", "Priority", "Description"] }
],
"deny": [
{ "action": "delete", "objects": ["*"] },
{ "action": "admin", "objects": ["*"] }
]
}
},
"model_calls": {
"must_route_via": "clawproxy",
"retain_gateway_receipts": true
},
"token_requirements": {
"require_cst": true,
"require_cst_scope_hash": true,
"optional_policy_hash_pinning": true
}
}
Prompt-only controls can describe these rules, but they cannot enforce them. Policy-as-code is what makes the agent fail closed when it tries a disallowed Salesforce operation, even if the model is confused or manipulated.
What proof do you get?
For each run, Claw EA can produce gateway receipts for model calls emitted by clawproxy. These receipts let you verify which model endpoints were called, when, and under what job context, without trusting application logs alone.
Claw EA packages those receipts plus related metadata into a proof bundle. You can store and view the resulting artifact as a Trust Pulse for audit, and use marketplace anti-replay binding (job-scoped CST binding) to make replayed tokens easier to detect in review.
Operationally, this means you can answer: “Which model calls influenced this Salesforce update proposal?” and “Was the run executed under the exact WPC we approved?” without relying on developer assertions.
Rollback posture
Salesforce changes are often reversible, but only if you plan for it. Treat rollback as a first-class job requirement: write paths must be idempotent, diffable, and tied to a run identifier stored outside the model context.
| Action | Safe rollback | Evidence |
|---|---|---|
| Create Case | Close the created case and mark it as agent-created, or delete only if your retention policy allows. Keep a run-id field or external mapping for traceability. | Proof bundle for the run, plus Salesforce record id list produced at commit time. |
| Update Case fields | Store a before/after field diff and revert to previous values using the diff. Require approval for bulk reverts, same as bulk writes. | Gateway receipts for model calls that generated the diff, and an approval record tied to the WPC hash. |
| Bulk update many records | Rollback via a bounded “undo batch” that is limited to the exact record ids and fields touched by the run. Never run an unfiltered rollback query. | Commit-time manifest (record ids, fields, timestamps) plus CST job binding in the run metadata. |
| Permission change / admin action attempt | No rollback needed if denied by policy. If allowed by exception, treat as an emergency change with manual verification steps. | WPC denial/exception trace and the absence of an executed commit step for the agent job. |
FAQ
Is this a native Salesforce connector in Claw EA?
No. Salesforce can be connected via official API with enterprise buildout controls, and you should assume implementation work for your org’s auth model, objects, and field rules.
Why isn’t prompt-only governance enough for Salesforce agents?
Prompts can be ignored or subverted, especially when an agent consumes untrusted text from cases, emails, or web pages. A WPC makes the execution layer enforce allowed actions and approval gates even when the model output is wrong.
How do you ensure writes and admin actions are constrained?
Write and admin actions require WPC approval gates, CST, and explicit least-privilege auth scopes. In practice, the agent prepares a change set, then a policy-controlled approval step is required before any Salesforce mutation is allowed.
What do gateway receipts cover in a Salesforce workflow?
Gateway receipts cover model calls routed through clawproxy. They do not automatically attest Salesforce API calls, so pair receipts with your Salesforce-side logs and the agent’s commit manifest for a complete audit trail.
Can I run Salesforce-capable agents in a sandboxed environment?
Yes for tool execution in OpenClaw: sandboxing reduces local filesystem and process blast radius. It does not replace Salesforce permission scoping, so keep both controls in place.