AI Agent Security in Salesforce: The Vendor Questionnaire

AI agent security in Salesforce comes down to five controls: the agent's identity, least privilege, approval gates, audit and rollback, and data handling. Ask every vendor to prove all five inside your org, not in their slide deck.

An AI agent in Salesforce is software that holds a Salesforce session and writes to your records on its own. A reporting tool reads; an agent acts. Clientell AI, the AI Salesforce admin, is one such agent, so we answer these questions too. Before you evaluate anyone, a free Salesforce permissions audit shows which users already hold more access than they use, in read-only mode.

Why does the usual security review miss agent risk?

The usual review asks about encryption, SSO (single sign-on) and the vendor's SOC 2 report. Those questions describe the vendor's own servers. They say nothing about what the agent can do inside your org on a quiet Tuesday.

A reporting tool's main risk is data leaking out. An agent's main risk is a wrong action, such as an update to Opportunity.Amount that a model chose, not a person you can ask.

So the controls that matter scope, gate and record actions. Good controls let an agent take on high-volume work while your admin keeps the decisions.

1. Which user is the agent?

Every change in Salesforce has an actor. The actor sets what is allowed and what appears in Setup Audit Trail, field history and login history. Vendors give one of three answers.

A shared integration user is the case to name plainly. A middleware tool, a marketing app and two old scripts often log in as one user. An agent on that login inherits years of extra access. Our permissions audit guide explains why integration users drift toward admin rights. Salesforce now offers API-only integration users for this job.

Then ask the test question. "If I open Setup Audit Trail tomorrow, can I list every change your agent made yesterday, without your product?" If the answer depends on the vendor's dashboard, your audit trail has an outside dependency.

Per Salesforce Help, Setup > View Setup Audit Trail shows the 20 most recent setup changes. The Download button covers 180 days. To list the agent's setup changes, query by its user, for example SELECT Action, CreatedDate FROM SetupAuditTrail WHERE CreatedBy.Username = 'agent@yourco.com'.

How do you set up a dedicated agent user?

1. Create the user. In Setup > Users, add a user such as agent@yourco.com, with an integration or API-only profile.
2. Add only the needed permission sets. Start with read access to the objects the agent's first job touches.
3. Test in a sandbox. Run one job and confirm its changes show the agent user in field history.
4. Check the result. Every change from that job lists the agent user, and nothing else does.
5. Keep a stop switch. If the agent misbehaves, freeze the user in Setup > Users. Unfreeze it once you fix the cause.

2. How do you check least privilege?

Every vendor says "least privilege". Make them prove it with two lists.

1. Granted access: what the agent's permission sets allow, per object: Read, Create, Edit, Delete.
2. Used access: what its API calls actually did over the last quarter.

In a healthy setup the two lists match. In most setups granted access is far larger, because someone set it up once in a hurry. A vendor who can't produce the used list is not measuring its own agent.

Find risky grants yourself with one query: SELECT Assignee.Name, PermissionSet.Name FROM PermissionSetAssignment WHERE PermissionSet.PermissionsModifyAllData = true. Any agent or integration user on that list needs a reason in writing.

Check these four points directly in Setup.

• View All Data and Modify All Data. These user permissions skip sharing. An agent with Modify All Data ignores your role hierarchy, OWD (organization-wide defaults) and sharing rules. Never grant them "for now".
• Metadata API access. An agent that builds flows needs it. An agent that only updates records does not. Keep the two in separate permission sets.
• FLS (field-level security). If the agent doesn't need a salary or health field, hide it. This is the cheapest control you have.
• Permission sets, not cloned profiles. Sets can be reviewed and removed per user. An install guide that says "clone System Administrator" is a warning. See our profiles vs permission sets guide.

Your team must be able to review the agent's access in Setup. Access defined only inside a vendor's platform escapes your quarterly access review.

3. Which actions should need a human approval?

Approval on everything sounds safe, but nobody uses that agent by week three. Gate by action type, and keep the settings on your side.

Ask two follow-up questions. Who sets the gates, you or the vendor? And what does the approval screen show? "Approve batch update?" is theater. It must show the records, the fields, the old and new values, and the agent's reason.

Earn autonomy step by step. Start with every type gated. Track the approval rate per type. Auto-approve a type only after it runs clean at volume for a full month.

4. Can you trace and undo every change?

Audit and rollback are two different abilities, and vendors often blur them.

Audit means every write links to a run: who started it, which instruction, which records, which fields, old and new values, and the agent's reason. Native tools cover part of this. Field History Tracking keeps data for up to 18 months, but only for fields you chose. Neither tool records the agent's reasoning, which you need most in an incident review.

Rollback depends on the action type.

A vendor that promises "full rollback" without naming the outbound case has not thought it through. A good answer names its own limits.

5. What data leaves your org?

Answers get vague here, so ask narrow questions.

1. Does org data leave Salesforce? Many agents run their model outside the platform. That is not a deal-breaker, but it shapes every next answer.
2. Which providers see it? Ask for named sub-processors (outside companies that handle your data), not "leading AI providers".
3. Is your data used for model training? You want "no" in the contract, not a settings toggle.
4. What is kept, where, for how long? Prompt and response logs are the usual gap. Ask for the retention in days and the storage region.
5. How are sensitive fields handled? Ask if personal data and PHI (protected health information) are masked before they reach a model. If you hold PHI, ask whether the vendor signs a BAA (business associate agreement).

What are the 15 questions to send every vendor?

Paste these into your RFP (request for proposal). Each one can be answered in a paragraph, and a vague answer tells you plenty.

Identity

1. Does the agent run as a dedicated Salesforce user or a shared integration user? One user per agent, or one for all?
2. Can we find every change the agent made using only native Salesforce tools?
3. How do we stop all agent activity at once, and how fast does that take effect?

Least privilege 4. List the permissions the agent needs per object (Read, Create, Edit, Delete), with a reason for each. 5. Does it need View All Data, Modify All Data or Metadata API access? For which features? 6. Are its permissions in permission sets we can inspect and remove in Setup? 7. Which granted permissions did the agent actually use last quarter in a similar org?

Approval and control 8. Which action types need human approval, and can we set that per type? 9. Show a screenshot of a mass-update approval, with the record-level changes. 10. Can we set a record count above which any bulk change needs approval? 11. Does the agent test changes in a sandbox before production?

Audit and rollback 12. List every field in the audit record for one action, the retention period, and the export format. 13. Which actions can be undone: field updates, inserts, deletes, metadata, outbound calls? 14. Does the agent snapshot flows and fields before it changes them?

Data handling 15. Name every sub-processor and model provider. Give the processing region, log retention, training use, and the deletion timeline at contract end.

Three answers rule a vendor out: a shared integration user with no per-agent tracking, approval rules only the vendor can change, and no named sub-processors. Everything else is a trade-off you can make with open eyes.

How does Clientell AI answer these questions?

Ask us the same 15 questions and hold us to the same bar. Clientell AI holds SOC 2 Type II, ISO 27001 and HIPAA. It reads your org in read-only mode first, builds changes in a sandbox, tests them, and asks before it changes anything in production. See how Clientell AI keeps your org safe.

Try it in Clientell AI: "List every integration user, the permission sets each one holds, and any with Modify All Data or View All Data." Start the 14-day trial, no card. The Agentforce readiness audit also scores permission hygiene before any agent goes live.

Sources

Salesforce documentation

• Monitor Setup Changes with Setup Audit Trail
• Permission Sets
• User Permissions
• Give Integration Users API Only Access
• Field History Tracking Overview
• Recycle Bin

Last reviewed October 2026

Last updated: October 22, 2026