How AI Is Redefining Corporate Security — Empower Conference 2026 (Zurich) [ENGLISH]

Okay, thank you for coming, everybody. I will try, you know, it's after lunch, so we are all a little bit, you know, siesta time, but I will try you don't fall asleep by explaining how AI is redefining corporate security. Just a little bit, you know, one second about who I am. I work as a cyber defense expert in iSolutions. And in case you want, this is a QR code. Feel free to scan it. It's not phishing, I promise. So here you can contact me, see what I've been doing outside my company. So in case you wanna have more questions after this talk or in case you need anything from my side, feel free to contact me there. So I wanna start by making you one question to everybody. It's like how would you define cyber defense in one word? Think about yourself, maybe somebody wants to say it. Okay, nobody. So for me, for me personally, I believe it's trust. Why? Because in the end, if you are protecting something, you need to be reliable to it and this person or company needs to have 100% trust in you, right? So moving forward with this definition, I would make— I want to make you another question. It's, who would you rather fly with? On the first side, we have this pilot. I don't know if you know this movie, maybe the younger people doesn't know them. It's Airplane, a really good movie, I recommend it. So as we can see, this pilot is surviving, let's say, right? He's sweating, he is really focused on the task, but he's definitely not supported by technology.

Why?

Because he has only headphones. He's under pressure, he's probably tired, and maybe it's not ideal. I don't know if— is anybody flying with this guy?

No. No?

Okay. And then we have the second pilot. We have this pilot is obviously full supported by technology. She's focused on the task as well, the same way, but she's not trying to survive. She's doing really well as far as you can see. Everything is calm. She is only acting when necessary. And this is the way everything should go. So which one are you picking? I guess the second one, right? Yeah, so in cybersecurity, what are threat actors doing or hackers? What are they doing? They are choosing the second one, which is the problem. Threat actors or hackers, they are using social engineering techniques every time more complex by using AI. I don't know if somebody has heard about North Korean hackers like swapping their faces with AI so they impersonate USA workers and they steal information. Maybe they are using voice impersonation to gather money from the victims and so on. So as you can see, threat actors have it very clear. They need automation, they need AI, they need to evolve. In the meantime, what are we doing? We stay in the same way, especially large companies. Large companies, big corporations, they follow the common SOC structure, Security Operations Center, which is a little bit boring. Why? Because on the first layer we have level 1 analysts or junior analysts that they basically perform a triage function. When a security incident triggers and we detect something, The level 1 analyst, their main task is to, okay, is this a real security incident? Is this something we need to analyze? If this is so, they will escalate it to another layer that I will explain in a minute. If the investigation is basic and it's something really easy, they handle it. But in the end, it's something very, and this is important, very repetitive. They do all the time the same, analyzing phishing, analyzing spam emails. I don't know if any of you have like the report button, report phishing.

Yeah.

So this generates a security incident that we will see in the demo. And normally this triage function is made by the level 1 analyst. If the incident becomes a little bit more serious, then we have the level 2 analysts. They are in charge of incident response. They are in charge of analyzing the thing, right? If the security incident is serious, then they start the investigation, they apply remediations, containment actions, everything that is needed. And obviously they are a little bit more senior than the previous ones, right? And on the top level, we have the level 3 analysts, the more senior and the more technical people in the team, which are in charge of developing new processes, designing new detections, such as detection engineering, for example. They are in charge of review the investigation performed by the layers below, in case there is any mistake that we will see in the following slides. And they are in charge of the most complex investigations, right? And this is the structure. And here I see an issue. Why? Because every time you are doing the same thing. You're doing the same over and over and over again, especially the first layer. I mean, some people here can relate, especially security analysts. So doing the same thing over and over again is not good. Why? Because this leads you to some mistake makers. On the human side, we have, you know, high false positive ratios. What is this? So imagine you are dealing with the same false alert every day. Maybe, I don't know, a cloud administrator is performing some tasks and these tasks generate the security incident and this analyst is like, okay, this is false alarm, this is false alarm. Then we have the routine as well, doing all the time the same incident. I'm always analyzing phishing emails, so I'm tired of it, right? We have alert flood as well, which is imagine you get 500 security incidents at the same time. This is definitely not good. Something is happening, right? And also we have human errors and personal situations that lead that the analysts make mistakes. I mean, we are people too, right? So yeah, so we sometimes we fail and these are the human side ones. On the other hand, we have the tech side mistake makers that are especially related to all automations we have set in place that I will speak in the next slides. We have no context between third-party solutions, so every solution is like doing his way, but they are not like putting everything together about the security incident, so they don't have like a 360 view of the security incident. And for the same reason, we have API calls depending on third parties. And finally, especially for multi-tenant environments, maybe MSSPs maybe security operation services with different customers. This has no scalability at all because the more customers you have, the more analysts you need. And obviously this is not efficient. This is not the best performance, right? So you end up by having maybe 1,000 analysts. This is not doable at all. So focusing on the human side ones, Let me explain you what is the analyst fatigue. I don't know if you have seen The Simpsons. I don't know if you have seen this chapter, but basically Bart is doing the same task over and over and over again. And once the magical fish appears and the fish tells, okay, I grant you one wish if you save me, what will Bart do? Do the same thing over and over again. And this happens with security analysts as well, and I've seen that. In previous companies, not in 91. So imagine you are dealing with the same false alert every day. So once you have a real security incident about this, you will close it as false alert because this is what you have been told, this is what you have been doing all your work career, right? And this is not good. And also we have another kind of analyst fatigue that I've talked already about it and it's by fluke. Imagine now you need to find the true positive between all the false alerts. So it's not easy to find, right? It's really difficult because if you need to deal with all the noise, then focusing on— have you done it? Have you seen it? So focusing on what matters is really difficult, right? Because again, we are humans and we are not good into detecting anomalous patterns. So this generates something that is worse than a security incident. It's a security incident when your analyst is telling you that everything is fine. And obviously this is an issue, right? Because you want to build trust with your customer or with the thing you are protecting, right? So right now we have the following context. Right now we have threat actors powered by AI and automations and using technology. And on the other hand, we have like the common thing. We have security analysts that deal with old technology, that deal with repetitive tasks and focus on the routine and basically not doing the thing they want to do, right? Especially the level ones. So now, more than focusing on the problem, we will focus on the answer, okay, on how to fix this situation. How can we fix it? So basically doing the thing around. Let's improve our security analysts. Let's overpower them so they can use new technology. They grow themselves as security analysts as well. And this way they can piece the threat actors. Okay, so the first thing we need to do to solve this situation is to use a new SOG structure. We need to tweak it a little bit. On the base of the pyramid, we will have, and this is important, we will have level 1s as previously. We are not getting rid of them, and we will also add some automation by AI, by another thing. They will work together into the triage and the basic analysis and repetitive tasks. This way, level 1 analysts have more time to improve themselves, to learn from the level 2 analysts and help them as well. So level 2 analysts, the same way, we have more free time because they are being helped by level 1s. And they will do the same way with level 3s. This way we don't have like the level 1, level 2, level 3 structure, but we have a more horizontal structure where everybody works together and everybody learns from each other. And everything is based on the first layer, which is basically AI. So there is no boring tasks, there is no repetitive tasks, And the security analysts can focus on what matters and the time that they have free they can learn from each other. Okay, so this is a new structure. How do we automate it? Right now large companies have this way to automate stuff and I mean it's good, it's not bad. I'm not complaining about it. I like it in fact. Because why? First of all, the API connections between third-party solutions like, I don't know, maybe, do you know VirusTotal, URLScan, reputational engines, something like that? So what we do is gather the indicators of compromise of the incident, then we throw them away to the API third-party services. And this way we have automatic IP analyzers, we have automatic URL analyzers, and so on. And this is really good. You don't need to do that manually anymore. So these kind of solutions are fast and predictable. They are obviously easy to audit because you have all the traces in the communication. They have high accuracy because in the end you are depending on a third party that is doing their job, so it's fine. Low operational cost because in the end you are analyzing tons of indicators of compromise without having to pay for each one of them. Obviously, this is excellent for repetitive processes, right? Because in the end, if you are analyzing any IOC of an incident, then you need to do the same over and over again. And therefore, you have low risk of error because you are relying on a third party, right? And obviously, it's deterministic. That will be the difference between this solution and AI. But this is not enough because in the end, are we understanding the incident this way? I don't believe so. Why? Because we are not understanding if the incident is a phishing, if the incident is about malware, if it's ransomware. We don't know. We just throw indicators of compromise to the solution and we obtain results, and we don't understand them. The security analyst does. So for this reason, we need to add a second layer of automation based on AI. Which reduces the analyst fatigue. It's in terms of analysis of the logs of the information is faster than humans, understands, and this is very important, understands the context of the incident. It knows what is about the incident, has a high accuracy, especially for the newest LLMs. Obviously, if you are using an old model, you will find some issues, but in the newest models, it's really easy to find suspicious activity over sign-in logs, for example. Adapts to unfamiliar use cases in case you have new ways of attacking. So maybe threat actors are using different types of attack towards an account, and therefore you don't need to use different agents. You can use the same one for analyzing the sign-in logs, for example. Spot anomalous patterns, obviously has a low maintenance because in the end you need to maintain only the platform and the infrastructure and the prompt in case you want to tweak something. Handles large volumes of data and it's excellent for natural language analysis and contextual decision-making because it understands what is happening so it can act accordingly to what you need. So are we choosing the first one? Or are we choosing the second one? What do you think? Maybe it's not about choosing, right? Maybe it's about combination of both automations, right? Maybe we can use this kind of automation when we need it, and then when we need to analyze contextual information about the incident, we can use the second one, right? But there is another issue. I mean, it's not that easy. And this is the question I want to make. Do we trust AI at this moment? Because in the end, when a security incident happens, we are dealing with sensitive data, confidential information, confidential files, maybe personal information about your users in sensitive scenarios during a security incident, right? So are we relying 100% on the AI? Which AI? What solution do we choose? Shall we use ChatGPT? Shall we use Copilot? Shall we use DeepSeek? Maybe Swiss banks are not happy about choosing DeepSeek, right? So we need to think about this as well. Every model inside the solution has their own pros and cons. We have models that are more powerful but more expensive and we have cheaper models that are maybe what we need, but maybe they are not good enough. So we need to find the line. And also, these solutions are training with our data because in the end, if you are dealing with confidential files and you are submitting information to the AI, you need to be sure that this information is not being used to train the AI. So these are questions that You need to answer. In my case, in our case, we believe the best solution is Azure AI for the reason that the information doesn't go out the tenant in the cloud. So you can execute automations based on AI in the cloud. You are sure Microsoft explains that there is no data leaks and they are not using your data to train their models. So only for this reason and also you can choose between different models in Azure Foundry. For this reason, I believe the best solution for AI automation could be Microsoft Foundry. We know why to do it, we know where to do it, we know when to do it now. we need to know how to do it, right? How do we build the thing actually? So this is like on a very, very high level how we are going to do it. But in the end, we are relying on Azure as a cloud environment to contain all the security infrastructure and the security AI analysis and automations. And this is very important for the reason I said before. The data doesn't go outside the tenant. So you are sure that all the information is contained within the tenant and therefore the information is safe. On the second layer, we will rely on Microsoft Sentinel as a SOAR solution, Security Orchestration and Response. In Sentinel, what we're gonna do is trigger the security incidents, merge all the solutions we have for detection. Also, we will document security incidents there if necessary, and we will execute automation rules, and we will trigger the automation itself. Secondly, we are using Microsoft Foundry as the AI provider to our automations because of the same reason. It's contained within the same tenant. It also provides API call activity. So you can choose between models, you can choose agentic AI if you need it for different security incidents. So the best solution in my opinion. And then we are relying on Microsoft Defender for detection and some containment actions, especially in Defender for Endpoint and Defender for O365, for example, right? And below this layer, We will rely on, and these 2 are in my opinion the most important ones, we are relying on Logic Apps that will be the ones who orchestrate the thing and the Azure Functions that have computational power. And how they will communicate between each other? They will communicate between API calls. So again, and this is like the, I would say, One of the most important things in the talk, no data is coming outside the cloud. There is no chances of threat actors intercepting activity, intercepting API calls, like trying to steal confidential files if you are analyzing them. So this way you are fully secured and fully sure that no information is being leaked while a security investigation is going on. Okay, so now let's focus in what these two solutions do. Logic Apps are in charge of orchestration, the automation. So by executing automation rules in Sentinel, they will call the Logic App, and the Logic App will be in charge of deciding what will happen. It's low-code, so More or less everybody can understand it. I'm really bad at developing, so even me can use it. It's really easy, to be honest. And to communicate between third parties and other solutions that are outside, we can use Graph and REST API calls. Like for example, to communicate with VirusTotal, with abuse IP database, whatever. Also, it will be in charge of approval requests, communication, for example, phishing notifications, Team messages, whatever you need, and it will handle the conditional response logic. In case, I don't know, in case the we will see in the demo. In case the user has clicked in a phishing email, then perform these actions. In case the user didn't click, perform other actions. In case we have dealing about one customer, act this way. If we are dealing with a different customer, act another way. So obviously for a multi-tenant structure, this is very important, right? Additionally, it will be in charge of the incident enrichment where we will help security analysts into completing the incident without their need, in fact. So good. Investigation procedures such as finding logs, hunting activity, perform KQL queries, sign-in analysis, whatever. And this is also important, containment and remediation. Through API calls to Graph API, they can be in charge of resetting passwords, revoke sessions, disabling users, and so on. On the other hand, we have the Azure Function Apps. That will be in charge of data processing, data parsing and normalization. They will be in charge also in heavy computation tasks because they are being in— you need to develop them by coding. So this way you can use Python or whatever you need. Maybe you need to use third-party libraries such as Pandas, for example. So you can use them for that. You can build reusable microservices with them. as we will see in the demo, and they are in charge of threat intel enrichment. So now I will go with the demo. Give me one second because I have everything open already. So the demo is starting with this phishing email. As you will see, Don't try to send an email to these accounts. They are not being listened. So this phishing email, maybe, I don't know if you can read it in the last lines, but what it says is basically you have won the lottery. Obviously, this is fake, right? And it contains a link to my blog. And this is the phishing email basically. It's really easy because it's a test. Okay, so let me open the link itself. You will find it here. It goes to— oh, sorry, it's in Spanish. Let me switch it to English. So it's a sign-in form where no data is stored. So basically, we have clicked in the phishing email and We have worked on that. So what happens here? The user has clicked in the phishing email and has also reported the email as phishing. And we receive this, which is basically as Microsoft Defender for Office 365 gives you when you report a phishing email. Every time you click on report phishing email, we receive this. And what is this? This is basically email metadata with the email sample above, so we can have the evidence to analyze it. So let me switch to the incident. So this is the incident. It triggers an incident where, let me go to the first comments. Here we have some automatic comments like incident was created. Maybe you don't see it, I will zoom in in a second. So we have more metadata here. I won't go into this because I'm not teaching you how to analyze it right now. But the important thing here, I don't know if you will see it, if not I will explain it to you. is that one automation rule was run. And this automation rule is in charge that every time a security incident triggers, it takes the incident and it forwards it to a Logic App that I mentioned before, okay? I will explain it in a minute. Let me grab my mouse. So here, the playbook, which is like the automation, changes the status of the incident from new to active already and assigns the incident to the analyst automation bot. So remember, this is very important. The incident has not been handled by a security analyst yet. In this case, if we scroll up, we will see the comment in Sentinel performed by the automation. And as we can see, the automation provides automatically the email data, the sender, the recipient, the subject of the email. The verdict, we can see classification, phishing, phishing probability 95%, and also provides information about the email, not only the indicators of compromise, but the context of the email, the email body. So we can see the key evidence of the phishing email is that classic lottery scam, says the AI, unsolicited claim of you have won the lottery with a financial lure. A request to submit your data, and after this attaches more more evidences such as free webmail senders gmail.com right after that it analyzes the sender sender analysis we have an analysis of spoofing records DKAM so DMARC after this analyzes the URL and the domain of the sender, also analyzes the link here, which is VirusTotal result not available, but it provides— it was not scanned by VirusTotal, luckily for me. So it analyzes also the sender IP addresses and performs a second URL analysis. Additionally, analyzes the attachment. In this case, it doesn't have any attachment, so It just reports that, and in the end, it gives final recommendations, action to quarantine the email, and also the phishing probability again. So the security analyst doesn't even need to open the email anymore and read the email. Just by automatically done, attached to the incident before any security analyst handles the incident, we have an automatic report not only about the indicators of compromise of the email, But the context itself, what is the email asking for, right? After this, you know, it has detected it's phishing, right? The AI knows it's a phishing email. Shall we do something else? Of course. What if— well, obviously it adds credential phish as tag to the case. And then what it does is looks if somebody has clicked. in the phishing email, right? And well, we have findings. We have 2 clicks executed by our user John Doe, and we have the time of the click, the URL of the click, again, the chances the email to be phishing just in case. And since we detected a click in a phishing email, changes the severity of the incident from low, I believe, to high. So now we have potentially a user compromised, right? And also what it does, performs a password reset. Once we will see here. So it confirms that the password reset was performed successfully after this action and provides to the security analyst the temporary password. Because I don't know if you know, if you reset the password, it's only temporary. The user needs to reset it again. So it provides to the security analyst the temporary password, which in this case is temporary password, obviously. So now it's okay, we know that the user clicked, we made a password reset, but did somebody enter in the account actually? Because if you click in a phishing email and perhaps you enter your credentials in the phishing, you maybe have somebody inside your account, right? So this is the next thing to do by AI. It performs an automatic sign-in analysis of the user account for the activity in the last 15 days. In this case, I must admit we wanted to do another thing, but the AI was so good that since we executed the same sign-in attempts by using Tor connections and so on, it got used to it and detected that it was a false positive. So in fact, I was trying to trigger a more complex incident and the AI didn't let me because it was analyzing it was me. So yeah, yeah, I promise, until 15 minutes ago. So the AI has detected, I mean, she's focused on Switzerland, Spain, and Germany. And despite she's finding key anomalous successes from the Tor connection, finally she concludes that the compromise probability is 0% because we have been trying to do the same activity over and over again in the test. So we don't need to test that much because it will fail. So it concluded that there was no chances of user compromise. Therefore, it didn't perform the revoke of the session. So here it says the user, despite clicking, has no sign-ins of compromise in the account. Probability of compromise, 0%. If the probability of compromise would be over 50%, I think I stated, it would perform a revoke of the session plus the password reset before. Therefore, we are sure that if there was somebody in the account, It's out. Reminder, no security analyst touched the incident yet. So now we have a security incident when somebody has a password reset already. We have a victim. There is no need to revoke the session. So it's pretty concise. I mean, it's focused on— it doesn't perform like a cannonball to disable the account, fire the user, shut down the laptop. No, it doesn't do that. And now we have a high severity incident. I don't know if you can see it. Let me show it to you here. Here we have a high severity incident and unassigned because the automation is done. So I'm done. I unassigned the incident and I set it as new for the security analyst to focus on what matters. So now the security analyst, the level 1, for example, will would come into the incident, okay, these actions are correct, these actions are actually good, so then we are done. If there is something missing, the same way as your pilots in the airplanes, right? The pilot only does the takeoff and the landing, so the security analyst does the same. Checks everything is all right. If everything is all right, I don't need to do anything else, I close the incident. So let me show you. I believe this is everything. Yeah, we can see here an assign of incidents. So let me share with you another thing because this is not everything. Here we will have an automatic message. Yeah, sent by the cyber defense bot that. Do you remember the user reported the phishing as well? The email as phishing, right? So the user needs to know if the email was actually phishing or not. So this is an automatic message sent to the user confirming that yes, the email you reported is a phishing attempt. So be careful. But our user was not careful. So since our user was not careful and clicked, sadly, he had to receive. Password reset notification where the cyber defense bot tells, "Hey, for this email we have detected you clicked. You clicked on this date for this subject, this sender." So these are the actions that we we we took. And yeah, we revoked the session, but in reality we didn't. So I I didn't want to send more emails. So yeah, we reset your account. So please do not attempt to log in using your previous account as it is no longer valid. Somebody will be Contacting you to give you the new password, the temporary password. Do you remember? So who is going to tell him the new password? The single point of contact, right? As a security analyst, you can you must not speak with all the users because in the end, it's it's maybe some of them are away, some of them are not available for some reason. So you need a single point of contact to send this email. and tell them, okay, be sure or be aware that your user, user John Doe, has been compromised due to a security incident with ID, in this case, 75. So a security analyst— let me scroll a little bit down. For security reasons, the temporary password will not be shared via email, obviously. this person should be in charge to be aware or be sure that the user changes the password. So obviously, also the automation is in charge of notifying the people that has been compromised, notifying the people involved in the security incident. Maybe we don't need an email, we need a Teams message only, right? Depends on the workflow. So let me end by Showing you for a second a little bit of the thing behind, right? Let me ignore the fails. This is because it's a test tenant and when we reset the user's password, it resets all the passwords. So no worries. So here we have more or less the structure of the Logic App. I won't go into details because it's quite technical, but I will focus in a couple of blocks. The first block is the security incident where everything comes from. So it provides the information, the artifacts, the accounts involved, everything. And from this, we are starting the automation. So first of all, we assign the incident to ourselves, and we need to add a delay. Why? Because the Logic App sometimes is that fast to execute that sometimes we don't have even the logs collected. So it's that fast that sometimes it's like, okay, hold on a second, let's wait until everything is done and then we act. Once we add this delay, we add some variables there. And in here, we extract the email metadata by executing a KQL query. I won't go into details, but you will. What I need you to understand here is basically from the incident we get the recipient, the subject, the sender. So we extract the information we need. From here, we extract the email, export the email, report the phishing itself. But there is one issue: the email is exported in base64, which is a kilometric string. So for this reason, we need to send this kilometric Base64 string to our function app through an HTTP call to decode this Base64, gather only the importation that we need, and then work with that. And this is done in the green block right here. And once we know that We have only the information we need, the information about the security incident we need. We send this to an agent, to an AI agent based on Azure AI. We will see here below. Let me scroll because this is a long prompt, definitely. It will finish.

Yeah.

So we see it here, Azure OpenAI. We can choose the agentic model to execute. And if we scroll up again, we will see that we provide the agent the information we need. We tell them, analyze the phishing email. We provide the subject, the sender, the recipient. We provide the spoofing records. We provide as well the email body, which is something we used to not do. And we provide the attachments as well. And this agent is in charge of analyzing actually the email by using Azure AI. After this, it comments, adds a comment to the incident. You have seen this before, that it's the AI phishing analysis based on the agent response. And sets a phishing probability here and looks for clicks.

Okay.

And we will see here that if there are clicks, if there are clicks, this is a condition. If there are clicks, so quantity of clicks is different to 0, and the phishing probability is above 50%, because we don't want to reset the password for spam, right? For clicking a spam. So in this case, we are doing the true. way, which is set severity to high and perform the password reset through an API call to Graph API. And I will move a little bit forward. I don't want to go into deeper technical details. Oh, I went really deep there. Sorry. So here, finally, we are analyzing— we are gathering the sign-in logs from the user. We parse them, we send them to the other agent because we have a different agent here with different prompt, with different information. And it analyzes the same way that the other agent, it analyzes the sign-ins of the user. And finally, it provides the sign-in analysis. And you can see all the responses performed by the agent. I didn't add anything there. Finally, If the user is compromised, you remember the phishing— no, compromised probability, sorry. In our case, it was false because the user was not compromised. So we update the incident telling, hey, the user was not compromised, no need to revoke the sessions, right? In the other case, if this was true, we revoke the user sessions. You will see here and add a different comment, session revoked for the user, whatever. Okay. And finally, we send the notification emails if we are speaking about an email, right? So we send a notification, send password reset notification, send email to Spock. And finally, we assign— we unassign the incident so an analyst can assign it. If you wanna see a little bit, a glance of the function app, we have it here. And you will see it's totally a different thing. It's based on coding, so we have more powerful tools here than not only the, you know, well-looking Logic Apps. But the good thing here is that we can use different libraries. We can execute Python scripts. In this case, this was programmed in Python, so we can import different libraries. This is something you cannot do in Logic Apps. So the communication with them is this way, through API calls. And as I said, you use Logic Apps for orchestration, automation, and then you use Function Apps to code in powerful computational services. So yeah, moving forward, this was the live, well, live demo, semi-live demo. So this is the way me and my team, Do these in iSolutions. So yeah, if you have any questions, insights, thank you. I have actually a question. Yeah.

So because so first of all, thank you very much.

Thank you.

It was very interesting for me. And I'm really into how AI and the use of agents and orchestration can improve the security. But my concern is one of the most usual attack attempts in the last years is using orchestration. So it would not be It would be crazy to think that in the future one of the most common attack attempts would be agent impersonation.

Could be.

So to try to train an agent to impersonate a really working agent, that will impact the whole orchestration. Like, for example, in a security scenario like this. So it's really interesting, but we need to take really care about the security in front of all those engines and that orchestration to avoid those kinds of attacks? Because I really think that's something coming.

Yeah, you're completely right. I mean, one of the steps in security investigations is to understand the context of the incident. An incident without context doesn't— is not really easy to analyze. So what we try to do is In case, for example, somebody is impersonating a user, we try to look for past evidence to perform a baseline, let's say. What is the usual communication between 2 users, maybe the sender, the recipient? Are they involved? Is this user— this user belongs to a company that is business-related to ours? So this is something you need to understand. And yeah, of course, If you use agents to impersonate other users, I mean, I'm expecting this to increase in the future, of course, but this is a kind of attack we are already used to see.

Not just the agent impersonating a user, but an agent impersonating another agent.

Another agent, yeah.

Because that would be really a huge impact in such a scenario.

Yeah, exactly.

why it's very important that no data is leaked outside the tenant, right? Because in the end, if no communication can be intercepted, it's really hard for the threat actors to like gather information through OSINT techniques, for example, or to package gathering to try to impersonate another agent. So that's, for example, HTTP communication, right? So that's why it's very important to have everything under the same environment, let's say. and no information is leaked. Any question? Yeah.

Thanks for the presentation, Cristian. It goes a bit on the way, but what about AI? Because the attack surface is no longer just your corporate, your email, any agent you deploy, for example, or any tool that you access is your attack vector, like an external RCP.

Yeah, totally.

How do you put that in Sentinel? How do you protect or shield that?

So yeah, good question actually. Yeah, so we protect that through roles and permissions in the Logic App, which is the one that is in charge of calling the agent. Okay, the agents are only deployed in the Logic App. I mean, you could do it through Azure Foundry and Perform HTTP calls to the API you create there. But in my opinion, it's better to have the agent only in the Logic App, then you protect him through managed identities and only you give them the necessary permissions. Also, the agent is not able to execute actions in this example. In other examples, you are able to execute actions, but in this example, the agent is only in charge of investigating, analyzing. The actions are performed based only in the agent response and the probabilities it provides. So that's, yeah, this is something we need to work. But yeah, in the end, we protect that through managed identities, try to give only the necessary permissions to the Logic App, and obviously only call the Logic App whenever it's necessary and not call the same Logic App for any incident, just for the ones we need.

Let me summarize that. Basically, it's using the surface of Type Response As much as possible.

Yeah, yeah. In the end, if you had Azure Foundry with HTTP calls, you could use this model to attack. But in the end, if you have this agent only in the Logic App setup, then you need to have access to the Logic App and you need to be, you know, have some certain level of privilege. So yeah. Did I answer your— Yeah, it was. Okay, then I believe we're done. Thank you very much.