Name: Exposing the 1 Recovery Gap Across 4 Google Workspace Tools
Uploaded: 2026-10-22T17:46:57.762Z
Duration: 45 min 8 s
Description: Exposing the 1 Recovery Gap Across 4 Google Workspace Tools

Transcript for "Exposing the 1 Recovery Gap Across 4 Google Workspace Tools": Okay. Thanks for coming, everybody. Welcome to, the first episode in the Rubrik series here, regarding protecting, various, SaaS applications. First one here is we're gonna be talking about exposing the one recovery gap across four Google Workspace tools. My name is Shane Donahue, and I am a, what's known as a platform level specialist here at Rubrik. I specialize in Google Workspace, have been doing so for over a decade at this point in various roles and and applications and services throughout the, the Google ecosystem there, all the way back from when it was, Google Apps. So if you know that one, that would probably date me a little bit there. That being said, wanna go ahead and hop into the agenda here, and we're gonna cover this in a couple of steps here. So first off, I'm gonna walk you through what Google offers you in the native tools for protection and recovery services. We're gonna talk about what's kinda changed in the ecosystem and the landscape across both kind of Google and just the global situation. We're gonna walk you through a scenario that we've actually seen happen here at Rubrik, kind of a a fallout element there, of a little bit of agent overuse and agentic overreach, in the situation that happened. And then how we're... How... Help you close the gap, what we offer here with the, for Google Workspace protection, and help you out with that. We're gonna walk through a demo on that one there. And then finally, we'll just talk through the, whole business, the next steps, and then, we'll wrap it up with a little bit of live q and a at the end here. Happy to submit questions throughout the whole session here, and we'll go ahead and work through that. So real world scenario. What are we looking at here when we're talking about things that have happened inside of, ecosystems across this? So, this is a situation where we hit an agentic overreach. Basically, a user with quite high level permissioning inside of Drive went ahead and attached, we'll just say, a tool like OpenClaw. They gave it a lot of access. They signed in. They checked off all the OAuth access there, and that tool was able to operate as that user, behaving as that user through those API actions. And it went through and just said, look. We're gonna go ahead and help clean things up. So it moved a bunch of files, changed sharing all our folders, deleted some calendar events, and, tidied up some group members that they had some ownership over. So what are we gonna look at with this when we're looking at what Google actually gives you in this sort of ecosystem? So credit where credit is due, Google is actually very strong. So coming from the standpoint of Google was built kind of on the cloud, for the cloud, by the cloud as it kinda turns out to be in the long run here, Google built a lot of security into that. So there's no kind of local executables. There's really restrictive APIs. There's a lot of good OAuth processes there. So Google is really good about blocking things at the door from before they happen or at least offering you the tools to do so. So talk about that a little bit. Google owns all the infrastructure, the availability, the default encryption is protected. Their key management system, if you ever can get a presentation on it, is really, really cool. And all your data is even sharded before it's encrypted, so it gets chopped up into little pieces and spread across the ecosystem. It's amazing data statics, for that and and how it can go ahead and pull all those files together and reassemble them right before your eyes in, like, sub millisecond performance. So it's a crazy, crazy ecosystem on security wise. And then Google is kind of answering the call that we need agents everywhere, but also AI accessibility and functions there. Whether it's kind of built in Gemini. So there's a lot of really good protections built into Gemini. Obviously, they would like you to kind of use the native or the built in tool sets as much as possible, because it offers kind of some of their security elements there. But there are OAuths available for a lot of different API access, and Google gives quite a lot of API accessibility, to an end user, if you so allow them to do so. So with that, we're gonna go ahead and switch to a demo. Okay. I'm gonna go ahead and start with just walking through the basics of kinda what you can use for data restoration. In this case, the first round for getting anything back that a user has deleted is actually on the end user themselves. It's the trash bin. So within something like a shared drive, I can go ahead and delete, a piece of data. It's gonna say it's gonna move it to the trash. It's gonna inherently... It's gonna put it there. It's gonna live there for about a month. So within a shared drive or an end user's specific drive, you can see I have the trash right here. It's in my shared drive. It's owned by the marketing shared drive, and it's there. This is gonna last thirty days. I can undo that as I see fit. So we can just say, look. We just hit restore. That file's right back. But if I went in there and hit the empty trash, that then queues that up for immediate purge. So that data is gonna go ahead and get wiped out of user view the moment I click the empty trash button. So that's not then recoverable by an end user. That's gonna need some higher level intervention there. Within calendar, we have the same kind of story. Taco Tuesday is no longer a thing, so we'll go ahead and delete that. But we can also, once again, move that right back... Right out of the trash or empty the trash to purge that data away from that. So, again, options for both sides of things. Bringing data back or expediting the active purge of that data off of Google systems. With that being said, we also have another element within the actual side of Drive for bringing data back that may have been changed or updated here. I'm gonna go back to my marketing drive, and I'm gonna go ahead and take a look at my team mission statement. Now this may have had some data corruption, some changes to it. I can usually go in and grab file information. And if I hit that, you can see here that I have a manage versions. A lot of people aren't aware of this particular panel because it's buried a couple layers deep, but I can go ahead and roll back to a previous version of this file right here. So this is available. I can go ahead and pull this file out and access that element there. So I have a little bit of a history from change that I can potentially use. Now this one's a little unique because I broke it because it's, I changed it from a, a doc x to a pages, so I can't quite roll back. But I can go ahead and download that, potentially reupload that. But then I still have to go fix all the permissions and all sort of stuff and put it back in the same place. So kind of example of where the version history can fall down a little bit, versus elements with, being able to restore. So this is kind of what we get from the end user side and probably the most common path to undoing an oopsie daisy within the Google tenant there. If I pivot here to a little bit more of an admin side here, talking to organizations about kind of recovery, risk, what they're gonna do to mitigate data loss, the first answer I often hear is, well, we have Google Vault, and that covers us. We're we're good. We have backups through that. Well, the first thing I wanna go ahead and point out here is is Google Vault isn't a backup system. It's an ediscovery and retention system. It's literally designed by lawyers for lawyers. So years and years ago, when Google started working, eating their own dog food, and using Google Workspace back in the time Google Apps themselves as their core email provider, internally, the lawyer said, hey. We need some way to manage all this ediscovery data. We need to be able to handle that. What came forth from that was Google Vault. So this is where we get into this. Now first one I wanna show off here is retention. So a lot of people will say, we're covered by Google Vault. It's there. It's installed. It's part of my license. I'm good. It doesn't help you if you never turned on retention. So right here, you'll see this is an out of the box configuration for Google Workspace. We haven't played with Google Vault in our particular demo tenant here at all. No default retention. Nothing's being protected past that. So when that data is deleted, it's deleted both here and out of Vault. We have no data that we can kinda come back from. So this is the first mistake a lot of people make is that they just never set it up. So that protection, even what it is, is not available. So you can set that, and you can walk through that there. The other side of this that a lot of people aren't aware of here is that if you delete a user account, the data stored in Vault for that user account is bound to that user account. So if I purge my own account, somebody else's account, etcetera, and it gets past the undelete period, which we can look at here in a second, that data is gone even from a legal and, ediscovery and archiving permission. If it was actively under a legal hold, Google would not allow you to delete that account. So kind of a watch point on that one there. But from this side of things, you can create a matter. We've got a basic legal hold that's set up. And then from within here, you can do some stuff like searching for drive content, and I can pull a specific account. And I can pull a specific account. And I can say, look, I wanna pick on Danny here. And we're just gonna say, look, I'm gonna go back... See, I can go back real far in in Vault here because it's, you know, in this case, it's only gonna pull data that's in the live environment though because I have no retention policy. So if he's deleted anything, this is not gonna pull this out. So this is gonna search. It's gonna show me his drive content here. Does search very quickly. Okay. Cool. I need to get that passport JSON back here. What do I do with it? Well, I can potentially open it in Drive. I can get a preview and all this sort of stuff. But how do I... I put it I put it back. There's no recovery. There... There's nothing in Vault that's meant to put content back into Vault after it's been deleted. So in this case, you have to run an export, and we'll say... And this is gonna go ahead and say, grab that. And that's gonna spin for a while. So this can take quite a while. And what this is gonna give you is a zip file with a chain of custody document because, again, for lawyers by lawyers, where it's gonna go ahead and be able to bring that out and execute that for you. So... But it's a downloaded file. It's not gonna have the file permissions. It's not gonna have where that data was located. And we just did this for one person, and we got about 10 documents back. Trying to do this at any sort of scale, or restore any sort of permissions with this is kind of not really possible. It's very, very, very difficult, to do anything, and, again, no permissioning. So we're not really unwinding. We may have the data, but we can't unwind, a truly catastrophic event or something that went really sideways. Okay. So now that that export has gone ahead and finished, you can see that it's available there. It's about 35 megs. But at this point, we're gonna go ahead and pivot over to the admin panel and look what kind of user undelete looks like here. So I'm gonna skip over the admin panel. We're gonna look at Danny's account on a little bit more of a data basis. We could see, you know, stores use, all that sort of common stuff. I'm gonna hit restore data because maybe we wanna pull some data back now. I open this window, and that doesn't go quite back as far as Vault. So I only have twenty five days of data that has been deleted from Danny's account that I can go ahead and restore. So in this case, I can pick everything from this to this and the drive. And if I hit restore, that's gonna undelete everything that Danny deleted for twenty five days. No granularity. No individual file picks. No specific restoration. It's gonna put it back where it was deleted from, but that could be a lot of data that you can sort through if you've been doing cleanup work or undelete sort of stuff. And it goes by the date of the deletion, not the date of, like, when the file was last modified or anything with that. So you have to know what date Danny deleted something on and if it was in that twenty five days to be able to execute that restore. That may be enough for some people. But, again, if the whole account gets deleted, then that data is gone. And what happens in that case? Well, you had a little bit of time here where you can hit recently undelete user... Or recently deleted users and roll somebody back, but you get about twenty one days on that one. And to go ahead to hit that button, that will put the account back, put a license back in place, restore that right where it was. So it's enabled and available to be logged into again at that point. And then you can start potentially doing some restoration assuming it wasn't deleted in there, and there's a whole layered element to this. So this is the protections that Google offers you to kind of undo things. But the core elements are here is Vault is not a backup tool. It's a need discovery and retention tool. It's not meant to put things back. And Google's built in tools to put things back cap out at about twenty five days for just about anything. Thirty days if you can get the end user to drive themselves working through that trash can. Okay. So recapping here, what we've looked at for Google tools is the trash. We've got short term undo for this. This is basically the end user side of undelete, and ready to go there. That's thirty days. Your version history can go for thirty days or a 100 changes, whichever comes first. Google Vault, there to be an ediscovery and legal hold tool. But, again, you can get data out of that potentially for very long terms, but any sort of recovery functions are not present. So you will not be able to put that data back into drive easily or repermission it or any elements with that. So you're... You'll you'll have the data, but organization is just completely out the window. And then lastly is the admin console restores and, again, twenty five days. So we're really dealing with if you can't find something happening within thirty days, you're not in very good shape. So what's changed in the ecosystem that we're so worried about these days? First off, poll question. We're gonna answer this one in the chat here. What can your agents write to today? Gmail calendar, drive and share drives, everything your user can touch, or you haven't... You not looked into this one yet? Well, we've looked at this, and a lot of the data situation that's coming through is that we're looking at, agents are not evil. They're indifferent. They're very simple tools. Well, they're very advanced tools, but they're very kind of simple in their thought process here. So users will give access to an agent, a toolset, etcetera, and that will go ahead and inherit that user's permissions. From that point, it is basically operating as user. Google gives us some capabilities with API visibility if the user is actually connecting via API. We're seeing a lot of these sort of desktop agent tools that are actually integrating with Chrome and being able to pilot like a mouse and keyboard inside of Chrome and be able to take those actions. So it's a little slower in there in what it's doing, but it's basically invisible to the, administration side of things. And then no alert fires. Because we're not seeing the behavior actually getting into their organization or or using some of those APIs, we are not getting some of the notifications because it looks like human behavior. So this is a growing concern for basically everybody across this. And to that end, we wanna kind of talk about what an actual vulnerability based off of Gemini actually happened here and what the timeline of it is. So GeminiJack was a executable or, basically, a a a injection prompt, vulnerability through Gemini via a calendar event, Google Document, Gmail. It had some capabilities to go ahead and change some sharing or do some actions there that were were not great. But the timeline here is one that I like to point out is because Google is really, really good at securing your organization, but we are moving from a situation where this was found and reported, by Noma Security in June 2025, and the resolution and patch to protect against Gemini Jack, they confirmed that it was a glitch. They worked with Noma on the fix in August, and then the public disclosure came in December, which usually means that's kind of the point where, you know, everything's patched. So we're looking at a six month timeline from known vulnerability to patched deployment because you gotta remember, Google is working with over a billion accounts at any one point. There's a billion Gmail accounts out there, and those accounts are, all sharing the same platform as Google Workspace. Across it, everybody's using the same infrastructure. So anything that has to be updated has to be able to be updated for a billion use cases across the planet simultaneously. So it's really, really hard to move at that breakneck speed, with that. So what does this kind of vulnerability bring in as we're seeing this AI evolution here is that the native tools are kind of assuming that one user is taking action, like a malicious action, an element with that. We're... You know, AI can move so much faster than that. So those sort of mass deletion events are really kind of our biggest concern with that where an AI might go in and start to purge things. Mass lockout. Google has behavioral and security analytics as well as content analytics that are running against every single Google account. And around that, if anything kind of happens that is uncouth is, you know, pirated media starts to show up, literally, there's there's a great security lecture on somebody using Google Sheets as a proxy server. It's amazing technology there. But that's sort of behavior that won't end well for your Google user account. And if something triggers that auto suspender, that lock out of that Google account, your process of getting the data back that was held by that account is basically going to be a a process of, appeals and potentially legal proceedings depending on what sort of data was involved in there and all these sort of elements that may lead to a point where you can't get that data back. And if your trust was in the Google undelete and the Google Vault side of things to protect things, remember, all that's bound to that user account. So if that user account gets locked out, Vault is gone for that user account, and there's no access or no rollback button for that particular one. So we have seen incidents where Google has machine learning, you know, the back end side of things, chosen to lock out accounts, and you have to start that, that appeals process, which, as you can imagine, working with a multibillion dollar global company, it's probably not the fastest process you've ever seen. Certainly not a overnight recovery there. And lastly, it's just undetected change. Like I said, we got twenty five days to thirty days for basically everything we can possibly undelete in this organization outside of fault. If you don't catch it in that period of time, you're in trouble. So story time here again. One scenario, four tools, one gap. So we're talking about agentic actions here. User says, look, I'm I'm loving, you know, insert agent product here. I'm gonna help it. I'm gonna connect it to my Google account. I'm gonna help it out there. Day zero, I deploy that agent. I give it a goal. Very, very simple goal. This is usually where you get in trouble. Tidy up my shared drives, remove whatever's redundant. Day one of three, goes to town, starts its work. Not attacked. I I asked it to do this. I gave it permission. It's it's it's it's helping me. Well, the bad news here is that, it went back and did away with a lot of content that maybe we only use quarterly or annually, you know, stuff that it saw no behavioral access to, no activity on. It just assumed, okay. That's old data. We don't need to worry about that. The q three closed files are now gone, and we're outside that twenty five day window. We don't have that possibility. So day 24, if somebody notices, maybe you can catch that and roll that back up. But day 24 is near that thirty day limit. Version history, that's deleted. When a file is deleted, well, it's it's no longer accessible. You have to get it out of the trash. So if it wasn't just changing files, that's not gonna help you. Google Vault, raw file dump. You may be able to pull that q three document out, but, again, you gotta go put it back. You gotta reshare it. You gotta do that. How many files are part of that q three? How How many things are linked to that? Are you using drive IDs? All that sort of stuff. This is all gonna be impacted by that sort of thing. And then admin accounts, so, the whole account, in this case, probably not the biggest thing unless you really, really panicked and deleted the account because you saw it making all these changes. But you can go ahead and roll that one back and potentially catch that as an undelete there on that version, history there. But this is cutting it close at day 24 there that you you might... You you, you know, one day, either side of this, you have a very big problem. So this problem compounds as we move up the tree. So scale... It's not one drive. This is every drive that the user has access to, everything that they touch, potentially thousands, if not millions of drive files. We see this all the time. Google Drive is is is now been around for almost fifteen years. This is... People don't clean things up. Unlimited storage has been around almost as long. So nobody deletes anything. Nobody goes back and checks their permissions. A lot of people love to use link sharing, and now we're starting to see the fallout for that as you get accounts that have, you know, individual user accounts that have been around a long time that have literally millions and millions of files accessible to them, potentially with added access, which gives you the access to change, or potentially delete that file depending on where it lives. So this can be a very, very wide surface area inside your organization, that you may fell to there. So, configuration is, you know, kinda coming back and undoing all this is... What does that look like? So, you know, try to rewrite all this sort of stuff. You lose all the metadata elements. Raw files are back, but not the the the business. So it's a little bit of a different story. So Google makes it fairly clear if you take the time to to sit down and read the the terms of service, which guilty as charged. I'm I'm not really frequent on that. So, we're looking at the shared fate model here, which is basically Google's gonna cover you for physical and network infrastructure. They're gonna make sure this thing keeps running, so they're gonna offer service availability and platform security. So they're gonna offer you the security tools to protect you. They're gonna keep you away from vulnerabilities there. And then they're gonna offer those default encryption and infrastructure controls. The top down settings there are available. Again, these are all things that you can use to to... They're gonna set the baseline. They're gonna offer you tools to protect yourself. But when it comes to your own access policies and configuration within your tenant, that's on you, bud. It's also on you to make sure you're securing your accounts and identity. So, you know, Google offers two factor authentication, passkey support, single sign on, multiple OAuth certifications, API restrictions available on a per OAuth toke... Token side of things. Have you set any of that up? Is that deployed right now? Question mark. So, that's on you to to set up and they're covered because each environment's different, so they can't kind of predict exactly what you need or everybody's gonna need as a top down. And if they could, they moved it up into the defaults there. And then lastly is just the information is, that's your responsibility. Google has a little bit of responsibility in maintaining the security of that data at rest while it lives in Google, but they're not maintaining that if there's a data loss event or things like that, that they're responsible for that. It's a shared fate sort of scenario situation here. So do you have a mechanism to protect against potential issues at Google with your data? This is where we're here to help close the gap. So Rubrik for Google Workspace is rolled out this year. We are gonna go ahead and offer you a copy outside of your tenant at a point of time of your choice. So we are covering Gmail, Drive and Shared Drives, calendars, contacts, and groups. We're gonna put that data in an immutable storage. It's air gapped and copied outside of Google. So it's outside of your tenant. It's not dependent upon a single user account or any sort of element with that. We have an up to twelve hour snapshot time, so we get two a day there. And we will... You can set that policy depending on whatever your organization needs, your frequency on that, and then how your data stores. We are keeping track and tracking that so that we can restore permissions, hierarchy, and metadata when we go ahead and bring that data back. And if you wanna go ahead and say up to ten years, we could do that. We can do forever. Well, I can't say forever. I don't have a forever checkbox. But what I do have is is the ability to set nine hundred ninety nine years, eleven months, and thirty one days, basically to to set that. And that's just long enough to make this someone else's problem, if, they so choose to lose backups at almost a thousand years in the future. With that, it's time to go ahead and switch to our other demo. Okay. This is the Rubrik Security Console. This is our, our tool set here that we're offering as part of this. This is kind of the central hub where you get an idea of what we're offering protection on for your environment. Whatever you've deployed, we cover. So you'll see here that we've got, you know, cloud products, data center products. You can get this all at a glance and see kind of the health of your organization and what's going on. So active directory controllers, SaaS toolsets like Jira, OneDrive and Exchange, Teams, and, of course, our Google Workspace products. So I'm gonna go ahead and switch over to my SaaS applications, and I'm gonna hop into Google Workspace. Okay. Now we're in the Google Workspace side of the SaaS protection. You'll see here that we get a high level between Google Drive and Gmail calendar and contacts. We kinda lump those together because they're kind of a natural flow, your kind of Outlook equivalent or kind of, you know, your day to day sort of thing there. And with that, we can see here that we have 100% compliance with SLA domain. And what's an SLA domain? Well, an SLA domain is basically how we define your protection policy. So really, really quickly here, we're just gonna say Google Workspace. We offer a retention lock. This is where you kind of have a nuclear two key solution so that no one... No single account. So you can log in user, can reduce your retention policy. We can set our frequency and retention. So like we said, we have every twelve hours. So we can say retain snapshots every twelve hours for seven days. We can stack this up as far as you need to go this out, and we can say, hey. There's my ninety nine years. Take one every year for, you know, a long, long time. We would save this policy, and then we can go ahead and deploy this across our organization where we would say manage our top down protections. We can set a default protection for everybody that our toolset detects within your Google Workspace tenant. Or we can go ahead and start to set some more narrow policies, say, by, managing the protection and setting on a per OU basis. This is kind of the most popular one. We get a lot of splits with, different sets of organizations, but we can also narrow this on a per user basis. Sorry. Per OU. And then my per users, if I wanna pick specific users, or I can use Google Groups to deploy that protection along that as well. I can also set my shared drive protection differently than my individual drive. So this is all pretty straightforward on setting that protection. As soon as you do that, it's gonna go ahead and start working and see backup protection there, taking those backups and working at kind of the maximum API that we have available to us. Now a restoration looks a little different. So let's go ahead and... I'm gonna keep picking on Danny because he's got some good stuff in his account. So we're in the manage protection. I'm gonna hit restore and restore user. And then I get to pick what I'm gonna bring back because I'm looking at the drive side of things right now. It's It's narrowing me to there. So I'm gonna say specific drives and folders. And, again, I'm gonna pick on Danny. And I can go ahead and dump a doc ID if I pull that out of, say, security investigation tool, you know, link history, something like that, audit trail that's been deleted. I can use that to go ahead and find that specific document. I can also just search his, his information or, you know, document IDs and metadata here. So I think we've got some PCI stuff here. Hit a couple of check boxes there, and then we just hit next. And we're gonna opt to... We can restore that to a new folder, or we can go ahead and put that right back where it was. We can also pull it into someone else's drive when you do this, so we don't have to necessarily pull back an entire user account just to go ahead and get a couple of files out of it, or we can export this content to a ZIP. So if you wanna download that, and there's always the option to opt out of restoring file permissions if you wanna do a little bit of investigation, little sideline sort of work. That's all available. Okay. So we're ready to go ahead and restore Danny's drive or at least the the selection of content that we've got here. I do wanna show a little bit of a different flow, though, that we offer here for what we call prioritize recovery. So I'm gonna hop over to my Gmail calendar and contacts this time, and I wanna go ahead and restore at scale. And then I'm just gonna pick my whole o u for this one. And then this is where we have a little bit of a differentiator in our product set. So prioritize restore is here to determine, prioritization and make sure that we're using that API pipe optimized or as best as we can. Google only gives us so many API transactions per minute, and per second, per user, all sorts of stuff per product. So what prioritize restore does is it's gonna focus on bringing back the last, in this case, seven days of data, and that we have determined from activity based off of the snapshots we've been taking inside your organization. It's gonna go ahead and recover that data first so that we're optimizing that. So we're not trying to bring back a single Google account that has, you know, 400 terabytes of data because it's where we've gone ahead and archived, every departed user, into for the last ten years. This happens. We're not gonna wait for that entire account to drive drive... Or, to, to restore. We're gonna go ahead and prioritize so that we're gonna work through... Look. We only need the most recent data first to get us organization back up and running, then we're gonna go ahead and pivot through recovering emails, say, moving up to one month, and then finally doing the full waterfall backfill of all that there. You can do a full restore if you wanna go ahead and just let let the system go. But prioritize restore gets you back up and functional much, much faster than just taking a full swing at this, from this element there. So that's a really big differentiator that we have, as we set forth with that. So that's prioritized recovery. Okay. So we've gone ahead and looked at kind of our four ways to recover here. So we've got our granular. So that's their kinda day to day. We showed you that, kinda walk through, pull out individual files as you need. Our mass recovery, we can go ahead and restore everything for everybody. That's the whole situation there. Prioritize recovery, where we're gonna go ahead and optimize that mass recovery, the the high performance restoration of the most critical recently used data there. And then lastly is self-service. I don't have a great way to show self-service, but we can certainly offer this to an end user, to allow them to, to self restore their individual files as they need. So you don't have to be in that loop for every single transaction when something gets deleted over twenty five days so they can help to handle that themselves. So coming back to our previous scenario where we were looking at this where we had that twenty four day situation where we're on the borderline here of what that looked like for that user. So day 24 with Rubik, at this point, we can pick the moment. You can choose a snapshot anywhere from before the agent ran, not necessarily just the last twenty four day or or that element. We can go pick up a spot in time where we wanna restore to throughout that snapshot process. We can execute that mass recovery where we can bring everybody back in one big operation with that prioritized recovery helping us out, making sure that that data comes back first that's most recent and most necessary, and we're bringing back that drive structure. So those folders, those permissions are sharing, that's all gonna come back. So it's gonna be not only available, but usable for your organization. So that's really where we're kind of setting the process different there. On top of that, when it comes to breach... So those are all great stories around the AI, the agentic overuse, that sort of thing. Now when we actually get into a cyber situation where there's a breach, kind of the number one way that this sort of stuff is happening these days is an identity breach. People are managing to break in through your identity provider, weak passwords, weak credentials, then they'll often, then the next step is always to pivot within that identity provider to go ahead and move, laterally to try to gain more access to ups, to increase their permissioning, potentially, you know, changing a lot of user accounts in the way, creating new user account elements with that. So what we have also as a service is we offer, identity backup and recovery services for Entre, Okta, and Active Directory. These tend to be about the three most common ones that are attached to a Google Workspace if you're not just using the native, identity functions within Workspace. A lot of orgs are gonna go and synchronize, say, Entre, Okta, or Active Directory to Google and then manage sign ins through that process along with, you know, device access and and functions with there. So with this, potentially, we can help you unroll that, which may be the grounds for the next thing that you would have to do, which would be a large scale prioritized recovery to go ahead and bring that back. So identities first followed by the restoration of data is not an uncommon path when dealing with a large scale cyber event. Within that, our core target here is delivering that rebuild of the minimum viable business in a truly kind of catastrophic event, and everything else, just that process kind of helps that happen faster. So we're really working around discovering the problem, mapping applications, dependencies before the incident, identifying users and behavior, identifying file activity, things like that that are gonna help us identify, know what needs to come back first, Then validate, working with this to do preemptive recovery, perform clean restores, being able to quarantine and isolate documents and such from restoration to make sure that we're not restoring bad content, prebuild. So kind of, help you orchestrate or plan a recovery around, potential cyber events or or challenges you run into there so we can kind of build that plan in our platform so it's rapid and ready to execute, and then be able to restore in an order that makes the most sense. So when we're working across the entire Rubrik platform here, we're not just talking about SaaS applications or identity. We may be looking at ground up restoration of, you know, virtual machines, databases, networking, virtualized networking across the whole side of things, and bringing the whole process up from ground zero across just about everything. So this is where we have a a kind of a widespread where we can do all this from kinda one panel, and help you out with that. So kind of the takeaway going back to, you know, you... Give you a little something here. As people start to deploy agents or as you start to think about agent deployment, we have three kind of big questions here. What can it access? You know? Can it map every drive? Can it access everything in in Google Drive? Is it overarching permission, or what are those access those individual users have access to that work... You may be granting an agent to? What can it write to? Is it a read only access, or is it escalating? Is it gonna be able to help, or be able to take action and cause this sort of problems that we have to deal with to undo? And then lastly is is what is the recovery plan? So when this goes sideways, if we hit a cyber event, something we couldn't possibly predict with the, you know, actions or or the, the the changing in landscape as as fast as it is. The question then becomes, you know, how can we keep up with that, and do we have a recovery plan for when we can't keep up with that? And that's really kind of the big core question that we leave with on that one. This is not the final video in the series. Appreciate you tuning in to to video one, or webinar one here. We do have a few more that are coming up. So just wanted to offer some follow-up updates here talking about, Frontier firm risk in Microsoft's s day, exposing threat vectors, and your SaaS blast radius, and then ways that Rubrik can, help you secure your SaaS state. So please do, make sure you get signed up for those. There's gonna be registration links available there. And with that, we're... Go ahead and open, up our questions here. We're gonna start to answering the questions that you've been filling with the chat, but please, make sure that you're, if you have any outstanding at this point, go ahead and get those in at this point. We're we're happy to take those, and we're gonna address those as best we can. Otherwise, we'll follow-up with you via email, afterwards there.