---
title: "Salesforce"
description: "Scoped Salesforce API credentials for AI agents"
url: "https://gazebohq.com/services/salesforce"
---

Salesforce agents may query leads, update opportunities, create cases, or trigger CRM automation, so the integration identity needs the same design discipline as any production user. Use a dedicated integration user with a Minimum Access base profile and only the object, field, record, connected-app, and API permissions the workflow needs. Validate sharing rules, field-level security, permission sets, OAuth scopes, IP/session requirements, and API limits before permitting an autonomous workflow. Gazebo then controls which named agent may retrieve the prepared credential and produces a separate record of that request.

## Why should AI agents use scoped Salesforce credentials?

Salesforce permission sets, field-level security, sharing, connected-app configuration, and OAuth scopes define what a credential can do after delivery. A Gazebo profile cannot reduce a broad integration user’s object access after the credential is fetched, so least privilege must begin in Salesforce. Gazebo adds per-agent retrieval control, including denials and rapid removal of future access, while Salesforce event monitoring, login history, and object history remain necessary to establish API calls and record changes. If a token may have been copied, revoke the OAuth session or connected-app credential and review Salesforce activity; disabling only the Gazebo profile is not retroactive.

## How it works

1. Create a dedicated Salesforce integration user with Minimum Access and add only the permission sets, object/field rights, record sharing, and connected-app OAuth scopes required by the workflow.
2. Store separate credentials for reporting, lead updates, and production automation when their permissions differ; map each one to a named Gazebo profile.
3. The agent calls get_credential through MCP. Gazebo checks the profile before returning the selected credential, rather than placing a connected-app secret in a prompt or shared configuration.
4. Review Gazebo access events with Salesforce login history, Event Monitoring where available, API usage, and field/object history. Also account for validation rules, flows, duplicate rules, and API limits that can cause an authenticated automation to fail.
5. Remove the profile to halt future retrieval. For suspected disclosure, revoke the OAuth refresh token or session and rotate the connected-app secret as appropriate, then review changes made during the exposure window.

## Use cases

**Per-agent access without per-agent connected apps:** A dedicated integration user and connected app can serve multiple agent profiles when their Salesforce permissions are genuinely appropriate, while Gazebo controls normal retrieval by agent. This is not identical to separate Salesforce identities: the integration user’s permissions remain the shared upper bound. Use separate connected apps or users for materially different risk domains.

**CRM automation with a full audit trail:** Gazebo’s log shows which agent requested the credential and whether policy allowed it. Salesforce telemetry and record history show the subsequent query, update, login, or automation effect. Combining those sources helps distinguish credential access from an API call and diagnose failures caused by validation rules, flows, sharing, or exhausted API limits.

**Instant revocation when an agent misbehaves:** Disable the agent profile to prevent future retrieval while other authorized profiles continue. If the underlying OAuth credential could have been retained by the agent runtime, revoke its Salesforce session or refresh token and reissue the integration secret; profile removal alone cannot invalidate a copied value. Review object history and API events before restoring access.