5 Easy Steps to Secure Agentforce Implementation | Dreamforce 2025

And I know you all have a choice and you made the choice to spend your lunch with us. So thank you for doing that. Without wasting much time, let's quickly jump into the agenda for the day. Most of you would have seen this a bajillion times. Yes, you've always seen this. But just for those who haven't, a quick overview. These are the five attributes of AgentForce. It all starts with the role. Role is basically the jobs to be done. What, what is the agent supposed to do then? We have data. Data is a competent, that is the knowledge that the agent has. Actions are the capabilities the agent has and what it's supposed to do. Guardrails are what it shouldn't do and channel is where it doesn't work. Why am I talking about this? Because this gives a good framework for us to spend the rest 18 minutes and 30 seconds on how to look at these from a security perspective. So we took this from and say, let's take each and every one of these attributes and look at it from a security lens. With that said, everything starts with a role. And one of the foundational things that we need to be doing is to make sure that we establish the boundary of our agent. And how do we do this? The best way to establish the boundary of your agents is by topics, because topics determine what work your agent will do and the three major components of these topics. First step is the classification description. You, you've all seen this, you all use this. What is the most key aspect of it? That is how the agent determines when should I choose this topic. So it is imperative that you make sure that your descriptions are clear, concise and more importantly, unique to the agent. Why? Because you don't want the Planner service to get confused and provide inconsistent or worse, wrong or inappropriate responses. The next one's a scope. Scope is basically what actions are available for this agent. And again, scope specificity is your friend in this case as well. Make sure you have clear, concise, without conflicts, all the actions in place. The next one is instructions. This is basically how the reasoning engine knows how do I change these events? How do I change these actions in order to achieve the goal that I've been asked to do? And again, like I said, be very specific, be explicit. Vagueness will result in vulnerabilities. We should also know where you're going to be deploying this agent. Why? Because knowing that will allow you to choose the right authentication mechanisms. Most of our private actions, anything that is sensitive, you want the user to be authenticated. If you're coming in from an experience site with an authenticated user, you're good to go. Nothing needs to be done. Everything flows in automatically because it's all handled by Salesforce. Now in a case where you're going to use an external app, you're going to use an external site, it's on you. You are responsible to make sure you pass the the user context from your app onto your AgentForce session so that I know exactly what that auth session is. If you're using third party applications like Apple, iMessage, WhatsApp, you need to completely build in that authentication flow into that interaction itself. The key point here is that you need to make sure that somehow the user context is passed on to the agent force so that it can scope as activities to just that user. Finally, it's not just enough to do things in the happy path. Think about how can I make this agent do things it's not supposed to do? How can I make it give me data that I don't have access to? And the best way to do this is by generic threat modeling. What it does is like, it allows you to create a list of everything that you want to look at and then you can go through each one of them and put guardrails, put controls around them so as to mitigate them. So this is a very, what do you say, a structured way of thinking about this. So the second most important aspect that we want to get into would be data. Data is foundational. The agent needs data to do its work. The agent needs data to understand what you're saying, to give more information back to you. Just because it needs data, it doesn't mean it needs all data. The concept of least privilege apply here. So make sure your agent has access only to the data that it needs. You can use permission sets just like I would use in Salesforce. Make sure that it's all tied down. And again we always forget that org wide defaults. Let's make sure that we don't forget it here. As well as you look into the data itself. One of the biggest things to notify is that sometimes you're going to have sensitive data. You're going to have data that you need extra handling, extra care. When you do that, make sure that your agent is aware of that. And your agent has those capabilities built into that. Honor your organization's classification policies. And when you're using external data sources, it's even more important to be more careful. Why? Because none of your Salesforce construct of permissions apply to those external data. You Write something there. You don't know who has access to it, you're reading from some untrusted sources, you don't know where that data comes from. So pay attention to that. And the last item I wanna quickly call out is our knowledge articles. Right? Knowledge is basically how I will know what to respond back to an agent inquiry. Make sure the knowledge is accurate, kept up to date, and more importantly, an agent to knowledge mapping is one to one, meaning that anything in your knowledge index is available for the entire agent user. So now we'll pivot on to the next big aspects, which is our action types. Right. There are several action types. We're gonna go through each one of them to enunciate what risks exist in each of those first ones, the standard action. Standard actions are what Salesforce builds out of the box. They leverage other actions. They can be different action types. The biggest issue here is that whatever the underlying mechanism is, that risk is now manifested into the standard action itself. So it's not that the action is built in securely, it depends on the implementation, the context in which it's executing, and whether the scope in which it's executing. So pay attention to those when you're using standard actions. Next up is going to be your prompt templates. Just as the name says, prompt what comes into your mind as soon as I see prompt prompt injections. So those are the biggest risks here are direct and indirect prompt injections. So make sure that that you don't you validate your inputs, make sure that your grounding data is accurate and it's not poisoned, and more importantly, make sure that your instructions and your data is clearly separated out. Next up we're gonna be talking about flow actions. Flow actions basically call upon a flow. Just like how flows are here. The bigger concerns are flows can be executed in elevated privileges and flows can be calling the flows or subflows. So when you're doing this, the biggest thing to pay attention is to make sure the flow always runs in the context of the user that's executing it. Why? Because when you do this, all your platform security stuff that you've already put in is now transcendent into your action as well. Next up is going to be Apex. As the name suggests, everybody knows Apex, the most powerful one. These actions are by far one of the most powerful and risky ones. It could have everything that developers do. It could cause SQL injections, it could cause elevated DML permissions, it could have insecure patterns. Everything that you would associate with a normal coding issues will be here as well. One of the other big things here is that this could also result in remote code executions. And the best practice here is to use the which Sharing annotation. When you use the which Sharing annotation, everything again runs in the context of the user. And finally jumping on, we're going to be getting into API Actions. API Actions is very similar to Apex, but the difference here is that you're now interacting with systems outside of the Salesforce construct. You're going to be talking to external systems and this is going to be susceptible to any risk that a modern web app would have, plus all the gen AI risks. So make sure you're very careful when you're using API Actions. Some of the best things to do is I've been talking about we're validating inputs, inputs, inputs. You might also want to validate outputs because you want to know what you're going to be sending out. You want to make sure that you have authorization and authentication implemented, especially when you're touching external systems or external data sources. Again, standard must do always use encryption in transit so that there's no man in the middle attacks. And the biggest point is here is like you need to also document who's the recipient system, make sure that system is secure. It doesn't matter if your house is secure and you send a mail out to an insecure spot that's going to get leaked out. So, so pay attention to it. And I know if you've noticed it, you've seen that Stride annotation. For those of you who are not familiar with Stride, I didn't want to get too much into it, but looking at the clock, I got a minute, so I'm going to get into it. So STRIDE basically stands for your acronyms for spoofing, tampering, information disclosure, denial of service, and E for elevation of privileges. So all of these are risks that can manifest from these kind of actions. Along with that, we also have your remote code executions. One thing that I also want you to pay attention is the context. What is the context? So the context is basically what's in your chat window that is very, very important. Why? Because the agent uses a context to understand your intent. Once it understands the intent, it goes in and picks the topic. Once it picks the topic, it picks the action that needs to perform. Then the action performs using the context that you already have. Once it performs an action, it generates more context and that cycle goes continues on and on. And that is very, very important to maintain the integrity of this context. Because if that context integrity is broken Your agent is now susceptible doing things that a standard LLM would do, which is it's gonna be non deterministic, it's gonna give you stuff that you didn't expect. So pay attention to those. As you continue on, I'm gonna take a pause and pass it over. Oh, I did have a slide on agent conversation context, so there it is. And I'm gonna take a time and pass it back to Joe. Joe's gonna be talking more about the rest two the guardrails and monitoring. Right, Take it away, Joe.

Thank you so much. As SRI said, you need to be aware of the context of what's going on. This is used by the agent forest executor to perform all of those actions and determine what's going on. Some of the things you do need to be aware of with that context is this is where you're going to be putting things like when you identify a user, who that user is, what their privileges are, and if someone is able to adjust your context, they may be able to convince the Planner service to run actions that they're not supposed to have access to because the context of that conversation will be corrupted in addition to the conversation context. I know there's a lot of context going around the security context of your actions that they're running in. So if you're doing an employee agent that generally will execute actions as the user that's logged in, as SRI noted earlier, flows and Apex by default, their data operations tend to run and elevated in a system context. So it's not just I have an employee agent and it's going to be great and it's going to only do what the employee user account can do. If you're invoking Apex, it's using default DML statements. That's going to run in system context. If your flow runs in system context, that means that that action is going to be invoked and execute with virtually unlimited privileges within your Org. This is again where that threat modeling, that documentation of here's what we're doing here, all of our actions and having that understanding of what's going on within your agent really helps you understand where those security context changes take place and how to manage that risk. Similarly, if you're building an agent that needs to take actions on sensitive data that only certain users should have access to, there are private actions. Various channels give you various mechanisms of authentication and authorization. If they're coming in through an experience channel, you already know who that user is. You may have some work to do on your own. If it's a different channel, but making sure that you're building your actions and all of your instructions in such a way that any sensitive actions have those guardrails around them to make sure that a user can't just arbitrarily invoke them. There's a lot of controls that are built into agentforce that allow you to tighten down all of this. Use of agent variables agent binding A lot of this was covered in a previous talk at tdx. But using these capabilities to ensure that data integrity is preserved as your conversation context is providing information to your actions and then your actions are then returning that data to the conversation context using those agent variables, using action binding, make sure that there's higher bar for someone being able to tamper with that data. When we get into more complicated agents where they have to take certain actions at certain times, deterministic execution is something to be aware of. If you have a specific need that action A always gets executed before action B. You can put guardrails in place, but remember that your LLMs that are powering this thing are non deterministic by nature. There is a small but non zero chance that your instructions may get executed out of order. If you need something to absolutely be guaranteed to execute an order, you're going to have to go outside of the Planner. You can accomplish that with Flows, with Apex, with external API calls, with whatever. But if you need to have that guaranteed order of execution, understanding the limits of the Planner and the other capabilities of the platform really help you to make sure that what you're building is not just secure, but that it's accurate, that it's relevant, that it's scalable, that it handles unexpected situations. You get a lot of benefit beyond just security from keeping these considerations in mind. Real high level. We talked a lot about the guardrails. Again, starting out that principle of least privilege. Only giving your agents what they need to do, doing that verification, thinking about your agent ahead of time, building security in from the very beginning, using the capabilities of the platform to minimize and mitigate any data corruption or malicious activity that may be attempted against your agents, and then finally having that control and monitoring, being able to see what your agents are doing not just from a security standpoint, but from a reliability and accuracy perspective as well. Speaking of monitoring, there is a lot available on the Salesforce platform. You can actually get an overview of everything that your agents are doing, every action they're taking, all the conversation context, all of this can be logged and used for later analysis. This means that you can see what happened, when it happened, who did it, why it happened. You can see the reasoning plans from the Planner engine and see that context Flow with the Agent 4 Studio Interaction Explorer. Again, you've got this nice drill down drill into behavior. You can use this not just if you have someone who's abusing an agent and you want to see what they're doing and why the agent's doing what it's doing, but also to measure your accuracy, make sure that your prompts are executing correctly and maintain user satisfaction. If you need more, there are more capabilities available. SHIELD Event monitoring gives you much more detailed information. You can take your agentic information, all of that execution context, all of those actions and everything, put them into data clouds, then you've got the ability to chop and sort your data as much as you need to have that unified view across all of your interactions. Build out reporting, build out analysis to see how things are working. As you're doing all this logging, I'm going to put my security hat back on now and warn you, yes, you can log absolutely everything that an agent's going to do. If your agent is working with sensitive user information, with private information, with someone's bank accounts or whatever, be aware of what you're logging and log appropriately. Users that may not have direct access to someone's bank account and their transactions may be able to view the logs because they're doing reporting or whatever else. So if you are going to perform actions with restricted or sensitive data, be careful what you log. Make sure that you mask it, make sure that you encrypt it, make sure you restrict the log access as appropriate. Being aware of what you're logging can really help from a compliance perspective. When the compliance folks come in and say, okay, we need to be sure of what you're logging, no one has access to it. You can guarantee that because you thought about it from the beginning. All right, I'm going to talk through a quick demo here. We built an ASA agent. Unfortunately, we built it before we came to the session. So we didn't do threat modeling, but we did build out something that has knowledge retrieval. It's going to answer questions based on a data library. So we have our data library built. The agent has those instructions in its topic to use it to answer questions. We can jump out to our support agent. This is again, public facing, unauthenticated. A user can come in, they can ask questions about what we're doing. Of course, we're media cloud, we do all sorts of fun stuff. But also we can look here and See that there's some internal documents that are exposed. This harkens back to when you're building those data libraries. There is no access control on what's indexed and what's retrieved. Anything you put in that data library is going to eventually be disclosed by the agent. Our agent also can query data. Very useful. Give our customers that great experience. We give our customers the ability to get a summary of a movie as well. So we're displaying these movies and they want to look at it. We do that with a simple prompt, being very careful to not introduce any biases in our prompt. However, when the user runs this and they look at the reviews for Godfather versus Pulp Fiction, they get a negative summary on that Pulp Fiction review. Positive on Pulp Fiction. Because if we look at our data, Poison. We look at our data here, we see in the plot, someone has introduced some poison data. Someone asks about the Godfather, they're going to get a positive review, not just a synopsis of the plot. Similarly for Pulp Fiction, negative. Finally, we left the privileged action and accidentally we have a flow that will update the runtime of a movie. When the user invokes that flow, since we exposed it through the actions, it's accessible to users of the agent without authentication. Normally, we would expect that. Hey, it's okay. We've got a minimally privileged user. Our ASA account is a service account. It runs with a permission set that only has read access. However, we didn't take into consideration security context of the flow. Flow is running in system context. It's invoked by the runtime. Boom. It runs without any privilege restrictions at all, and it automatic. And it goes ahead and updates our data values to the wrong ones. With that I'm right at time. So thank you again for coming out. Really appreciate you spending your lunch with us. Thank you. Sri. Lanka.