Name: Cowork Security Deep Dive: Getting Your InfoSec Team to Yes
Uploaded: 2026-08-20T17:31:57.332Z
Duration: 47 min 40 s
Description: Cowork Security Deep Dive: Getting Your InfoSec Team to Yes

Transcript for "Cowork Security Deep Dive: Getting Your InfoSec Team to Yes": Hey, everyone. Welcome. Thank you so much for making the time to join us today. We're have about an hour together. We're gonna be going through a few different chapters on the Cowork security deep dive. But our goal today is pretty simple. So by the end, we want your security team to be able to threat model Cowork accurately, and determine what your sponsors need to know before rolling out a broader pilot. Before we get started, I'll go through some brief introductions. So my name is Maggie Russo. I'm a member of the applied AI team here at Anthropic, and I support our commercial and mid market function, which I know probably many of you are a part of. So thanks again for being here, and I'll turn it over to Riggs, my colleague. Yep. Riggs Goodman, applied AI security architect. I cover, FSI customers and all the fun security questions that everybody has. Awesome. Alright. So here's an agenda of what we're gonna go through today. So we're first gonna set a quick baseline on what Cowork actually is. Most of you already know that, so we'll keep it short. Then we're gonna go a little bit deeper on Cowork local and Cowork remote. We'll talk about the data life cycle, then identity and administration, and then we're gonna wrap with a summary. The part that I really like you all to lead with is recommended enterprise posture. Again, just kind of going through what a governed pilot should look like on day one. So let's start with a short overview of what Cowork is and how a delegated task actually runs. Cowork can sit inside the desktop or on claude.ai, dot AI, and its job is to perform a task, not just answer a question. That's really the main differentiator between Cowork work and a Claude chat. In a chat, you're just asking something. The model may call a tool or use a skill, and you get an answer back, but it's basically just a single agent. Cowork work looks at what you've been asking, plans the work, spins up sub agents if necessary, executes across them, verifies the result, and then hands that back to you. It uses the same connectors, tools, file access, and skills that you already governed. It's just orchestrating them. In almost every customer conversation that Riggs and I have, most of the questions that we're getting are not about model safety. Many of you already probably have pod code and chat already broadly rolled out across your organization. The core questions that we get are about the architecture. So what is the virtual machine that you spin up? What runs inside of that virtual machine versus outside? How do I control it as an admin? So that's really what we're gonna be going through for the rest of the session today. So this is a little bit of a closer look on how a delegated task actually runs in five separate phases. Claude starts by asking clarifying questions rather than diving into the task blind. It breaks the work into a plan, which you'll be able to see in the progress bar. It executes across tools, files, and the web. It then checks its own quality and accuracy and then delivers the final output. The thing that I really wanna emphasize for you all is that every phase is also a control point. So the clarification and the plan are visible to the user, and execution passes through the permission layers that we're about to spend the next two chapters on. Finally, delivery is auditable. We had a huge launch, a couple of of days ago with the compliance APIs. We'll talk about the that a little bit later too. So keep this loop in mind because the architecture chapters, that we're going to talk about really all happen inside that execute phase three. So here's where we're going to go into a little bit more depth. The two places that Cowork can execute. First being Cowork local, which runs on your device, shell commands, and any model written Python code go into that hardware isolated sandbox, that virtual machine, while all the files and web tools sit behind a permission layer. With local, you're either running inference first party against Anthropic API or third party on your own bedrock, vertex, or foundry deployment. And then we have Cowork remote, which is newer. Cowork remote moves the entire agent architecture and sandbox into Anthropic cloud. Remote is first party only for Inference. There's no third party road map for it today. And remote exists because a lot of folks, don't want anything running on end user devices or on their endpoint. Right? So if you've had this issue where your developers are using Claude Code but it's inside of VDI, remote is the answer to that. So, again, everything is running in the cloud, and the endpoint is just a thin client talking to it. So next, Riggs is gonna talk a little bit more about Cowork Local and the architecture there. Yeah. Thanks, Maggie. So like Maggie mentioned, the first, area that we're gonna focus on is Cowork Local. And when you think about Cowork Local, this is having a desktop application, whether on Windows or Mac, that sits, on your laptop, where both the agent loop or the host loop, and the actual, agent, virtual machine actually sit. Set. And so, like, if you think about it, when an agent actually decides to do something, there's something called an agent loop where it runs and, will decide, like, what it needs to do. Whether it's gonna call a model, whether it's gonna call tools, whether it needs to do something in bash and other things. And, like, the way that we built out the Claude Desktop with, Cowork is being able to make sure that we're giving the right permissions layers both, to the agent themselves, the file web tools, being able to store the credentials in a secure way with that permissions layer. But we also have, the ability for these agents to do more, I guess, creative type things, like running bash commands. Or if you're asking it to do some type of growth model, being able to write a quick Python script, that can, be run-in order to have, like, a deterministic output. And so a lot of, both the bash and the shell commands is what exists in the sandbox itself. And the reason why we send it in the sandbox is to make sure that we can control exactly what it does just like with, what you have with MCP, and tool access, as part of the host device, being able to put that permission layer there and other things. And so if we dive a little bit, deeper into the sandbox, if you go to the next slide, what we have with, the sandbox is multiple different things. First, the sandbox itself is a virtual machine. It's either using the Apple virtualization framework or the Windows virtual machine platform, and it's running a Linux guest. And the similar type capabilities that you have with Linux today with users and what you can mount in this type of permissions that it has, we're doing the same thing within the sandbox to control exactly, what the sandbox is allowed to do and what it's not allowed to do. And, one of the big things that we have as part of that is process isolation to make sure that with each session, it's, creating a new user in there that the user only gets access to certain mount folders and other things that you decide to allow it to, have access to as part of the overall session. Also the types of files that you wanted to allow, as part of it. So, for example, if you wanted to have access to a certain file system that exists on your device, you would add that as part of the session, and that's what can get mounted into, that virtual machine. And the goal with the virtual machine is not calling MCP servers. The goal of that virtual machine is to be able to do, some of those bash commands that you might need to do as part of the session, and also, being able to, do those Python scripts. And you as an or overall organization get to control exactly the types of things that go in there. For example, if you don't want any environmental variables in there, where, Bash or Python could possibly use those, then you as an organization can set those type of controls. And, like, one of the most important things about that virtual machine is that we control exactly what egresses, from that virtual machine, possibly out to the Internet. And so if we, go to the next slide, the way that that actually works is, being able to have what's called an egress proxy. And by default, with the egress proxy, you can make it where it doesn't allow any, external access. So even if someone tries to put, like, some malicious prompt that says, hey. Write this Python script to go this malicious website. It everything going egress from that VM has to pass through that proxy. And, it does TLS termination for that proxy, and it allows you to do what we call a domain allow list. So if you only want the domains, where that Python or bash is able to hit the internal domains to your organization, then we, you can set it up as an organizational policy that this is the only thing from a web, egressing that virtual machine that you can actually touch, going, with Bash and Python. And it's very important, like, when you think about from a governance perspective and other things, having, the control of what you're allowed to touch and what you're not allowed to, touch and, like, having those approved, destinations to make sure that you're controlling even when the, model and, the agent architecture is trying to be creative with some of the things outside calling MCP tools, what it's allowed and what it's not allowed to do. Right? And so if we, look to see exactly where everything executes when we talk about Cowork, when it's something that is shell or model written code like Python, that exists inside the sandbox. And so you have that egress allow list, the TLS proxy in order to gate exactly what is allowed to do and what it's not. As part of that too, of course, we mentioned, like, what do you get to mount, as far as file systems or what, permissions that you're giving each session, and those type of things. For file tools, that's where things like MCP, come into play that you want to be able to access local files, but you also want to control exactly what, files, certain agents can access and what they can't. And this is something that sits outside that, virtual machine on the host itself. And, you as a user can decide exactly what folders you want as part of the session, what files you want as part of the session. But also from a governance perspective, you as an organization can control what files and folders that you, want them to be able to add. For example, maybe it's not the best thing to add your home folder, as part of a session if you don't want, the, agent being able to read on that. The third one is web fetch and search. And so from organizational perspective, this is something that, we can do web fetch and search with one p on the anthropic side. So running in Anthropic cloud going out to the Internet. Or you can actually have MCP servers locally that does the web first and, web search. And just like you have with MCP permissions today and the governance around, where you can go and other things, you can do the same thing with web for fetch and web search. For example, if you're doing one p, you can also set the allowed domains of where you want web patch and web search to be able to go. And if you're doing something with a local MCP server, the same thing, you as an organization can set those up just the way that you, set up that MCP server. And then MCP connectors and local plugins ins and MCP service. These are also things, that can execute either on the host itself, or you can have it, as managed, MCP servers or connectors on the Anthropic side. And, with any type of MCP server, you as an organization can decide what MCP connectors, are allowed, whether you want to allow local users to actually have local MCP servers. But a lot of that comes down to the permission layer that you wanna put in place for it and the types of connectors that you want from an organizational perspective allow your users to get access to. Alright? The one thing I do wanna call out is credential handling. So if we go to the next slide, one of the important things that we made a decision on from an architecture perspective is where credentials actually sit. And so one of the biggest things that we made a decision because it is a lot of that creative things with Python, and bash scripts that exist inside the sandbox that no credentials exist inside the sandbox. And that's intentional. Like, we don't want, the, agent to have Python access to things like environmental variables or o auth tokens and other things. And so the way that we're actually implementing credentials is being able for that to sit outside, the, VM itself. And so it sits on your host. Or if you're using, Anthropic connectors, all those OAuth is gonna sit, on the Anthropic side in order to connect to where you need to go. Because, like, if you think about anything with MCP servers, you strip off all those layers with MCP. It is an API call that you're making an API call to some, internal system or third party system, and you have to do the authorization and authentication in order to get there. And so, like, we put a lot of thought process as far as where credentials sit and what you should have access to and what you shouldn't have access to, as far as, getting access to those credentials. Alright. Next one, file access. And so I mentioned a little bit on the other slide, but with file access and folder access, you want to control exactly what files and folders you can, get access to. Because if you, allow, the, overall agent as part of Cowork to get access to your home folder and be able to do read and write and delete. A hallucination or someone trying to do some type of prompt suggestion or something like that could cause things to get deleted. And we've seen, like, public, I guess, posts and other things about that. But as an organization, you have to think about, one, what are the folders that you want, users to get access to? But, also, if you are an individual user, what are the folders that you want the agent interacting with? And it's easy to just say, hey. Let's interact with the home folder. But from a security perspective, you want to for, the agent to be able to engage with certain folders and being able to, either get information by doing a read or possibly you're trying to, update and document and giving that readwrite permission, but possibly not the delete. And so, like, that comes to a governance perspective and a individual user perspective if you are an individual user of the types of things that you want to give for file access in those permissions. Next one, plugins. So plugins and desktop extensions. If you think about, what the agent has access to, you have access to things like MCP service. You have access to things like skills. Where plugins come into play is it's combining multiple different, possible skills and MCP servers into a single package. And so we have a marketplace for, plugins at Anthropic that you can use, but you can also build, your own plugins. And from organizational, perspective, you can control what plugins, they want to have access to. If you wanna have an organizational marketplace where you can say, this is a plugin for internal use that has these MCP servers, these skills, and other things, you can do that, as part of, how you actually set up from an admin perspective and other things. And then, last one I, wanna talk about before talking a little bit about, third party is locking down the desktop. I kinda commented on all these as part of, what I mentioned other slides. But from a governance perspective, you can control exactly what are the types of MCP servers that they're allowed to have, whether you want to have local MCP, service disabled, what is the extension policy, what folder allow list, what egress domains. Like, all of that comes into play of you want users to be able to use Cowork in order to, solve task and, be able to be more efficient in, their job and other thing. But you also had to think about what is it from a security perspective that I want to govern across all of us. Right? It was mentioned in the beginning, that we support both first party, API and, third party model. And so if we go to the next slide with third party, there's a little bit of a difference exactly what third party supports. And so with third party, everything still exists on, the, Cowork local, like it does today. And so you still have that agent loop. You still have, the, virtual machine. But as far as for a policy perspective and governance perspective, instead of going into the Anthropic, admin console, the way that you actually push, the different controls down to each, Cowork device is being able to do it through MDM. And so, you as an organization can have different MDM policies that you can push, down to your users' devices that control the same type of things that you would get with one p. And if we actually look at the differences between, first party and third party, there are a lot of similarities, but they're also different. So inference, first party, third party is kinda where the separation is. First party is going to an Anthropic API. Third party is going to the cloud of your choice. So that could be Bedrock. That can be Vertex. That can be Foundry, just depending on where, you want to, send the data. The other thing is with data retention. So one of the things, that we have, with, first party is we provide a lot of features and capabilities as part of, being able to interact with Coworking first party. And some of the, session data and other things as far as you interacting with the model, we store that in the Anthropic cloud in order for you to be able to log or log out of the, application and then being able to get your session information back. And this also comes into play, when Maggie talks about remote too, that there's a lot of capabilities that we add with first party that you don't get with third party. And so, like, with third party, the way that it works from a, data retention perspective, everything exists locally on your device. And so you can still, exit the application and go back in. But, in order to actually see those sessions and stuff, it has to be on your, user device. With HIPAA and BAA, first party, it is still in scoping. With third party, as part of your cloud service provider's BAA. I've talked about both RBAC, and admin, for both first party and third party. But third party, you do it through MDM. First party, you do it, through the, Anthropic console. And we'll get into monitoring coming up, but we have a lot of, different capabilities as far as being able to monitor it. And then also being able to do things like inline, deep packet inspection. So thinking about, if you want to be able to look at each one of those prompts and completions from a governance perspective of being able to strip out things like PII or the types of data, that you want users to go in there. One of the things that we launched in beta, which I'll talk about coming up, is something called inline DLP, or inline hooks, I think is what the final term was that we called it. And then for third party, you can do a very similar thing with gateway. And so with that, let me turn it back over to Maggie, to walk us through exactly what we're doing with Coworker mode. You're on mute, Maggie. Sorry about that. Thanks, Riggs. I think before we move on from local, there's a few questions that came up in the chat, that I'd like to to have us answer. So the first one is, does it align with device firewall rules? For example, if I block something on the local firewall, does the proxy respect that, or do I need to manage it manage it completely in the sandbox proxy? Yeah. So, e anything egressing from the application is still egressing from your user device. And so we're not, like, encapsulating into a tunnel where you can't see it or anything like that. And so if you have certain firewall rules, within your network or within the user device itself, it's still going to, be able to control it that way too. But you also have to think that there could be firewall rules where you allow going to certain domains if it's a user that you don't want an agent to actually be able to access, and that's where that allow list comes into play. Great. Thanks, Riggs. And then second one before we move on to remote, I think this is kind of an overarching, question for the theme of the session. But, someone asked, does Cowork for Work have specific security controls in place to mitigate risk with the lethal trifecta scenario where an AI system has access to sensitive data, can interact with external systems or tools, and can execute actions autonomously? If so, could you describe the key safeguards and governance governance mechanisms? Yeah. So, you kind of or the person who asked the question kinda put it in chat, but one of the things with lethal Trifecta was coined by, Meta, I think, two years ago. But the goal is you think about it as a triangle. And, like, you have three different things, untrusted data, access to internal data, and access to external systems. And the goal with the legal trifecta is if you have all three, what leg of the triangle do you break in order to be able to, control and make sure that, like, some type of hallucination or malicious action doesn't cause an adverse effect? Right? And so with this, we do have controls that allow you to do that. We have, capabilities like being able to add human in the loop or being able to control exactly what MCP servers, users do have, access to. But, like, overall, we're giving you the permissions and we're giving you the controls in order to control what, the application does, but it's still up to you as an organization to decide exactly, what you wanna do with it. For example, if it has, access to an internal, database and you also are allowed to read email, you can have an email come in that has some malicious action, and then something, tries to get access to that internal data and then possibly try to exfiltrate it to the Internet. But, again, you as an organization had to decide what you want users to be able to do, what, like, domains that you want to be able to access in order to control that. But, like, as part of, like, the overall permissions layer, the virtual machine, and the governance controls that you have, there are ways to help, I guess, break one of those legs of the triangle, but it's more of an architecture decision from a, a organization compared to it's just like you click a button and you're good to go. Great. Thanks, Riggs. Alright. There's been a lot of great questions, but we're gonna keep this moving so we can get through the content. And then we'll hopefully address, more after the next section and at the end. So moving on to Coworker mode. So this is execution of Coworker in Anthropic Cloud. So this is the answer for those of you that, have VDIs and lockdown endpoints. And it comes with a little bit of a different trust, framework than than Cowork in local mode does. So again, why does remote exist? The local virtual machine in Cowork requires nested virtualization. And if you're using a VDI platform, most do not offer it, which made local kind of a nonstarter for a lot of our regulated customers' financial services. So hopefully, this is good news for a lot of you that were blocked by that earlier. Remote kind of inverts our model. So execution is happening in our cloud, and nothing is installed or executes on the endpoint. Users can also reach for Cowork then from a browser or even on their phone through the Claude app. And it's in public beta today with enterprises able to opt in within their organization settings. Hopefully, we'll have some more announcements on GA timing soon. Before we go any deeper, here's the interaction model side by side. So on local, everything is sitting on the device, the app, the host loop, and the sandbox virtual machine. The only thing that leaves is the inference call. With remote, everything we just went through about local, the agent loop, the sandbox, all of that moves off the user's device and into a micro VM in Anthropic Cloud. You send a task, the micro VM runs the loop, locks down shell commands and model written code the same way, and sends the response back. This unlocks a ton of value for the user, and this is why we built it. So for an end user, you can kick off a task in Cowork, close your laptop, and walk away, and that task is still gonna execute in Anthropics Cloud. So for scheduled tasks or things that you're, kind of restricted by us today and local, right, you'll you'll see that, setting when you create a scheduled task that your laptop has to be kept awake. You can gain a lot by enabling this in remote and running those tasks in the cloud. On credentials, they're going to follow the same pattern as desktop. So they're implemented cloud side. The OAuth tokens and API keys are still never entering the sandbox. What we have is a per session proxy that holds them outside and injects them on egress, which attaches assigned per request workload identity. So even a fully compromised sandbox workload holds no secrets. All it can do is use the ask the proxy to make requests. And every one of those is attributable and policy checked. So once again, code credentials never in the same place. On the control plane for CoReq remote, orchestration and policy for remote live in one multitenant control plane. Tenant isolation there is enforced at the application layer, the stand which is the standard multitenant SaaS pattern. So no difference there. Payload data is encrypted per tenant. And for concerns for customers with concerns on this, we can talk about CMEK, which we'll get to a little bit later, in the session. Okay. Let's talk about the network pass in remote. So for core remote, there's still more than just the the inference call, right? So, the model call is going to go from micro VM to the egress proxy to the Anthropic API. Connector calls go from the micro VM to connector proxy to third party. Everything is originating from the micro VM after the agent loop decides what to do. For remote, we also offer what we call desktop bridge. So this is where the cloud session can reach back into The U to the user's local machine for things like local files or local MCP servers. It's up to your organization if you wanna lock that down. You're able to lock that down completely if you want, but it's there so that people can utilize that local content when they need to. Okay. Session stay at rest. So remote sessions persist so that users can resume where they left off, which means that session state exists at rest in our cloud. And so this is important to know for for data classification purposes. The way that it works is when a user is interacting with the session, that session is active. But if they step away, after a while, it's going to go idle. And then we take a snapshot, memory and disk, and we encrypt that at rest. So when the user goes back to it, they can resume that session to pick it back up and start work again on a task. And that snapshot will expire after thirty days. This is another really important callout for why Cowork is not DDR eligible. So in order to provide on on first party. In order to provide your users the ability to resume the session and for us to save that session state, we need to save the session, which requires data retention. So we're going to go more into that in the next chapter where we talk about that data life cycle. But I just want to call it out here, because I think it's really important clarification of why data retention is needed. It's it's, you know, just to to let cohort function the way that it's intended. And often folks don't realize, you know, what we're what we're trying to do there, and why that's required. Before we move on to data life cycle, Greg, is there any questions from the chat that we should take? No. I kinda answered some of them as I went, so I think we're good. Okay. Great. Moving on to the data life cycle. Alright. So data life cycle, we've talked about a couple of these, but just to kinda go into a little bit more. So with data retention, a lot of it comes down to us being able to provide the features functionalities functionality that, we, provide as part of, first party compared to third party. So if you think about it, Maggie mentioned with Cowork remote, that the ability to resume sessions after you started. We had to save, Okay. what the session was about, all the memory and other things to be able to resume it in order to provide that as a. feature. And so, like, the data that we're retraining is being able to be used to provide the capabilities. No data is used for training models and all that that we've talked about at length, and, a lot of other sessions, but we're using it to provide the capabilities as part of the service. With three p today, the conversation stay local. And so if you ever wanna go back to your conversation, you have to go back to, your computer that you were running it on in or, as part of, like, the overall application architecture in order for you to get access to that session. So that's where a lot of it, is different. And, like, I kinda go already went through the next slide too of, like, why, one p is not, z d ZDR eligible. But just to, like, reiterate is the session staying transcripts is what we care about to provide those features compared to with three p, conversations, being stored locally. The other capability that we also provide, and this is also something, that we provide a lot across a lot of our services, is what we call customer man customer man customer managed encryption keys, or CMEC for short. And, what this is is the ability that when we're storing state on your behalf, being able to encrypt it with your own, keys. So if you think about, like, from AWS KMS or, from GCP or, Azure, being able to use those encryption keys to encrypt the data that we store within, the Anthropic Cloud as part of the service. Cowork remote, that's something that's not supported today. It is coming. It's just because it's in beta right now, and we have not enabled it, but will be, enabled, sometime in the future. And then data residency. This is another one that comes up a lot, of the way that you, get data residency. So with first party, we have two types of, data residency. First is US processing only, and the second one is just, global, geography. And so, if you want to be able to just process in The US, we do support that, or you can just allow it to go to, any inference endpoint in order for you to get, accurate, across, the globe. With third party, it is dependent on how you're doing inference with that cloud. So whether there's Bedrock, Vertex, Foundry, you can, have inference to certain regions of your choice, and, it's up to their, controls and other things as far as staying in the region and other things. For things like, over in the EU, you can have, res residency bounds in the way that you do the inference, but a lot of the configuration with that is done on the cloud service provider, to make sure that you're only doing inference, to the regions that you want to and those type of things. Right? Maggie's Screenshare, were there any questions on a couple of those that came up? Yeah. I think there's still a few lingering questions on credential management. So maybe. we can address all of these at once. So I had a few questions around, you know, how would a compromised VM keep credentials safe? How does the credential proxy know the difference between a threat actor versus a legitimate request from the sandbox? And then someone else was asking about cache credentials, pulling from your credential manager edge session, things like that. So can the sandbox still pull those in? Yeah. So the the way if if there's a credential that is needed for a sesh or something coming, from inside the sandbox, outside the sandbox, it has to be the credential has to be added outside the sandbox. But, like, a lot of the ways that, you're interacting, with, things with inside the sandbox, whether it's some type of bash command or some type of Python, if you're looking to get access to third party systems, that's where, the recommendation is to have MCP service do that. Not trying to get Python figuring it out for you and not trying to do some CLI command, that organizations have less control. Because, like, if you think about controls from an identity perspective, when you do have MCP servers, that use the MCP protocol, you can set up identity providers in a certain way as part of the application to decide these are the tools I wanna give access to, and these are the permissions when a user logs into, Office three sixty five or Gmail or something like that. These are the permissions that I want, to allow them to have. And so, like, having, especially if you're looking to do authentication and authorization, having that as part of the MCP server compared to try and do that inside the VM is the recommended pattern, because you as an organization have better control of exactly, what it can do and what it can't do. As far as compromised VM, I wouldn't say compromised VM, but more of, like, the data that goes in there if someone's trying to do something malicious with the VM. But you can still control that of the data that it gets access to within the VM and, where it's actually able to contact outside the VM too. Great. Thanks, Riggs. I also don't know if we say it at the end of the session, but, our trust center contains a lot of our security white papers and, information on this. There's a lot of, like, really great but very specific questions that I'm not sure we'll be able to to get to today. So just wanna call that out as a great resource. We can make sure that that is sent out after the call. Okay. So moving on to identity and administration. So who can do what? What roles, what connectors, where does human approval sit on that? So first is RBAC, which we launched in the spring. So that's role based access controls and single sign on. So RBAC and skin provisioning is essentially just deciding exactly what users get access to each capability and what permissions get pushed down to those user groups. So that's things like specific connectors. You can gate those as on or off for your entire organization. That's even tool level granularity. So, this is, basically up to the organization, and you can define this with, you know, very varying levels of specificity for each group. So for example, per group connector and tool gating, would be saying, I wanna give this particular set of users the ability to use certain right tools within a specific MCP, without Claude requiring approval first while the rest of your organization, so everybody outside of that particular group, has read only tools approved for Claude to take action autonomously. It also works for spend limits, gating different capabilities, like Claude in Chrome, turning Cowork on or off for your entire, you know, organization or specific groups. So all of those are capabilities deployed within RBAC. On the identity side, we support single sign on with SAML. It connects at the parent org with one IDP connection cascading to your child orgs if you have multiple organizations that are linked. And role mapping is from your IDP groups at sign in or via skin. One thing to call out today for the group is that we only support a single IDP connection. In the future, but it's a roadmap item. It's not something that is supported today. So connector governance. So connectors are the the right path. Right? This is the place where Cowork can act on your external systems so that they get their own governance stack, in these kind of four gates that we see. So admins can install connectors. So there's no connector that's approved by default when you, you know, install Cowork and start using it. You're granting those to your entire organization. And then users are authenticating via OAuth to to each connector. Per tool gating by group means that you can allow reads while requiring approval on write. So what I mentioned before, where you can block writes entirely. One important thing to call out is that whatever you configure at the admin level is setting the ceiling. So if you grant certain tools that always allow permission, which is the most permissive for a particular group or for your entire organization, your individual users can still go into their Cowork customized settings and choose to move those permissions to, ask before acting or block, depending on their personal comfortability. So, of course, this it does not work in the opposite direction. You are always in control of how conservative tool permissions are across the organization. We also have domain guard. So if you haven't heard of it, what it does is basically restrict verified domain connectors to your enterprise. So only Claude accounts in your enterprise organization can connect the supported connectors using email address on your verified domain. So if someone tries to make a connection to, you know, your your Salesforce, your your Gmail, whatever connector it is, and they're using a Claude account outside your enterprise account, that is blocked. So they can't connect to your, company email on their personal Claude. Alright. Approval mode. So here is kind of where the the human in the loop human judgment sits. Right? On Teams and enterprise plans, write and delete tools require per action approval by default. So the model proposes and human approves. Restoring always allow is an explicit admin decision like we mentioned. Right? So user, cannot just flip this on for themselves. Fully unattended mode ships off by default behind its own org level toggle that is available for the admin to control. And on auto mode, basically, add server side checks on risky commands. So in our internal evaluation, automated screening of this blocked a substantially higher share of dangerous commands than manual click through did. You can imagine, you know, with manual click through, some users are are not, kind of looking at those checks as, or evaluating them as as carefully as, a classifier could on our side. So, we we do treat this as a safety feature, not a convenience feature, and and would recommend, looking into approving that. Okay. Moving on to monitoring and compliance. Alright. So monitoring compliance. One of the biggest things that we talk to customers about is being able to get visibility into what their users are doing and how they're using Cowork. For one p, one of the things that we have is something called the compliance API. And this gives you visibility into the prompts, the responses, the tool calls, other things like that that we have, both for our Cowork work local and Cowork work remote in beta. Right? And so, like, the goal of this is for organizations that when they enable, Cowork for their users, being able to get that visibility to understand what they're doing, possibly even running it through their sim to, be able to find if user are trying to do malicious actions or, other things like that, as part of the overall governance that you have, with, Cowork remote or Cowork and, local and remote. The other thing to think about is, compliance API is for, one p. For three p, we support what's called open telemetry or OTEL. If you go to the next slide just for additional details, what open telemetry is is it allows you to do a very similar thing using a standard protocol in order to, send it to your collector or send it to your, SIM of your choice. And so the goal here is to be able to, kinda go where our customers are and support a, standard protocol to get this data, and then you as an organization can decide exactly, what you want to do with that. Alright? One of the things I mentioned earlier, I I think it was inline DLP, but, I think the official term, for this is, pre infant inference policy hooks. So if anybody's ever used Claude Code before, one of the things in Claude Code that allows you to do is, something called hooks. And the goal of that is if you think about the agent loop, that's basically a looping process where you can make model calls, you can read files, you can do tool calls, and other things. But what hooks do is they allow you at certain stages of that process to have deterministic controls that before a tool call was called, you can have it run through whatever Python script you have or send it to a third party to get approval before that tool call is called. And so what we're doing with Cowork and across a lot of our, one p, platforms is being able to have standardized, policy hooks that anytime there's an inference request of or tool calls or other things, you as an organization can push it through whatever policy engine you have. This is in beta right now. We have a couple of launch partners, that we had this with. But the goal there is being able to push it through a policy engine that then comes back to say, is this allowed, from a user perspective, or is this not allowed? And so, like, if you think about it, a model is going to help protect, some things with prompt injection. And you can control exactly the types of things, that you want them to be able to connect to in other things, but still within those tool calls or within those prompts, what this is allowing you to do is get greater visibility to see exactly what they're doing, whether it's PII data and those type of things. Right? The last one I'll talk about with, compliance, and this is something that Maggie mentioned is in the trust center too if you want more details. There's a lot of certification as attestations that we have, whether that SOC two, ISO twenty seven zero zero one, forty two zero zero one. HIPAA, is something that we're working on right now, but it's available with, three p. But, from a certification attestation, if you go to trust center, you can get an up to date list of exactly what we are supporting overall as part of Coworker in the, service that we have at. Maggie? Okay. Great. So we'll go into a brief summary, and then we can answer a few more questions live because we're doing pretty well on time. So five main things to take away from this session. So the first one is know what runs where. Right? So shell commands, model written code, or executing, and Cowork local in that hardware isolated VM. File, web, and connector pass each have their own gates. The second is that code and credentials are never in the same place. So that is true whether you're running Cowork local or in the cloud. Credentials are kept separate from the the sandbox or the VM where code is executing. The third is that humans stay in the loop. So write and delete actions need per action approval by default. Loosening that and making it more permissive for your organization is at the admin level as far as a decision. The fourth is you choose the deployment. Right? So you can have local with first party or third party inference, remote with first party in our cloud. Most enterprises segment that by population sensitivity, so that's something to be aware of as well as it's not, you know, one size fits all within your organization. The fifth is visibility. So what today what we have today, or have had for a while is OpenTelemetry. We've we very recently launched compliance API in public beta and beta opt in for our enterprise customers and preinference policy hooks, which is also in beta today. And last, we wanted to give you kind of a recommended enterprise posture. So if you're looking to deploy Cowork in a pilot or start rolling this out in your organization, this is what we would recommend. The first one is to scope your folder access narrowly. Right? So, keep that, you know, narrow based on what information you want Core to be able to reach for. Otherwise, you can grant specific folders, at the user level, but this will kind of maintain that, for your organization. The second is to keep your egress tight. So no wildcard hosting or pasted site domains on the VM allow list. Keep that domain allow list and those package managers scoped to exactly what you need. The third is governing your plugins. ins. So disabling your local MCPs and extensions, unless needed using a marketplace policy. So plugin in marketplace for your organization where you can, specify what's able to be installed by your end users. The fourth is keeping approvals on. Right? So, for any right tools that you're hooking up to via your connectors, making sure that those are not, something that Claude can just act on without asking for approval. Reserve that unattended mode for read only tools or no tools depending on your posture. The fifth is streaming telemetry and compliance API. So someone actually asked a question in the chat about, compliance API integration. So Otel, you can stream it to to, you know, any any partner. We launched some specific integrations for, security vendors, eDiscovery, SIEMs. So, that article should be linked in the chat if you wanna check that out. And then the sixth is segment by Assurant. So, local sandbox or remote mode chosen per user group by data sensitivity. This can also be a decision at the org level, but would recommend you kind of evaluate that based on the different groups, within your organization. That was all the content that we have for today. So maybe we'll take a couple of questions, from the chat, and then we can wrap things up. So, Riggs, I don't know if there's any that are coming up or some more, themes that you think would be good to address out loud here. No. There are not any themes. I've answered, some of these for people on the side. I'm trying to see if there's anything else that's, there are a couple questions about, compliance, API, that I will actually put the documentation in the chat just so people have it, specifically of, like, what is supported and other things. So I will put that there. But, a lot of the others are kinda questions I already answered. I don't know if you can scroll through to see if there's anything else. But, yeah, I mean, I I Maggie Russo, as you go through, I'll just kinda comment too that, Sure. like, one of the big things that, like, talking to customers, especially, their security organization and other things, that they care about is understanding exactly what the security posture is. And then from a governance perspective, how they as an organization can control it. Because, like, the last thing they want is to be able to enable something, and then, users are trying to be creative or being able to solve some of the tasks that they want, but it's causing it to go outside the way that you as an organization, want to, use it to interact with it. And so a lot of, the conversations that I have or Maggie Russo have is, like, going through that thought process of making sure that you understand exactly how it's built, but what controls, you can put in place in order to help things. Like, one of the questions that came up was human in the loop. When do we need to use that compared to, like, denying a tool? And, like, if you think about it, if anybody's worked with an AI tool before, if you turn on human in the loop for every single thing, after what, five questions, Maggie Russo? Six questions that you're just gonna keep hitting yes. Yes. Yes. Yes. Yes. Because you wanna complete the task. And so that that almost, like, puts for a worse security posture because they're not actually reading what you're asking for compared to maybe it is okay for any read action to be, auto mode compared to if you wanna do a right action or actually send an email that has to be human in the loop. And so, like, that's something like from a threat modeling overall governance perspective that organizations need to think about in in order to make sure that they're providing those tools, but also providing the right controls on top of, the permissions and, stuff that is available within the service itself. Yep. Exactly. Last thing I'll say is we have a survey that opened up a few minutes back. Would really appreciate if you could fill that out and kind of let us know if there's, things that we, you know, didn't cover in this session or, even items that we did that are still a concern. Our goal is to to make sure that everyone walks away from this feeling more comfortable with, you know, starting a a Cowork pilot or at least starting a conversation with your InfoSec team. So if there's major future gaps for your organization that are blocking you, or things that you would just want more information on even, you know, data updated or more information put in our docs, that's the feedback that we really wanna know that we can take back to our product engineering and and security team. So, please give us as much information as you feel comfortable sharing. We can always, you know, work with your account teams as well to make sure that you're getting the support you need on an individual basis. Alright. I think that's all for me. Awesome. So, with that, I think we can wrap up. Yeah. Go ahead, Riggs. Sorry. I was gonna say thanks for everybody, for joining. Feel free to find me on LinkedIn if you want. But, yeah, really enjoyed the session, and appreciate all the great questions in the, chat too. Thank, you. so much, everyone.