Quick answer: Salesforce API access control for AI agents means giving each agent its own connected app with OAuth scopes limited to what that agent actually does, a dedicated integration user, and a permission set that grants read/write only on the objects it touches. The goal is that a compromised or misbehaving agent can be cut off instantly — without rotating credentials or disrupting every other system that connects to your Salesforce org.
Start with what each agent actually does
Before configuring anything in Salesforce, write down what each agent needs. Not what it might need someday — what it does right now.
A lead qualification agent might need:
- Read access to Lead and Contact objects
- Read access to Account (to check existing relationships)
- No write access to anything
A deal-desk agent that updates opportunity stages needs:
- Read/write on Opportunity
- Read on PricebookEntry and Product2
- No access to Account, Contact, or Lead objects it never touches
A reporting agent pulling pipeline numbers needs:
- Read-only across Opportunity, Account, and custom forecast objects
- Zero write permissions anywhere
This inventory matters because Salesforce's permission model is additive. Every permission you grant stacks. If you start broad and try to narrow later, you're fighting the system's design. The same principle applies across every service your agents touch — see least privilege for AI agents for the broader pattern.
One connected app per agent role
Salesforce connected apps are the mechanism for granting API access to external systems. Each connected app gets its own client ID, client secret, and OAuth flow. Most teams create one connected app for "the integration" and share it across everything.
For AI agents, create a separate connected app for each distinct role. A lead qualification agent and a deal-desk agent should authenticate through different connected apps. This gives you independent OAuth scopes, separate refresh tokens, and the ability to revoke one agent's access without disrupting the other.
When creating the connected app, set the OAuth scopes to the minimum the agent needs. Salesforce offers scopes like api (full API access), but also narrower ones: chatter_api for Chatter-only access, custom_permissions to enforce custom permission sets, and cdp_query_api for data cloud queries. Use the narrowest scope that covers the agent's job.
Permission sets over profiles
Salesforce profiles are blunt instruments. They grant object-level access across the board. Permission sets are additive layers you can stack precisely.
Create a permission set for each agent role:
- Start with zero object permissions
- Add read access only to the specific objects the agent queries
- Add create/edit access only where the agent writes
- Set field-level security to hide sensitive fields (SSN, revenue figures, internal notes) the agent has no reason to see
Assign the permission set to the integration user associated with that agent's connected app. The integration user should have a minimal base profile — Salesforce offers a "Minimum Access" profile for exactly this purpose — with the permission set layered on top. This maps directly to the granular permissions model that keeps agent access auditable and revocable.
Field-level security is where the real scoping happens
Object-level access is necessary but insufficient. An agent with read access to the Contact object can see every field on every contact: phone numbers, email addresses, notes from account executives, internal tags.
Field-level security lets you restrict which fields the agent can read or write. For a lead qualification agent, you might expose:
Lead.Status,Lead.LeadSource,Lead.Company,Lead.Industry- Hide:
Lead.AnnualRevenue,Lead.Description,Lead.Rating
This reduces the blast radius if the agent's credentials are compromised. It also keeps the agent's context window cleaner, which means better performance from the model.
Declare credential requirements before you deploy
One pattern that reduces credential sprawl: write down what each agent needs as part of its design spec, before any Salesforce admin work begins — not what it might need, what it does right now. This means separating the agent definition from the credential values. Envelope's guide to tool credentials and permissions is a useful reference for structuring this: declare what each agent requires by name without embedding actual keys, so when you reach the Salesforce admin console you already know exactly which objects and operations each connected app needs to support.
This design-first approach prevents the most common failure mode: an agent gets broad access "to unblock development" and nobody narrows it later.
Audit logging closes the loop
Scoped access is only useful if you can verify it's working. Salesforce provides event monitoring through its EventLogFile and Real-Time Event Monitoring features (available on Shield or Enterprise editions). These logs capture which user accessed which object, what operation they performed, and when.
For AI agents specifically, each integration user's API calls show up in these logs. Because you've created separate connected apps and integration users per agent role, you can filter the event logs by user to see exactly what each agent did. If the lead qualification agent suddenly starts querying Opportunity records, that shows up immediately.
Pairing per-agent integration users in Salesforce with a credential broker that logs every token request gives you two layers of audit data: Salesforce's own event monitoring (what happened inside the org) and the broker's logs (which agent requested which credential, and whether the request was approved or denied). For a deeper look at what a complete agent credential audit trail looks like, see AI agent credential management.
Scaling the pattern across services
The per-agent connected app pattern you've built in Salesforce is the right foundation. The challenge is that it doesn't generalise across services automatically. Your agents need the same treatment in GitHub, Stripe, Vercel, and every other API they touch — and each service has its own version of connected apps, permission sets, and audit logs.
Gazebo provides a credential brokering layer that sits in front of all of those services. You connect Salesforce once, define what each agent is allowed to do, and Gazebo enforces per-agent access profiles on every credential request — with a unified audit trail across all services, not just Salesforce. The per-agent scoping you've configured in Salesforce maps directly into Gazebo's access policy model, so you're not starting from scratch for each new service.
The minimum viable setup
For teams just starting to scope Salesforce access for AI agents, the practical first step is small:
- Create one connected app per agent role (not one for "the AI integration")
- Create a Minimum Access integration user per connected app
- Build one permission set per agent role with only the objects and fields that agent touches
- Turn on Salesforce event monitoring for the integration users
- Review the logs weekly for the first month to catch permission gaps or unexpected access patterns
This takes an afternoon of Salesforce admin work. The payoff is that when you add your fifth or tenth agent, the pattern is already established — and each new agent gets scoped access from day one instead of inheriting broad permissions from a shared key.
Managing Salesforce OAuth refresh tokens for AI agents
Salesforce's OAuth flow issues refresh tokens used to get new access tokens when the current one expires. For AI agents, refresh token management has a complication that doesn't exist for traditional services: agents may run as multiple concurrent instances.
If two n8n workflow executions start simultaneously and both try to use the same refresh token to obtain an access token, one succeeds and one fails — Salesforce enables refresh token rotation by default on many connected app configurations, which invalidates the previous token on each use. The second request arrives with an already-rotated token and gets an authentication error that can be difficult to diagnose. Verify your connected app's token rotation settings, as behavior varies by configuration.
The fix is consistent with the broader per-agent credential model: a credential broker holds the refresh token and handles token lifecycle centrally. Agents request access tokens from the broker; the broker handles refresh atomically. Concurrent agent executions don't compete for the same refresh token — they each get a fresh access token from the broker, which manages the rotation.
Testing your Salesforce agent setup before go-live
Before using production Salesforce data, verify each element of the setup explicitly:
Test the negative case. Log in as the integration user and attempt to access an object the agent shouldn't reach. Confirm it's blocked. Testing what the agent can't do is as important as testing what it can.
Check field-level security in API responses. Pull a record via the integration user's credentials and confirm restricted fields aren't accessible. In some Salesforce API configurations, restricted fields may be returned as null rather than omitted — verify both that restricted fields are not writable and that the response behavior matches your security expectations. Test against your specific object and field permission setup.
Verify event monitoring is capturing agent activity. Make a test API call via the integration user and confirm it appears in Salesforce's EventLogFile or Real-Time Event Monitoring. Availability and timing windows vary by Salesforce edition and monitoring configuration — check your org's settings and Salesforce's current documentation to confirm what's available on your plan. If monitoring isn't capturing calls, the logging setup needs attention before production.
Let the workflow run in staging for two weeks before widening access. Permission gaps — operations the agent legitimately needs but the permission set doesn't cover — show up as failures. Two weeks of staging usage surfaces most of them. Resist granting broad access "for now" while you figure out the exact scope; in practice, "for now" rarely gets narrowed.
This is an independent editorial post — not affiliated with or endorsed by Salesforce. Last reviewed: August 2026. Salesforce's OAuth behavior, field-level security, and event monitoring capabilities vary by edition and configuration — check Salesforce's current documentation for your specific org setup.