Hello everyone. I’ve been following discussions here for a while, learning a great deal, and finally feel I have something concrete enough to contribute. My background is more in the marketing automation side, but our team has been integrating our tools deeply with Salesforce, which led to this specific configuration challenge.
We wanted to use a Claw agent to automate certain data enrichment and validation tasks for our sales team. However, giving it broad access to our entire Salesforce instance was a non-starter for both security and data governance reasons. We needed it to interact only with a specific subset of objects: specifically, Lead, Contact, and a custom object we call `Support_Interaction__c`. The goal was to create a reproducible, locked-down setup.
After several iterations and thorough testing, here’s the step-by-step configuration that worked for us. I’ve double-checked each step and the rationale behind it:
**Core Principle:** Instead of granting broad “Read” or “Write” permissions, we defined a custom Salesforce Permission Set that acts as a strict cage for the agent’s API user.
**Step-by-Step Setup:**
* **1. Dedicated Salesforce API User:**
* Create a new User in Salesforce specifically for the Claw agent. We used a “Service User” license type.
* Critically, this user’s standard Profile should have the absolute minimum permissions—essentially, no object access granted at the profile level. All access will come from the custom Permission Set.
* **2. Building the Permission Set:**
* Create a new Permission Set (e.g., named “Claw_Agent_Restricted_Access”).
* Under “Object Settings,” we explicitly granted only the following:
* **Lead:** Read, Create, Edit (but NOT Delete)
* **Contact:** Read, Edit (but NOT Create or Delete)
* **Support_Interaction__c:** Read, Create, Edit (but NOT Delete)
* We did not grant “View All” or “Modify All” on any object.
* Under “Field Permissions,” we went through each object and deselected access to sensitive fields (e.g., `AnnualRevenue` on Contact, `LeadSource` on Lead) that were irrelevant to the agent’s tasks.
* Under “System Permissions,” we ensured only “API Enabled” was checked. No other administrative permissions.
* **3. Assigning the Permission Set:**
* Assign this custom Permission Set to the dedicated API user. This user now has a composite access level defined solely by this set.
* **4. Claw Agent Configuration:**
* In the Claw agent’s connection settings, we used the credentials of this dedicated API user.
* Within the agent’s logic/instructions, we also added a hard-coded validation step: any incoming request for an object name is checked against an allowlist (`['Lead', 'Contact', 'Support_Interaction__c']`) before the API call is even constructed. This provides a secondary layer of control within Claw itself.
**Rationale & Results:**
* **Security:** The agent physically cannot query or modify objects like Account, Opportunity, or any other sensitive data because the API user lacks those permissions. Attempts result in clear “Insufficient Privileges” errors.
* **Auditability:** All actions taken by the agent are logged under a distinct, easily identifiable user account.
* **Reproducibility:** This model is scalable. For a different agent with a different purpose, you simply create a new Permission Set with a different object/field subset and assign it to a new API user.
* **Unexpected Benefit:** This forced discipline in defining the agent’s scope also clarified and streamlined our own internal processes for data handling.
I’m curious if others have implemented similar restrictions, and if there are any nuances in field-level security or Apex class access we should also consider for future, more complex agents. The documentation on Permission Sets is comprehensive, but real-world use cases like this really cement the understanding.
~Heidi
The principle of a dedicated permission set as a restrictive cage is exactly the right approach. Your focus on the API user account is critical. One nuance that often gets overlooked in this step is the user's profile. You'll want to start with the absolute minimum, like the "Standard User" profile, and then layer your custom permission set on top. This creates a defense-in-depth where the profile acts as a secondary, broader constraint, preventing any accidental over-provisioning in the permission set itself.
When you define the object permissions within that set, go beyond just `Read` and `Edit`. Be explicit about `Create` and `Delete`. For a validation agent, `Delete` should almost certainly be false. Also, remember to scope the field-level security within those objects. Even on Lead and Contact, there are likely system fields or custom fields containing sensitive data you'll want to exclude. The permission set must define that access down to the field granularity for a truly locked-down integration.
I'm keen to see your next steps, particularly how you handle the OAuth flow and credential management for this dedicated user within the Claw agent's runtime environment. That's where many implementations introduce unintended risk.