Security Best Practices with Agentforce | Dreamforce 2025

Thank you so much for making some time and attending my session on security best practices with AgentForce. So a quick show of hands, how many of you have already started building agents and deployed it for end users? Okay. A very good number. Okay. How many of you are still trying to learn AgentForce? Okay, cool. So I think it's a great session for both of you to understand what are the different security protocols Salesforce provides and see how you can build and deploy secure agent for your end users as well as customers. So my name is Vishwa. I'm a senior manager for Developer relations here at Salesforce. I've been with Salesforce for almost 10 years now and I primarily focus on creating some content and enable our developers across a pack region. So before we get into the Agent Force best practices, I would like to take a moment and understand where exactly the Agent Force is sitting on the Salesforce architecture. So agentforce is not any new technology which is outside Salesforce. It is actually built on or it is on top of Salesforce platform and it accesses the same meta unified metadata layer like any other Salesforce apps which you are using day in, day out, like sales, cloud service, cloud marketing, so on and so forth. So what does that mean in terms of security? So basically it respects all the platform access controls which any other Salesforce apps respects, just like all the licenses, profiles, permission set and field level security, so on, so forth. So there are two key aspects what we are going to focus today throughout the session. One is the platform access controls and the other one is the additional security protocols which Agent Pros agentforce provides, which will help you to build and deploy secure agents, be it from interacting or pulling data from Salesforce Instance itself or any other external LLMs. So we'll look into it one by one. So if you have been working with Salesforce technology for a while, you understand how the entire Salesforce security mechanism works. So how exactly the platform access control or the basic access control works. So it all happens based on the user who logs in. So what happens when a user is trying to log in into Salesforce? It actually tries to access what kind of license this user has, what is the profile, what are the permission sets? Based on that the user will be shown respective objects, applications, records, fields or whatever it is. So let's look into each of this one by one. So when while we are talking about the user who is logging in into Salesforce and trying to access Agent. So there are two types of users you need to understand. So which we called as Agent Force, running user so the first type of user is the user who is accessing the internal agents or employee agents. So it depends on what type of agent the user is accessing. So there are internal agents like employee agent, SDR sales coach and agent for setup. So this is run in the context of the user who is invoking that agent. So it could be pulling all the permissions which this particular user who is invoking that agent or interacting with this agent. And the second type of user is the service agent user or the external service agent. And it has a dedicated user which is called Einstein Service user. So this is a dedicated user which is created for any agent which is being accessed externally by your external users or customers through any of your websites or experience cloud, et cetera. So this, if the user has to access this agent, it runs in the context of this dedicated user called Einstein Service user or Einstein Service Agent user. So the third point here is if you're working with any dedicated user, you might be always running into access issues. You might be creating a user and it looks everything well when you are testing it, but once you deploy it, you see a lot of access issues. So one good thing is if you're building an agent, the builder has inbuilt functionality which will allow you to text in the context of the user. So you can actually test the agent as the user who is going to use it in that particular context. So now we know the logged in user and what kind of permissions they need. Let's understand what kind of permissions they need. So if you're talking about accessing internal agents or employee agents, the first thing the user need is access to the permission sets. So previously you need to assign a default permission set, but now we have made it easy. If you're seeing the screenshot, you can go to the agent and see a special tab called Agent Access where you can go ahead and assign all the permissions or the permission sets for the agent and you can also look at all the profiles which have access to that agent. So which is easy as an admin or a developer, where you can manage the access to the agent for a particular user or assign the permissions accordingly based on your business need. And second thing, if your agent is going to access data from Data Cloud, not just from your salesforce instance, you need to make sure that you assign a permission called data360user or previously called Data Cloud user. So if you're retrieving any information from Data Cloud, this is an important permissions which the user needs. So without that the agent will not be able to access any data from data cloud and there might be some actions which might invoke prompts. And if the user has to is using this agent, he should also have or he or she should have access to the prompt template. User Permissions so these are the default permission set which you need to assign for employee agent or your internal agents. So now let's talk about the service agent or any of your external agents. For service agent there is a shared permission called Agent for service agent Secure Best which is the default permission which needs to be assigned. But this gives access to only few objects, not to all all the objects because end of the day it's an external user and it's probably you need to give a very limited access. So the default objects would be cases, contacts and knowledge. So you can't extend permissions beyond this. But when you create a service agent there is a default permission set which is created which is named on the name what you define for the agent. Let's say you're creating an agent called Dreamforce Agent with which answers all the questions around Dreamforce. So there is a default permission set which is created called Dreamforce permissions. So this is where you can extend the permissions for this service agent user. You can give access to all the objects, what you think are important for this user and any apex classes or data spaces, et cetera. So this will allow you to add more permissions and there is a permission set group which is again need to be assigned if your user is going to use prompt templates and data cloud as well as of course the agent user. So these are the default permission sets which needs to be assigned for your internal user or the external service agent users. So there are some additional permissions needed. So you need to also give all the CRUD permissions that you want to allow this user to perform on any object you want based on the business criteria you have as well as the field level securities as well. One thing to note, the service agent user doesn't have view all permissions. So which means that the chat external user or the service agent user cannot access all the records. So what do you have to do is you probably need to create some conditions or create a criteria based condition criteria based sharing rules which will allow you to share what kind of data or records that can be accessed by your users. The best practices use a role hierarchy and a criteria based sharing rules and ensure that you don't place your sorry the user on the top of the role hierarchy which will actually give access to all the data. So it's always make sure you use a combination of role hierarchy as well as the criteria based sharing rule. And it's always important you have to give respective permissions for the Apex classes. If your agent is going to invoke any Apex classes based on the actions you create within the agent, or if your agent is going to also invoke any data from Data cloud or the data 360, you should also provide access to the particular data spaces as well. And as you know you can run Apex classes in different contexts like with sharing, without sharing. So flows and Apex run in the context the way you created them to run in. So these are the few additional permissions needed. But if you notice this is all for Agent for Service Agent, but for all your internal users it would respects all the permissions which you have already defined for the internal users. So all the profiles, permission set and additional field level security which you already created. So moving on. So while you're implementing agents and you're trying to test it, I'm sure you'll be running into a lot of data access issues or common errors. So these are the few common errors which I personally encountered and thought it will be helpful for you to also review it. So this is the first one. So I created an Apex action which would actually query some information from an custom object called orders. So let me I'm trying to invoke or try to ask the agent to show me the recent orders, but it is showing me some error which is actually not able to actually even invoke the action. So what could be the issue? So the issue is here, the agent must be given access to the Apex class. So if the agent doesn't have access to the EPIC class, it can't even invoke the action what you have defined within the agent. So let's say that you have figured that out and have provided it, but you see another exception or error which is a dmlexception. So any guesses what it could be? So the agent should also have access to the record or the object so that it can actually fetches that information and provides the details. So make sure that you also provide access to the objects as well if your agent is going to query any of the information from that object. Again there is another use case where I have a flow action which is failing to run, but the object OWD is set to public read only and the flow is running in the user context. So again there is an issue which is not allowing me to interact with the agent and get the required information. So any guesses what it could be? Again, so the issue is with object access, so the agent should also have access to the object in terms of getting that information, even using flow. Let's say that you have overcome that and you are trying to run that flow in the context of system. But what you're observing here is you're not actually getting the record information, but you're actually getting the product record id, which is not necessary for an user. So you need to ensure that what is the context where you're running the flow as well. So it is always recommended to run it in the user context rather than the system. Cool. So a few things to remember. Make sure as you have seen, make sure that you run your apex classes or flows in the user mode rather than the system mode, but you can use it only when it is appropriate, probably while you are implementing it or testing it. Also remember that though there are sharing restrictions, what we have discussed around the platform access control, it doesn't apply to Data Cloud. So let's say your data is being pulled from your salesforce Org and we create Data lake objects in Data Cloud or Data360. And if you're trying to get that information from Data Cloud, so security protocols doesn't apply. There is a different concept altogether around data360 which is around data spaces. So you need to work on that to make sure that the data spaces are assigned or allocated to the user. So just be caution while you're using Data360. And as you know you can debug the flow as any user. So it is recommended if you are implementing any agent, you can always use or test it on debug it on the context of the external Einstein service Agent user. If you want to debug or catch any errors before you deploy it for your end users. So that's primarily around the existing Salesforce protocols. And what are the different permission sets and observations what you need to keep in mind while you're implementing agents. Now let's look into the additional Agent Force security protocols which will give you additional privileges or enforces you to build secure agents and deploy it for the users. So any interaction with the agent your users are doing it is actually converted or taken as a prompt and there is a lot of things happening behind the scenes once you interact with an agent. So the Agent Force Trust layer comes into the picture. So it actually securely retrieves the data from your salesforce Org based on the platform access control or the security settings. What the user has and it does all the dynamic grounding and it also makes sure that there are no prompt injections and it detects any prompt injections which might be happening. And it also detects once it hits the LLM, it it also makes sure that your data is secured before it hits the LLM. So which is basically a zero retention policy what Salesforce has with any of the external LLMs you might be using. And once we get the response, the agent Force trust layer actually looks into any toxicity which the LLM might has provided, it filters it and also makes sure that there is an audit trial which captures and then shows that response to the end user. So there is a very big secured mechanism which is running behind the scenes before any interaction happens between the user as well as any external LLMs based on the interactions you have with the agent. The next thing about the guardrails for AgentForce is topic and instructions. So topic ends instructions is where you actually tell your agent what it can do, what it should do and what it cannot do. So this is where you give all the instructions to the agent, you can do this, you cannot do this, or you do not provide this, or if you do not know anything, probably hand over it to a human at certain time. So this is where you actually control the agent, what it can do. And it has multiple protocols here where you can select the topic, where it detects if the user is trying to deviate from the topic, it actually detects its soft topic and it also detects any prompt injections which are happening through the interactions. And there is a reasoning engine behind which actually ensures that the agent is following all the instructions which we have provided in the topic and make sure it is getting better in terms of responding and following all the instructions. So there is a new functionality or a new feature which is introduced recently which is called instruction adherence. Let's say you have given all the instructions to the agent, but how do you know it is actually following? Right? So this is where the instruction adherence comes into place, where you can actually go into the event logs and actually see if your agent is following all the instructions, what is the reasoning behind it, what is the source behind it. And you can see all this logs into the builder itself. You can also create reports through audit trial as well as the data cloud and see what happened during the interaction, what is the scoring around it, and try to make your agent better in terms of improving your instructions as well. So while this is happening, this is all asynchronous and this doesn't affect the response Time or the runtime your agent is interacting with your end users or the customers. So now let's get into actions. We discussed about instructions, but any agent you define or create will also perform some actions. So you can consider the actions as two types, which is public as well as private. This is nothing at a configuration level or a setting. But as a admin, as a developer, while you're implementing your agent, you understand if this action is going to be a public action or a private action. Let's say for an example, if you want to just ask what time the next keynote is going to start. It's more often general question which doesn't need authentication or a private information which needs to be fetched from a object or a fee or a field. So anything which is like a general questions or FAQ can be considered as private. Sorry, Public and private is something which needs an additional authentication. Let's say you want to fetch the status of the order you recently placed and basically the agent can ask your order details or your email id. Let's say I know your email ID and enter it and I can access that information. So you consider this as a private action where you need an additional level of security, kind of. What do you call as a two factor authentication? Let's say this is what we discussed about public actions and private actions. Yeah. So if you want to fetch some information, it needs an additional security layer where we can use the agent variables where you can send a verification code to the user to authenticate. And once the user gets that verification code, the user can input into the interaction and agent can authenticate if the OTP is valid and then provide the information based on that. And you can define that using the agent variables and action bindings which is available. And you can also use the filter filtering rules before agent performs any of the actions. It can actually make sure this filter is applied before performing that action. I know we are out of time, but Salesforce also provides an additional layer which protects you from prompt injection risks where if you have to perform any CRUD operations, there is a field called Required user confirmation which you can apply which is applied for all the standard actions. But if you're defining any custom actions, make sure that you apply this so that it gets the confirmation before it makes any CRUD actions or operations. So it's up to you how you want to secure the agent, always the guest user. It's always recommended that you have a verified private verification before there is a private action. Make sure you perform an initiative two factor Authentication which makes your agents more secure rather than just handling the interaction without a second factor authentication while there is an existing information. So that's about the best practices around AgentForce. But if you want to know more, I know this is a rapidly evolving product and there would be a lot of new features coming in. So stay tuned to Our Salesforce Developers YouTube channel if you would like to know more on the latest around the security best practices. Thank you so much for the time and see you around for the next session.