Video: How to Monitor Agentforce Activity and Reduce Security Risk | Duration: 1816s | Summary: How to Monitor Agentforce Activity and Reduce Security Risk | Chapters: Welcome and Introduction (8.35s), Agentic Security Landscape (92.46s), Salesforce Security Layers (244.58s), Event Log Objects (400.17s), Event Monitoring Dashboards (560.105s), Real-Time Agent Governance (832.175s), Transaction Security Policies (1064.855s), Roadmap and Q&A (1385.8s), Auditing and Use Cases (1668.16s), Real-Time Event Storage (1695.93s), Closing and Q&A (1714.91s), Closing Remarks (1808.21s)
Transcript for "How to Monitor Agentforce Activity and Reduce Security Risk": Hello, everyone. Welcome or welcome back to another Salesforce Ben webinar, this time in collaboration with Salesforce. I'm Simon, and I'll be your host for today's session, And we'll be covering how to monitor agent activity to reduce risk, and there's a lot for us to cover today, so I won't keep you for very long. Some general housekeeping before we get started. You are in listen only mode, so please do use the chat function to interact with us and each other throughout. This session is being recorded and will be shared in our follow-up email along with the slides, and there will be a q and a at the end. So please do submit your questions in the q and a tab throughout. But without further ado, I'd love to introduce our speakers for today's session, Trevor Scott and Purva Korshell. Thank you, Saima. Hi, everybody. I'm Purva, product manager for event monitoring and field audit trail, focusing specifically on transaction security policies, threat detection, and real time events. And, of course, with me, I have Trevor. Hey, everyone. Trevor Scott here, also a product manager for event monitoring, specifically for event log objects, event log files, analytics, and some new observability features. Awesome. Thank you, Trevor. Before we begin, just want to quickly remind you all about Salesforce's forward looking statement slide. Please make sure to make all of your purchasing decision based on what's already available and GA today. Now we have an awesome agenda set up for today. We first start, talking about how we've seen the way the world has changed around this whole agent experience, specifically when we talk about security. We know how agents have changed the way we interact with all the apps and the products. But it's also changed the way we think about security when it comes to how the agents are accessing your data. We talk about some of the things that we have heard as product managers from our customers, from the market research, And we'll talk about how you can then use Sheel's event monitoring to mitigate some of the concerns and reduce some of the gaps that are that are still existing out there. At the end, we'll talk about something that we as product managers love to talk about, roadmaps. We'll give you a sneak peek into what's upcoming and the latest capabilities with Sheets event monitoring. So without further ado, let's get going. Trevor, do you wanna start? Absolutely. Thank you. Alright. So let's talk about how the agentic experience is changing the security landscape. So AI is changing everything. Right? And as we adopt AI, we're driving outcomes, with agents together, and agents are gonna span, the whole system, the whole platform, and lots of different kinds of workflows. They're gonna work it autonomously. They're gonna anticipate our needs and elevate our impact. And the security landscape is changing a bit, right, because it was designed for humans. And with agents, we need to kind of lift and shift a little bit. We need to kind of take special consideration into, how we think about security in this new agentic landscape, especially because attackers are really enabled by AI. Just like AI is enabling us for positive big business outcomes, AI is also enabling, malicious actors, to move at, speed and scale that is unprecedented. So that's why it's more important than ever, to have visibility into your organization to see what agents are doing, to make sure that you can audit exactly what the agents are doing and actually build trust in the agents that you deploy into your org and to enforce policies and governance on them because they have the ability to do things like modify or delete data. So we definitely need that governance layer as well, and Porvat's gonna talk about that later. And now I'm gonna hand it off to, Parva. Thank you, Trevor. In Salesforce, when we talk about operating in a headless environment, it does not mean that you have to rethink all of your security strategy. At the foundation layer in Salesforce, we have a lot of capabilities like multi level tenant isolation, hyperforce, encryption, data residency, site reliability. These are all capabilities which actually help protect your agents and the data that your agents interact with. You can think of this as the security of the infrastructure in which your agent and your data resides. When we think about configurables, which is our next layer of security, we've always considered them from the perspective of human users. Your profiles, your permissions, your org wide defaults, field level security, your sharing. Today, depending on how your agents are configured and in what identity they run as, you can extend all of these configurables to your agents as well. For example, if you have an agent that's working with the contact object, but the agent has no business looking at the billing address field of your contact record, you can set up the FLS in such a way that your agents do not have access to that field or any of the values. We have another layer in Salesforce, which one we call as the enhancements. Now these are premium suite of products, which actually help you provide capabilities like greater visibility into your agent and human activities, protection through encryption, masking, helping you make it easy to comply with privacy laws, and a lot more other capabilities. These products fall under the umbrella of Salesforce Guardian. Today, we'll be focusing more specifically on Shield's event monitoring. What exactly is this product? Event monitoring is a product that gives you more detailed visibility into human and agent activities in Salesforce. It generates traces, logs, events, and spans, which gives you detailed information on when... Who and when, or who or what performed an action, when did they perform an action, and where in the application did they do that. You can then build even analytics on top of all of this telemetry. So you can understand and and identify any check patterns, understand if your... You know, how your users are behaving, what is your user usage pattern, and even find any performance blockers through traces and spans. You can also build policies to prevent any risky or malicious activity from actually being completed and secure your data. Let's see that into all these different pillars of event monitoring. Trevor, I'll let you begin here again. Thank you,. Yes. Let's, talk about event log files real quick. So the first feature of event monitoring... And it has great breadth, meaning it covers the whole platform. We have over 70 different events. Really a fantastic source of data for all three of the canonical use cases for event monitoring, performance, adoption, and security, and, really critical for, security investigations, and a great tool for exporting the data into third parties because we have a bunch of, you know, out of the box, third party connectors to, you know, solutions like Splunk and Datadog. So our newest feature, well, a continuation of the event log files is event log objects. And, we made a bunch of different improvements here, when handling log data. Instead of storing the data as a file that gets generated every hour and twenty four hours, we're now gonna store that data in a matter of fifteen minutes into standard objects so that you can query it with SOQL and do aggregate queries and flexible filtering. And we built, out of the box dashboards for security, adoption, and performance use cases. And, because you can query all this data with SOQL really easily, it's really easy to extend and build off of the log data to do things like build custom dashboards, build custom lightning apps, and also build custom headless skills as well. So event log objects, fantastic, solution, for just getting access to data sooner and also building on top of it. And the prebuilt dashboards, you know, I I I glanced over this, and I will show you kind of go in-depth on these ones in a minute. But we have prebuilt dashboards around security, application performance monitoring, and adoption. And the newest feature of event monitoring I'm really, really excited about. This is a brand new capability that we've been working on where we use OpenTelemetry, SDKs to instrument the core platform as well as agenda capabilities like MCP. And, we've integrated deeply with a new, a new feature on the platform called the agentic identity so that you can really understand who is doing what with what registered agent. And I will give you a demo of this in a minute. Okay. So let's walk through, the dashboards, and let me just bring up the demo real quick. Okay. So the first demo that I wanted to show you is, the event log objects dashboards. And so, with this feature, you can go into CRM analytics and create a new app. If you just search for event log objects, we have this, new application in CRM analytics called event monitoring and event log objects analytics. And with it, we have three new dashboards, the threats and access dashboard, the adoption dashboard, and the performance and health dashboard. And so this is a fantastic solution for, auditing users in the in the organization. And I wanna point out that you can actually, sort or filter by specific user in the org, and and also by a specific time frame as well so that you can do a scope assessment to see exactly what a user did in a specific org. And so this is a really fantastic solution for understanding what's going on in the org specifically for users. Right? And we give you information about the, real time event, threat detection data, as well as what we think are high risk activities like inactive user logins, data exfiltration, authentication patterns, and locations, as well as time series data around around logins, the exact records that are accessed in the org, and API activity. And so you can actually filter by, the agentic API service here to see exactly what sort of MCP calls are being made into the org. So this is a really kind of quick way to understand what agents are doing in the org. And, additionally, you know, we also have the other dashboards around, adoption. So you can understand adoption in the org, and the user journeys that people take through the org. Dish... And lastly, we have the performance and health dashboard to, help you understand if there's any slow, apex or flows in in, or API calls in the org as well as understanding what the errors look like and what the time series data is related to errors so that you can really spot if there's a specific spike and, like, identify certain patterns in the org, to see if there's an opportunity to fix, any of these errors. So these are the dashboards for event log objects. And now I want to just shift into our newest feature, the observability and tracing app, that is part of the the Shield app. And so with observability and tracing, it's going to live in the event monitoring tab, and, we're gonna give you all sorts of information about active agents in the org, how active they are with request rates per minute, how slow they are, you know, if... What the average latency is for their end to end requests, as well as if, you know, anything is broken in error rate here as well. And so we'll have a service breakdown, what are agents accessing at a high level, we'll have a status breakdown, what percent of errors, are there, as well as kind of top adopters in terms of the different agents in the org and the different users. And so I wanted to show you you can filter down in this trace table here for a specific agent. And so I, registered this agent with that identity, agentic identity, and you can filter by this specific agent and see everything that they've been up to. And in this table, we have a view that kind of, like, at a glance, kind of lets you see exactly kind of what happened. Okay. We can see that this agent had an MCP call, an API request afterwards, and then we can click into the trace tree and see exactly what happened. Every single unit of work that happened on that agentic transaction that called the MCP, tool. So, here, we can click into the different spans over here on the left side... Oh, sorry, on the right side and get specific details. And, we can see here that there was delete. And so this is a really fantastic auditing tool, so that you can really gain confidence in your agents and understand exactly what they're doing in the org. Really excited about this feature, and, and you will hear more about it soon. Alright. So with that, I think I'm gonna hand it back over to Porta. Awesome. That was great, Trevor. Thank you so much. Now with event monitoring, as Trevor showed, you can observe and audit your agents, but you can also govern your agent activities in real time and block those activities if they are risky or malicious depending on your org security criteria. Let me show you what this means with the help of demo. Now before I share my screen, I wanna talk about my fictitious demo organization. It's called ebikes. It's a seller of electronic bikes that sells its bike to different retail stores in the country and globally as well. Ebikes built its business on top of Salesforce platform. And like a lot and like a lot of other companies, it wants to embrace AI across its business. I'm sharing a Slack profile of a Ebikes sales associate, Jennifer. Now Jennifer is leaving the company, but she wants to take some critical data with her so she can reuse that and leverage it at her new job. Now Jennifer is aware that she could not access that critical data when she tried to use this, via the Salesforce traditional experiences because there were some policies set by the admin, and she could not access that data. So she gets into Slack. This is where she gets most of the job done when she starts her day. And she puts in a very simple prompt. Give me name, email, and phone, all contacts in USA. Now it's very important to note here that Jennifer has legitimate access to some of this data. However, even the agent actually is configured so that she can do her job in a more productive fashion. But the problem that she put in here crosses the security boundary of her organization, which is set by the security admin. The message she gets here from the agent was basically saying that whatever prompt she put in does not comply with the policy and therefore the agent could not complete the transaction and give her that list of contact. But let's make this little more interesting. In today's world, your interaction with Salesforce data does not have to only be bound by the Salesforce experiences that existed. You can build agents by using third party applications and then interact with Salesforce data using hosted MCP servers. Ebikes did something very similar. They built an agent powered by Cloud, which then interacts with Salesforce data using Salesforce hosted MCP servers. Jennifer thinks, wow. Let me try that agent and see if I can get the same response or hopefully get, you know, a list of all of those records. So she gets on to this e bikes assistant app, which is powered by Claude, and puts in the same query. Now the way Jennifer is thinking here is that with traditional Salesforce experience, the policy was not working. With, employee agent in Slack, you know, it's making a direct API call. So maybe that's why the policy is still getting triggered. However, this agent is now using Salesforce hosted MCP. So maybe the policies will be bypassed and she'll she'll get that list of records that she's been wanting since so long. But the response that she gets here, the message is a little different, but the core underlying, meaning of it is still the same. She tried to access some data, and the plan that she put in does not comply with the policies of the organization set by the admin because of which even this agent could not give her that information. The important thing to note here is that irrespective of whichever experience she tried to use or whichever agent she tried to use, the policy stuck with the data. With event monitoring in the background, the policy stays with your data in the agenting experience, irrespective of whichever agent you try to use. Let's go back and see what exactly is happening in the background. In event monitoring, we have real time events. Now these are events which get generated, of course, in real time as the name suggests, whenever user or an agent performs a certain activity. A very simple but important example here is report event. Anytime a user tries to turn a report, download a report, or create a report, an event gets generated which has detailed information about that activity. Similarly, if you have your agent configured to do any of these activities, an event will also get generated. It will have a lot of granular information, which has details like which agent ran the report, which user prompted the agent, how many records were they able to see, for which fields were visible in the in the report, for which object was that report created, and a lot more other details. Another very crucial example here is API events. These events are generated whenever a human, a client, or an agent tries to access Salesforce data through Salesforce APIs. It again has a lot of detailed information. How many records were they able to access? What were the records? What was the query? For which object was that API event being generated? And again, a lot more other information as well. Along with this, event monitoring has transaction security policies. Now, these are custom policies which you can define based on your auth security criteria. Once you create this policy using the condition window or by an Apex method, you can enable these policies quickly in your own. And anytime that the just key activity actually occurs, which does not meet the criteria, you have the ability to decide what action do you want to take. Do you want to block that activity altogether? Do you just want to notify somebody but let the activity complete? Or in case if it's a user who's performing that activity, do you want the user to re authenticate themselves before completing the transaction? Let me show you with a very simple example how easy it is to build these policies in Salesforce. I'm going to start with an example using report event. I want to create a very simple policy where if someone's trying to download a report which has more than 50,000 records, block the activity. So I'm gonna go back to my screen sharing here. In Salesforce setup, you can find transaction security policies. I'm gonna click new here. I'm gonna select condition builder as my option because I'm gonna create this policy declaratively. On this page, I'm gonna select the event to be report event. Now under the condition section here, these are all different attributes that are available with your report event. So you can see there are a lot of thing that the report event captures. I'm gonna scroll and find those processed. I'm gonna give the value greater than 50,000. I'm gonna add one more condition, which is the export condition. So I'm gonna go for an attribute called operation. As you can see, there is a lot of different operations that your report event can capture. I'm gonna select report exported and then go next. On this page, I can choose the action that's gonna occur whenever this policy gets triggered. You can either choose to do nothing, just notify somebody so at least somebody's aware that these activities are happening. You can block the activity altogether. Or if in case of a user, you can make the user reauthenticate themselves before completing the transaction. I'm gonna go ahead and choose block over here. You can then define your own custom block message or use the default block message. Choose who you want to send a notification to on top of the block message, and then give this policy a name, and that's it. Just enable the policy, and that's it. You're done. Your policy is deployed in your organization, and anytime a report is done, which does not meet the criteria, the policy will be triggered. Now in the case of the e bikes use case, my my requirement is a little bit more complex. I wanted a policy where anytime someone tries to access contact records and if the fields they're accessing are classified as sensitive or PII based on Salesforce's data classification settings, then block the activity. For that use case, I wrote, relatively simple Apex, which identified all of this criteria. Once I wrote this Apex, I went ahead and created a new transaction security policy and just added the apex and set the condition to block. Now if you're thinking, oh, this is a great example, I can reuse this exact example for my use case or tweak this a little bit so that, you know, it works for your use case. Or if you want to build your first ever transaction security policy, we have a very quick solution for you. We created a a managed package called DSP accelerator app. This package has 10 plus different transaction security policies, which are spread across different security lenses. It has examples on how we can prevent data exfiltration, examples on authentication, authorization, check detection, and monitoring use cases. Once you deploy this package in your org, with just a few clicks, you can enable multiple policies in your org as well. So if you're interested, we do have a QR code on this slide over here, but this package is also available in GA on AppExchange, and you can find it by the name d s p accelerator app. Now we've spoken so much about, you know, how agents are interacting with your data, how you can keep it secured. But the speed at which agents are advancing, the technology is advancing, it's very important that even the security of the agents and data goes at the same space, which is why we have a lot of amazing things on our road map for event monitoring. I'll start talking about a little things within the transaction security policies first. The example that I showed today for data classification with e bikes and Jennifer, I had to use Apex. We're actually incorporating all of that into the TSP framework so you can build these policies without the need for you to write Apex declaratively using the condition better. On top of that, we're also adding an agentic skill for the same so that you can build this example or any other DSP example using just natural language. We're also continuously enhancing our transaction security policy so you can send notifications to multiple users, our users who are outside your Salesforce ecosystem but still within your security scope. Send it directly to Slack so that your notification has a higher outreach. We'll also continue enhancing DSPs so that you can not only block but even take more actions, like reset a a password, freeze a user, create a case, approval processes, etcetera. We're also enhancing threat detection side of event monitoring. We have a few different anomaly detections. Now these are detections which get generated as real time events whenever, there's anomaly in certain activity. We're introducing query anomaly, which is an enhanced version of API anomaly and report anomaly. We're also gonna be adding agent anomaly in the future where you can identify if there's any behavioral change or any anomaly in how your agents have been accessing data. We also have a lot more on the observability side. Trevor, do you wanna talk about those? Absolutely. And in the spirit of forward looking statements and a testament to road maps being living As of this morning, I need to share with you that the observability center, is being pushed back a little bit. We're hoping to get it out in November, but we're really, really excited about it. So, stay tuned for more details there. And we have a new event type called the road lock error event log file type. This is gonna be really helpful for understanding road lock errors on the platform. And then in the spring, we're gonna go GA with observability center, and and we're gonna ship a couple other features too, about general purpose observability on the core platform. So we'll have a a platform tracing beta and a new feature called telemetry relay that's going to enable an open telemetry push model to third party OTLP endpoints, like, and Datadog and, Dynatrace have, OTLP endpoints that we're going to preconfigure for you. And then we're also looking into shipping a new headless event monitoring skill, and looking to instrument platform metrics as well. So they can have near real time visibility into key metrics on the platform, like how many long running API requests do I have, how many, MCP requests are my agents executing in a in a minute. So really excited about those updates. And then towards the summer, we're gonna go GA with telemetry relay. We'll go beta beta with the headless skills, and that is a wrap for the observability side. Amazing. Thank you both so much. So we'll move into, q and a now. We did have a couple of questions come through. The first one is what are some real world use cases for observability? Yes. So with the observability and tracing app, we really targeted a few different key personas, and and one of them is actually a developer or a DevOps persona. And, as you implement various different, you know, custom MCP skills on on the platform, and, you know, they they might use Apex or Flows. And so the tracing is an outstanding tool for debugging and troubleshooting for developers. Additionally, it's really useful for understanding exactly what an agent did. So if you're a a a business team leader, like, maybe you lead a sales team and you wanna understand how your team is actually using data... Using agents to access, modify data, and things like that, You can take a look in the observability and tracing app to really understand everything that the agents are doing, and that's gonna help you kind of build trust in the agents. And then lastly, it's a fantastic auditing tool as well, and we're looking at making the app, really useful, specifically to spot CRUD operations so that you can quickly drill into, the exact CRUD operations that are happening, that that agents are responsible for. So... And and that's just just a few. There's a lot more, use cases. It's a fantastic technology. We're really excited about it. Amazing. Thank you. Another one here. For real time events like API events, is there a cost to storage? I can take that one. Thank you, Saima. No. There is no cost to storage for real time events like API events, report events, login events, or all the others that you saw in event manager in Salesforce setup. Amazing. Thank you. So this person is a longtime customer of event monitoring. Is there something that you would recommend them do immediately or as a first step to understanding how to monitor agents? Yeah. I can I can take that one? I think that, you know, creating the event log objects analytics, dashboard is a great starting point, because as I showed you, you can basically hone in on the exact, MCP invocations, that agents are are, executing on the platform and the API requests. And so I think that's a really good starting point. Yeah. And I would also like to add to that. I would also recommend that, you know, enabling API API events streaming and storage is also a great place. You can build transaction security policies to govern your agent activities and get more details on, you know, whether it's an agent making a direct API call or agent call... Making calls via hosted MCP. You can govern those activities as well. Amazing. Thank you. I think that's all the time that we have for today. So thank you, Trevor and Poruba, for your time today, and thank you everyone for tuning for tuning in and for submit... For submitting your questions as well. If we didn't get around to answering your questions, then, the Salesforce team will be reaching out to you afterwards. So do keep an eye out on your inbox. And as I mentioned in my introduction as well, we have recorded this session, so we will be also sharing that in the follow-up email along with the slides as well. Thanks, everyone. Have a good day. Bye.