The fastest path to safe AI adoption: Programmable SASE for the future | Immerse Stockholm 2026

All right. Hello everyone. My name is Anukica. I'm so excited to be here with all of you today. And I'd love to start with a question. Let's put your hand up if you are already using AI for your daily workflows on a daily basis. You're using AI to make yourself more productive. Almost everybody in the room. Okay. Now, keep your hands up if you believe that. Maybe not you. You don't have to out yourself but if you believe that some people in your company are probably using AI applications that they should not be also everybody in the room. Okay. So statistically you are correct about this. The vast majority of organizations are seeing adoption of AI way faster than IT teams or security teams have been able to keep up with it. 85% of organizations adopting them before that can happen. 75% of people saying, "Yep, I'm sending data I shouldn't be to AI applications." And then this is actually already resulting in serious security breaches. So, one in five organizations saw some kind of security breach related to shadow AI use just last year. And these are having serious consequences. It is already showing up in the news cases where people are uploading unapproved company data to public applications. And this is only happening more and at a higher speed. And every single customer that I talk to is concerned about this problem. Very few of them have a solution in place today to address it. And the problems that you were solving a week ago with securing AI usage look different than they do now. And so in addition to speed of uh how fast all of this is changing, one of the things that we hear from customers is getting in their way is the complexity of their existing stack. When we talk to customers and whiteboard out the solution that they have in place today, what we end up with in many cases is a picture that looks a lot like this. They've put in place over time a series of solutions that were individually designed to solve particular problems in their corporate IT or security stack, right? I need to grant access for my users into corporate applications. So, I'll put in a VPN or maybe a zero trust network access. I need to um look at the amount of traffic that's going out to the public internet. So I'll introduce a secure web gateway maybe traditionally as an appliance maybe today now as a cloud solution. Some customers that I talked to are still managing both. They introduced tools like CASBY and DLP to help with cloud security and data loss. And they introduced SDWAN to help optimize traffic headed out from um individual branch locations or retail stores. And if you zoom into any of these individual solutions, they make a lot of sense, right? They solve that point problem really well. But when you zoom out and look at this set of solutions altogether, plus now you layer on top of it how quickly the landscape of AI is accelerating, what's become clear is that this architecture, this sort of band-aid architecture created over time does not work for customers anymore. The industry came up with this concept of sassy a few years ago to address this specific problem. Right? The idea was security and networking. You combine them. You deliver these services from a a distributed edge and you shift a lot of the management of all these things. Instead of patching individual hardware devices and centralizing all of your traffic into a single hub, you put it in a distributed cloud platform. But and I'll give uh the industry analysts who came up with this concept a little bit of credit for this. They were a little ahead of their time. At the time when Sassy was coined as a concept, there was not really any provider on the market, including Cloudflare, that had all of the different pieces of this solution. But people saw the advantages of this architecture. They saw the um the demand from the market from customers who were dealing with that kind of mess of band-aid solutions we talked about before. And so they responded and came very quickly to market with uh um uh essentially platforms that were created to solve sassy um capabilities and issues. But what really happened is though we sort of lost the plot along the way. Instead of being delivered as a unified platform, what we see from a lot of solutions in the market right now is uh essentially some version of the last slide that I showed you but with maybe like a unified control plane or a dashboard on top because companies started either from an SDWAN perspective or as a secure web gateway or as a zero trust network access provider and then acquired other solutions or built separate solutions on different networks on different infrastructure and then stitched them together And so what we uh learned from from watching this happen in the market at Cloudflare, we had a little bit of a second mover advantage in this scenario is that we needed to architect this fundamentally differently. And funnily enough, this is sort of the the original vision of Sassy is to like have these key components as part of the architecture. Those components are that capabilities need to run everywhere. You heard already about our globally distributed network. Every single thing that we offer that you'll hear about throughout the rest of the day-to-day runs on every single server around the world, including the full Sassy platform. And that's incredibly important for user experience and means that you have a consistent experience as a user regardless of where you are. Not true with platforms that maybe have different solutions for different parts of the portfolio, right? A separate SDWAN from the zero trust um network access for instance. From a data plane perspective, it's also important that you have consistency regardless of how you are connecting to Cloudflare. So let's say for an end user, you install a client on a device. For a branch, you might use a lightweight appliance to connect it to our network. For a data center, you might use a direct connection. For a cloud provider, maybe you're connecting with their native transit gateway or the components. But regardless of how that traffic is getting to the closest cloud location, what you need is a unified control plane. uh for for all of that uh data and you need a control excuse me you need a unified policy set so the security controls that are applied across that traffic regardless of where they come from look the same and then this last piece is the control plane right one dashboard one API one Terraform provider and then now also one MCP server that is available for you to use to manage and control and configure all of this stuff and so these are the foundational principles that we use to architect our solution again watching from sort of the the mistakes that the providers that were earlier to the market made and trying to assemble it quickly by putting together these disparate components. So those are the architecture decisions um that we have made. How does this actually uh translate into helping provide for you a fast path to safe AI adoption? Well, our argument is that you don't actually need a different security paradigm for this set of problems. We are seeing right now as tends to happen when there's a new technology that evolves a whole new crop of security vendors that are out there that are addressing just specifically issues like shadow AI, MCP server proliferation. And you could try and solve those problems in the same way that we just saw sort of the band-aid slide with solving all kinds of other specific point security problems, right? Introducing a new tool just for secure AI usage. Our argument is that that doesn't make sense and what you should do instead is have a platform a sassy platform and then a set of security principles. We argue those should be zero trust principles that just extend to cover AI specific use cases as well. And we think there's two classes of problems that are important to be solving right now in this space. One is safe AI adoption for your end users. How do you make it easier, safer, provide guardrails for all of you and all of your colleagues to continue using the tools that you want to every day to make yourself more productive to be able to enable people who traditionally could not build on their own to do so now. And then this next piece is for agent traffic, right? Um making sure that you can govern, manage, view, control the actions that agents are taking within your organization. So what does this look like concretely? Let's start with the securing the workforce use of Gen AI. The first step here is just getting visibility. How many of you believe today that you have complete visibility into all of the AI applications that your users are using in your organization? One person. All right. You discovered some magic that no one else I talked to has been able to figure out yet because generally the answer here is like no. We we don't know what people are using and for um um for what applications. So Cloudflare can help with this. We have sha uh shadow AI and shadow MCP visibility tools starting with things like analytics and logs. And then we also try and make this easier for you by doing stuff like uh adding confidence scores for specific AI applications. We take in a whole bunch of different signals to help you get an automatically generated level of confidence for the different apps that your employees are already using. So those are some set is sort of generic to all SAS applications basic security checks on what the app is doing. But then there's also signals that are specific to AI applications, including stuff like the presence of a model card, which is a set of um publicly available information about AI models that includes things like the system dependencies, the limitations of the model. And so this is just one example of a signal that we use to help provide a confidence score or a risk score for AI ops and and models specifically. If you've got a really solid available model card, stronger confidence. if there's one that isn't there, it's incomplete or it has red flags in it, that'll be lower. And so, of course, you have the ability to customize the um the the types of access that you want to give for your employees, and we'll talk more about that in a second. But if you're just like, look, I have no visibility around this today at all, and I want to start getting some control or understand how widespread or bad the problem is, we make that really easy for you with a whole bunch of these built-in defaults, including things like the AI app uh confidence scoring. Okay, so once you have better visibility into what is going on in your organization with Shadow AI, you can start controlling access to these applications. And again, the good news here is that the same principles of zero trust. So things like authenticating and authorizing every single request, granting access to individuals based on identity and to single applications instead of entire networks to allow lateral movement. All of those principles still apply and you have capabilities today within the Cloudflare platform in the same policy builder that you would use to grant employee access to other kinds of applications um for AI specific apps. If you aren't already using Cloudflare for zero trust network access, no worries. We are actually seeing a lot of adoption where customers are starting today with just these specific use cases and then they are expanding quickly to transition to our platform for other zero trust use cases for access to nonAI apps. Um but what they found is that there's just limitations of the platforms that they have in place either traditional VPNs or firstg zero trust providers and they can't get the visibility and control and granularity of access that they want in their current provider. So they're starting by solving the shadow AI problem with Cloudflare and then adopting the the broader platform over time. All right. So once you have the visibility and you put some access controls in place, then you can get more fine grain with it by governing exactly what data is allowed to flow in and out of your network and your organization and essentially how people are able and allowed specifically to use these applications. So you can do things like isolate AI applications. You can automatically load LLMs, for instance, in an isolated browser and control things like the ability to upload or download company data. You can restrict the actions that users can take within AI applications. And then you can also do full logging and guard rails for AI prompts. So you can prevent for instance someone from accidentally uploading a whole bunch of uh secrets information to a public GitHub repository using a GitHub MCP server which is something that maybe in previous workflows if you're moving a little bit slower being more careful as a developer doing more by hand maybe you would capture that type of error but if you're moving very quickly using AI agents to write your code you might not catch and so it's helpful to be able to put these specific guardrails in place. Okay, so we've got the visibility, we've got the controlling the access to the AI applications, and then we've got the controls for data loss prevention. And this is really where we've invested in our cloud access security broker or CASBY and our uh data loss prevention or DLP tools that are part of our platform is on helping with these new and burgeoning use cases around uh um controlling the data that is shared specifically with AI ops. These same set of protections also apply to model context protocol or MCP which has seen crazy fast adoption in the past year. For comparison, this is how long it took for HTTP to become industry standard. We reached kind of consensus in the market, right around five years. For comparison, here's MCP. The adoption curve has been crazy. It reached industry consensus within just six months. And this is incredible news for developers because it means that they are able to build faster than ever. Right? There is an MCP server, sometimes uh sort of officially blessed by a provider, sometimes just homegrown and vibe coded by a developer, but available for pretty much every public API that you could think of. You can search and find one that someone's created and posted somewhere. So awesome for devs, but very very scary for security teams because there is now a proliferation not just of shadow IT, not just of shadow AI, but specifically of shadow MCP servers. people that are finding these available on the public internet. They're downloading them and they're running those shadow MCP servers locally on their own machines. And in this case, as a security person or an IT person, you have very visibility into what is going on. And this is essentially a reinstatement of like an early 2000s era security problem, right? Someone could potentially download an MCP server that includes straight up malware and be running it on their local machine um without knowing and without you having any ability to to view or control it. So, Cloudflare is the only platform that has a holistic solution to this problem to the shadow MCP problem and we think that the architecture should look something like this. There's three main parts to it. The first one is the ability to host MCP servers remotely on the Cloudflare edge. This gives you more visibility and more control than if your developers are downloading them and running them locally on their own machines. And just like everything else that you host within Cloudflare, when you host an MCP server, it's available everywhere in the world. You don't have to worry about the locations, the redundancy, the capacity planning, none of that. It automatically scales and is available globally for you and your team of developers in seconds. So, host the MCP servers on Cloudflare. The second piece is setting up MCP server portals. This lets you aggregate trusted versions of MCP servers. both those ones that are hosted on Cloudflare like I just mentioned, but then also MCP servers that are hosted elsewhere, you can control how developers get access to those portals and then they can integrate it with whatever coding agent that they're using. And so if they're living every day in cloud or open code, they can set up their default uh gateway to point to the MCP portal that you have configured and then automatically get access to your trusted list. So think about it like a controlled app store of NCP portals which we've actually seen dramatically accelerate developer workflows because they suddenly have access if you can set this up and and grant them to it um to a whole bunch of blessed resources that they can use and so you don't have people doing duplicate work or using different versions of MCP servers that are hosted in different places on the internet that again might be unreliable or untrusted. So host the servers that you can on Cloudflare, use the MCP server portals um to aggregate and control them. And then you can add zerorust policies just like the ones that we talked about for users accessing applications to these MCP servers that are gated behind the portal. And then you can manage the actions that are allowed for developers and for coding agents that are interacting with each MCP server. I've said MCP serve probably as many times as is possible within a single presentation. So we'll move forward from here. But if there's one takeaway is that there's one single architecture right end to end and Cloudflare is the only platform that has this. It's part of our sassy platform. We think these controls make sense to live again in the same place. We are already controlling who can access what within your uh private network and within the public internet. Um and this is just an extension of those existing capabilities. Our goal overall with all of this stuff, the AI controls as well as the rest of the platform is to be undeniably absolutely the easiest platform to use. One proof point for that today is that we're the only sassy provider that has a free plan. And this matters to enterprises because there are millions and millions of users that are beating up our free plan every single day. It would be impossible for us to support that volume of free customers or customers that buy, you know, a limited set of seeds on a a credit card um with human support. And so we have to make the platform super easy to understand, use, troubleshoot, manage, configure. Our documentation has to be really solid and we have to have really good tools like our infrastructure as code providers and again the publicly available MCP server for managing all of this stuff um in order to serve essentially the masses and then that work that we've done into making it easy to use for everybody means that it is easy for you to use as an enterprise or as a cloudflare partner to manage on behalf of your customers. Um and this is our commitment is to continue being the easiest to use. Two examples of how we are doing this concretely beyond having the free plan is we have made it super easy for you to manage uh and and feel safe and secured with postquantum cryptography or PQC. Does anyone know the estimated date when computers will be able to break traditional encryption when we'll have postquantum computers that have that capability? Someone said 2030. Any other guesses? 2028. Yeah. So we thought it was going to be 2030ish. Of course, this is like an estimate from scientists that are working on quantum computers, right? Earlier this year, we heard that that deadline came in to 2029. And there is even speculation that it might be as soon as 2028. So this is a more urgent problem than we traditionally had thought, right? We thought we had years maybe as an industry to solve for PQC across our our um overall technology stack. But not only do we not have that amount of time, if you have sensitive data today in your organization, then you are at risk for harvest now and decrypt later style attacks where attackers, if they can infiltrate your information and get access to data that is currently encrypted, they might be able to just sit on it and then use it years into the future. And so this is super scary, but Cloudflare has your back. We have you covered. This is part of being the easiest to use Sassy platform is that if you're using Cloudflare, we already have end-to-end postquantum encryption in all of our Sassy capabilities. We're the only provider that has this today. And we are also going to be the first provider with end-to-end postquantum authentication. We have promised that that is going to be available as um uh by the beginning of 2028 and ideally earlier in our platform as well. And so this means that if you're a security person, you're worried about this set of problems. If you're using Cloudflare, it is already covered. If you have auditors, regulators that are asking, what's your plan for PQC? Again, Cloudflare's got your back. So, that's one way we're making it easy to use. And then the last thing I'll give you just as a quick teaser of what is coming up next um is the Cloudflare 1 stack. I mentioned we already have a publicly available MCP server that enables you to manage, deploy, troubleshoot, and configure anything that's available in the Cloudflare public API. And everything that we build is API first. So if you see a button or a toggle that exists in the dashboard, if you see some information that you can use um with the click of a mouse then you can also control that with API and then now as well via MCP. So Cloudflare 1 stack which is coming out in the next couple of weeks is a set of curated skill files and contexts that we're adding in addition to this MCP server to make it even easier for you to manage your Cloudflare 1 deployment with agents. And we keep hearing that this is super important for our partners because the entire ecosystem of uh of how IT teams work and manage their technology stack is changing. And so having blessed firstparty primitives like this stack of skill files that we're making available to all of you is super critical in managing your day-to-day work and making your jobs all simpler. So if you're interested in early access for this technology or if you want to learn more about anything else that I talked about today, come find me. I'll be around all day. Thank you so much for listening and I'm hand it back over to Tobias. Thanks a lot Anaker for a great presentation. So we have a couple of questions I picked. Uh the first one is about internal networks. So how is cloud for able to provide network and security to internal network of an organization? Will it remove the requirement for firewalls or the security measures that has been in place for years? Yeah, totally. So maybe I didn't make this explicit. If um if you have a source or destination of traffic that is connected to the Cloudflare network, all of our security tools work for both public facing and private applications. So for an end user, that might look like putting a client on their device. For an application within a cloud or a data center, that might mean connecting it with an IPSec tunnel, an interconnection, some kind of mechanism that enables us to put the private traffic inside of a tunnel to get it to Cloudflare. But then once your private traffic is connected to us, you have essentially access to think about it as like a big virtual private network mesh that is deployed across the entire Cloudflare network that enables end-to-end connectivity. So every single day we are seeing customers replace traditional connectivity methods and security methods. So VPNs, NLS circuits, uh SDWAN appliances, firewalls, intrusion detection systems. they're dramatically and radically simplifying that stack and moving all of those security tools to the cloud. Um, and again works for public traffic and p private traffic. And as the boundaries between those things continue to to blur, Cloudflare is the only platform that has the coverage for both of those pieces, right? The private stuff in Sassy and the public facing apps in our application services. Perfect. Thanks a lot. Second question is around MCPS. Are are you not adding an extra layer of latency time by introducing cloudfare zones between MCP clients and MCP providers? What if Cloudflare infrastructure is down? Yeah, good question. So, two parts. Um, first on latency, not that is measurable for the vast majority of use cases because uh like everything else on our network, we have built our infrastructure to be super super close to end users and applications, right? Just milliseconds away from the vast majority of the internet connected population. And so if you host an MCP server on Cloudflare's network instead of hosting it on uh like the developer's local machine, the experience from the developer perspective or from the coding agents perspective looks virtually the same, right? Maybe it is a couple of extra milliseconds at most. But actually in many cases, customers see that we're able to accelerate the traffic flow because once traffic is at our network from there to its destination, we are able to optimize the traffic flow, right? We send it either over our global backbone or we use signal from the 20% of the internet that runs through our network every day to choose the most optimal network paths. So if you just have a developer with an MCP server on a local machine and then they're connecting to um a remote application that they're developing with um then there is a potential for an improvement by sending the traffic through Cloudflare server compared to 100% local deployment. Right? I've got my MCP server. I've got my app completely on my machine. Again, maybe an extra couple milliseconds latency. Not enough to make a difference for the most most the vast majority of developer use cases and huge security benefits. What if Cloudflare's network goes down? Totally valid question for any SAS provider that you are working with, right? Um we have not had an incident that impacted the entire Cloudflare Cloudflare global network, knock on wood, in a very long time. But it is possible right with any service that you use including anything that you develop internally that there will be reliability and resiliency challenges and concerns. And so we um have a whole bunch of publicly available uh best practice reference architecture for what business continuity plans can look like if you're putting critical infrastructure behind Cloudflare and want to make sure that you have backup services available um break glass procedures available etc. so that if something were to happen, your um team can can keep working and their workflows are not disrupted. Perfect. Thanks a lot, Anukica. Awesome. Thank you.