AI Agent Security in Salesforce: The Vendor Questionnaire

Buying an AI agent that operates inside Salesforce is not like buying a reporting tool. A reporting tool reads. An agent writes, and it decides what to write on its own. Most vendor evaluations have not caught up to that difference.

The typical evaluation asks about encryption at rest, SSO, and whether the vendor holds a SOC 2 report. Table stakes, and the wrong place to lead. Those questions describe how a vendor runs their own infrastructure. They say nothing about what the agent can do inside your org on a Tuesday afternoon when nobody is watching.

This piece covers the five dimensions that do decide that, and ends with a question list you can lift straight into an RFP. It applies whether you are evaluating Agentforce, Clientell, or anything else that holds a Salesforce session and takes actions.

Why the usual security review misses

Security reviews assume software is a passive recipient of data. You grant it access, it reads, it renders something. The risk surface is exfiltration.

An agent inverts that. The risk surface is action. It is not just seeing your Opportunity records, it is updating them, and the decision about which ones was made by a model rather than by a person you can go and ask. So the controls that matter are the ones that scope, gate, and record actions.

None of this argues that agents should not act. These controls exist to let an agent take on high-volume, low-judgment work while the admin keeps the decision rights. Good controls widen what a team can safely say yes to.

1. Agent identity: who is taking the action

Every action in Salesforce has an actor, and the actor determines what is permitted and what shows up in SetupAuditTrail, field history, and LoginHistory. So the first question is simply: which user is the agent?

Three common answers, not equally good.

A dedicated Salesforce user per agent. Its own user record, its own permission set assignments, its own login history. Filter field history by that user and you get exactly the agent's writes and nothing else. If you need to stop it, you deactivate one user. This is what you want.

One dedicated user shared across all of a vendor's agents. Workable, but you cannot attribute an action to a specific agent when the vendor runs several. Academic if you run one. Not academic once you run a data hygiene agent and a permissions agent side by side.

A shared integration user. The red flag worth naming plainly. Plenty of orgs have an integration user that a middleware platform, a marketing tool, and two legacy scripts all authenticate as. Dropping an AI agent onto that login makes agent writes and integration writes indistinguishable in the audit trail, and the agent inherits whatever that user accumulated over the years, which is usually far more than it needs. Our permissions audit guide covers why integration users drift toward admin access: scoping was harder than not scoping, and nobody came back to fix it.

The follow-up matters as much as the first question. Can you tell, from inside Salesforce alone, that a record change came from the agent? If the answer depends on the vendor's dashboard, your audit trail has a third-party dependency. Ask whether agent writes carry a marker inside the org: a dedicated user, a custom field, or a log object.

2. Least privilege: granted access versus exercised access

Every agent vendor will tell you they follow least privilege. The useful move is to make them prove it with numbers.

Two figures matter. Granted is what the permission sets say the agent can do. Exercised is what its API calls actually did over the last 90 days. In a healthy setup those converge. In most setups granted is far larger, because provisioning happened once during onboarding under time pressure and nobody revisited it.

Ask for a per-object breakdown: for each object the agent touches, does it need Read, Create, Edit, or Delete? Then ask which of those it used. A vendor who cannot produce the second list is not instrumenting their own agent, which is itself an answer.

A few specifics worth checking rather than assuming:

• View All Data and Modify All Data. These bypass sharing entirely. An agent holding Modify All Data is not constrained by your role hierarchy, OWD settings, or sharing rules. Sometimes genuinely required. Never the default, and never granted "for now".
• Metadata API access. An agent that builds Flows or edits fields needs it. An agent that only reads and updates records does not. Very different blast radii, so they should not share a permission set.
• Field-level security. If the agent does not need to read a PII or financial field to do its job, it should not be able to. The cheapest control available here, and routinely skipped.
• Delivery mechanism. Permission sets and permission set groups are diffable and revocable per assignment. A cloned profile is neither. An install guide that tells you to clone System Administrator is a design signal. The profiles vs permission sets migration guide explains why that distinction is structural rather than cosmetic.

One thing worth insisting on: the agent's access should be reviewable by your team, not only the vendor's. Access defined inside a vendor platform is invisible to your quarterly review.

3. Approval gating: what earns a human, what does not

The instinct after reading the two sections above is to require approval on everything. Reasonable as a starting posture, poor as an end state. An agent that needs sign-off on every read is an agent nobody uses by week three.

The workable model gates by action category, with the mapping configured on your side.

Two design questions follow. Who configures the gates? If the vendor decides which categories are gated, you have outsourced your risk appetite to their product roadmap. What does the approval show? A prompt reading "the agent wants to update 340 records, approve?" is theatre. It needs the diff: which records, which fields, from what value to what value, and the agent's stated reason.

The graduation path is what most teams skip. Start with everything gated, track approval rates per category, and auto-approve only once a category has run clean at volume for a meaningful stretch. Approval rate earns autonomy. Vendor assurance does not.

4. Audit and rollback: can you reconstruct it, can you undo it

Two different capabilities, and vendors often blur them together.

Audit means every write links back to a run. A complete audit record answers: which run, triggered by whom or by what schedule, using which instruction, touching which records, changing which fields from what to what, at what timestamp, and with what stated reason. Native tooling gets you part of this. Field History Tracking covers a limited number of fields per object with retention that varies by edition. SetupAuditTrail covers configuration changes with six months visible in the UI. Neither captures the agent's reasoning, which is the part you will want most during an incident review.

So ask what the agent logs natively into your org, what it logs into the vendor's system, the retention on each, and whether you can export it. If your compliance framework needs longer retention than either provides, those logs have to go somewhere durable, and you want to know that before signing.

Rollback means you can put it back. Harder than it sounds, and the honest answer varies by action type:

• Field updates are reversible if the prior value was captured before the write. Any serious vendor supports this.
• Record creation is reversible by deleting what was created, assuming nothing downstream referenced it since.
• Deletes are partially reversible. The Recycle Bin holds records for 15 days with capacity limits, and cascade-deleted children may not come back cleanly.
• Metadata changes are reversible only if a snapshot exists. Reverting a Flow means restoring a prior version, which requires that a version was saved. Ask whether the agent versions metadata before changing it.
• External callouts are not reversible. Once an email has gone out or a record has been pushed to an ERP, no rollback exists. That is why callouts belong behind an approval gate rather than behind a rollback promise.

A vendor claiming "full rollback" without qualifying the callout case has not thought about it carefully. The good answer names its own limits.

5. Data handling: what leaves the org

This is where answers get vaguest, so ask narrowly.

Does org data leave Salesforce at all? Some agents run entirely inside the platform boundary. Many do not, because inference happens elsewhere. Neither is disqualifying, but the answer shapes every question after it.

Which models and which providers? Ask for named sub-processors, not "leading LLM providers". You need this for your vendor register, and under GDPR for your Article 30 records of processing.

Is your data used to train models? The answer should be an unqualified no with a contractual reference, not a settings toggle somebody has to find. Ask whether it is no by default or no by configuration, because those carry different risk when a new environment gets set up next year.

What is retained, where, and for how long? Prompt and completion logs are the usual gap. Vendors keep them for debugging, often longer than customers assume. Ask for the retention window in days, the storage region, and whether you can request deletion.

What happens to PII and PHI specifically? Ask whether sensitive fields are redacted before reaching an external model or whether the record goes as-is. If your org holds PHI, ask whether the vendor signs a BAA. If you are EU-based, ask where inference happens. Then ask what gets deleted, and how fast, when the contract ends.

The questionnaire: 15 questions for your RFP

Paste this into your evaluation. Every question is answerable in a paragraph, and vague answers tell you plenty.

Identity

1. Does the agent operate under a dedicated Salesforce user with scoped permission sets, or a shared integration user? If dedicated, is it one user per agent or one user for all agents?
2. Can we identify every record change made by the agent using only native Salesforce tooling, without logging into your product?
3. How do we immediately halt all agent activity, and what is the time to effect?

Least privilege

4. Provide a per-object list of the permissions the agent requires, split into Read, Create, Edit, and Delete, with a one-line justification for each.
5. Does the agent require View All Data, Modify All Data, or Metadata API access? If yes, for which specific capabilities, and can those capabilities be disabled independently?
6. Are the agent's permissions delivered via permission sets we can inspect and revoke in Setup, or configured inside your platform?
7. Can you show which of the granted permissions the agent actually exercised over the last 90 days in a comparable customer environment?

Approval and control

8. Which action categories require human approval before execution, and can we configure that mapping ourselves, per category?
9. What exactly does an approval request display? Share a screenshot of a mass update request, including the record-level diff.
10. Can we set a record-count threshold above which any bulk operation requires approval, and what is the default?
11. Does the agent execute changes in a sandbox before production, and is that behaviour configurable or fixed?

Audit and rollback

12. For a single agent action, list every field captured in the audit record, including whether the agent's reasoning is stored. State the retention period and whether we can export it.
13. Which action types are reversible and which are not? Answer specifically for field updates, record creation, deletes, metadata changes, and external callouts.
14. Does the agent snapshot metadata (Flows, validation rules, fields) before modifying it?

Data handling

15. List every sub-processor and model provider that processes our Salesforce data, the geographic region of processing, the retention period for prompt and completion logs, whether our data is used for model training, and the deletion timeline at contract termination.

How to read the answers

Score each answer on specificity, not on whether it flatters the vendor. "Deletes are not fully reversible past the 15-day Recycle Bin window, so we gate them behind approval and snapshot the record set first" tells you far more than "yes, full rollback".

Three patterns are disqualifying rather than negotiable. A shared integration user with no per-agent attribution. Approval categories only the vendor can configure. An inability to name sub-processors. Everything else is a trade-off you can make deliberately once you can see it.

Where Clientell sits, stated plainly

We built this list partly by answering it ourselves, so it is fair to state our own posture and equally fair to tell you what to verify directly.

Clientell's agent runs sandbox-first and approval-gated by default. Changes are proposed, a human signs off, and the change deploys with a record of what changed. Auto-approval is opt-in per action category rather than the starting state. On the audit side, the connection is read-only OAuth and the scan does not write to your org. Commercially the model is a fixed monthly price rather than hourly billing, which matters here for a reason people miss: hourly billing makes leaving scoping work undone quietly profitable.

For the specific technical controls above, ask us the same 15 questions you ask everyone else and hold our answers to the same standard. That is the point of writing them down.

If you want to know how exposed your org already is before you evaluate anyone, the permissions audit shows which users and integration users hold more access than they use, and the Agentforce readiness audit scores permission hygiene as one of its dimensions for exactly this reason.

Common questions

Is a dedicated agent user worth an extra license?

Almost always. The alternative is losing attribution, and attribution is what makes every other control enforceable. Check your edition first, since integration user license types vary in cost.

Should the agent sit in the role hierarchy?

Usually not. That grants visibility to everything beneath it, which is rarely the intent. Give it explicit access instead of inheriting a branch.

How often should the agent's permissions be reviewed?

Quarterly at minimum, same cadence as any user. The difference is that an agent generates far richer exercised-permission data, so compare granted against exercised rather than just confirming the assignment still looks sensible.

Does any of this apply to a read-only agent?

Identity and data handling do. Approval and rollback mostly do not, which is why read-only is a sensible first deployment. Prove the reasoning before you grant the write.

The short version

The security question for an AI agent in Salesforce is not "is this vendor secure". It is "what can this thing do to my org, who would know, and can I undo it".

Five answers cover it. The agent has its own identity. It holds only the access it exercises. Destructive and irreversible categories need a human. Every write traces to a run and reverses wherever reversal is possible. Data movement is named, bounded, and retained on a schedule you agreed to.