Agentforce Security: What Salesforce Covers and What You Own

So you’ve rolled out Agentforce. Have you checked what the agent is actually allowed to do? For most teams, the honest answer is no, and the uncomfortable part is that its access is usually much broader than anyone planned. An agent works with whatever permissions it got at setup, and during a pilot those are rarely chosen carefully. A common shortcut is to clone an existing permission set just to get the agent running. That set may include read access to Contact, Account, and Opportunity fields nobody has reviewed since the last org merge, and the agent inherits all of it. Because it answers questions well, no one asks what it can see or who should approve changes to that access. This is one of the risks teams can encounter when moving an Agentforce pilot toward production without a dedicated security review. The Gravitee’s State of AI Agent Security 2026 report found that nearly 38% of organizations already run more than 100 agents, while only 14.4% say all of theirs went live with full security and IT approval. Salesforce customers sit inside that number, and the agent inherits every permission decision your org has made since the day it was provisioned. For an enterprise, that turns into one question: “which parts of agent security does Salesforce actually own, and which parts stay with us once the agent starts reading records, firing actions, and talking to customers?” Most AI security reviews skip it and go straight to the model. Agentforce ships five security layers, you configure four of them, and that gap is where deployments go wrong. Prompt injection and LLM-level risk live in Sombra’s guide to LLM security risks in 2026; this piece stays on the Salesforce platform side, on what to configure before go-live and how to keep hold of the agent afterward.

This is a short preview supplied by the publisher. The charts above are separate ApplyDjinn observations. The complete story, including images and updates, remains with the publisher.