Name: Deploying Claude Agents Safely in Financial Services — AITEC x Anthropic Deep Dive
Uploaded: 2026-05-20T20:32:11.460Z
Duration: 56 min 20 s
Description: Deploying Claude Agents Safely in Financial Services — AITEC x Anthropic Deep Dive

Transcript for "Deploying Claude Agents Safely in Financial Services — AITEC x Anthropic Deep Dive": Good afternoon, everyone. Thank you so much for joining us, for our deploying cloud Safelian financial services session. I know a few people might be joining, but we have a lot of great content to get through today. So I will jump right in. First and foremost, a few housekeeping items. A recording of this session will be available to your email about twenty four hours after this session. We do have a q and a session, block that you can submit questions throughout out the session, and we'll have dedicated time at the end. And at the end, we would love feedback on the topics we're going to cover here today, and really hope this session is useful. So as a short introduction here, good to see many familiar faces and names on the call here today from the New York City dinner a few weeks ago. This is the follow-up webinar that we promised from that event. And from the conversation that night as well as the survey responses we heard from your teams, it's clear that what we wanna focus on today is about how to deploy Claude and AI in these regulated environments you all are working in without taking on risk that your firm can't control. So the next hour is going to be very practical and specific to those questions that you raised, and we will dive in deeply to those specifics in the q and a at the end as well. Very quick intros on who you'll be hearing from today. My name is Emily Wynne, and I'm an account executive on our financial services go to market team here at Anthropic. I've worked with many of you in the past, and excited to work with many more of you in the future. I'm very excited today to be joined by two of my amazing colleagues from our plat AI team, John and Maggie. They are the people that actually sit with firms like yours to deploy cloud in real workflows, talk through the security architecture diagrams, and the more specific technical questions, and they will drive most of our content here today. Awesome. So before we jump in, Maggie, I just wanted to note, the survey we sent you guys out on the next slide here. Last thing I wanna say is, clearly, for us, it is not a pilot conversation. 95% of you already have AI in production, and this is really the two zero one, three zero one, four zero one level sessions to really help you walk away with some technical insights of how to go forward. So with that, I will turn it over to you, Maggie, to dive in. Awesome. Thank you so much, Emily. Hi, everyone. So great to be here today. Like Emily said, we really looked through all of the the responses and feedback from the dinner, and that's kind of what we based today's session on. So this slide is really a road map for the four areas that we're gonna be talking about today. So the first is is kind of around that lack of control. Right? How do we actually, gate what Claude can access, what it can reach, how do we set up those gates. We're gonna spend a lot of time talking about those sort of enterprise controls today. We're also gonna talk about data exfiltration and bad outcomes. So where does data live from a residency and retention standpoint? Where do outputs land that clogged code and coworker are creating, and then framing that all around regulated workloads. Third, we're gonna address the execution environment and blast radius. So, as a lot of you may know, there's a little bit of a difference here in terms of how we actually deploy and and stand up a co work environment versus cloud code. And there's a few different options there, so we're gonna talk about that. And then lastly, we'll touch on prompt injection, red teaming, and some mitigation strategies there. Alright. So jumping into things. Before we actually get into the details of each, I wanted to really talk through some of the common misconceptions that we hear. So the first myth is cloud can exfiltrate data through web search. And reality is that web search is read only retrieval, so cloud is not able to write to external sites and browsing is happening in an isolated environment. Another thing we hear a lot is cloud could spin up an MCP server or custom server and dump our data into something like Dropbox. The reality here is that connectors are admin configured only, so Cloud is not able to self install or self authorize a new server. The third is cowork runs on our laptop, so it can just see everything on our local machines. In reality, code execution runs in a sandbox VM, sandbox virtual machine on CoWork, and folder and connector access is gated by explicit admin and user toggles. And the fourth one that's really common is, concerned about letting nontechnical users or business users run co work and having that be less secure than Cloud Code. For most enterprise configurations, co work's built in sandbox for code execution, is equal or stricter to a typical cloud code setup, and we're gonna get into the details there. Alright. So the first layer that we're gonna address is that control and governance side. So I wanted to kind of provide this mental model for how we think about our security posture. In the center, we have the anthropic product and product services. Right? So within the different services, we have chat, cohort, cloud code, and our Office agents for Microsoft Office. Within the cloud platform, we have the API. We have cloud managed agents, which is like a service side managed service for agents, and then we have the agent SDK. On the left, we have kind of the four main categories that we like to talk about for how you actually think about securing your own environment. So that's identity and access controls, isolation and connectivity, data loss prevention and content controls, and data handling and key management. So these four categories are kind of gonna bleed throughout the presentation here that we're gonna go into, and you'll see how different parts of these categories map to the specific posture that we're gonna talk about and kind of how you determine those options for your organization. One thing I also wanted to just say is that, a lot of this is gonna be dependent on your organization's risk management policy. Right? Like, how much risk are you willing to take on when you're actually deploying, an AI solution? And that's, you know, gonna be a part of the conversation with, you know, how what decisions you actually make with with setting up your organization. Okay. So let's talk about what clause able to reach and what gates it. So for Internet, we have read only tree retrieval through their search tool. This is, no outbound rights and there's no credentials passed through this. So cloud in Chrome is really the only way, that that cloud is able to use the browser for rights and it can be completely turned off for your organization and certain sites can also be blocked. For your desktop files or files in your local machine, this is only gonna be accessed by Cloud through Co Works opt in folder selection where the user is actually picking that folder per task or per session. For your, email inbox and your calendar, this is only accessible via the Microsoft three sixty five or Google Workspace connectors. These can be turned on and off for your entire organization by your admin. And even if they are enabled by your admin, your user, can choose to toggle that off, on a personal basis. And, again, those are gonna be authorized by the user's individual OAuth. Everything is scoped by OAuth with connectors. For knowledge bases like SharePoint, Google Drive, or Box, these are only gonna be via connectors that the admin has specifically provisioned. And, again, these can be gated by the by, RBAC, which we're gonna talk about in a second, and they're scoped by the user's OAuth. Your internal APIs are only available to cloud via custom MCP servers that your team is going to configure. And, again, these can be cloud cannot install or reach new servers on its own. And lastly, for code execution. So in co work, this is gonna run inside of a sandbox VM or in cloud code within a sandbox that you scope yourself. So there's gonna be no persistent access to your laptop or your network. Alright. So talking more about RBAC and how we actually gate for different people in different roles within your organization on what they can reach. So there's basically three levels here. Right? The first is is setting up a custom role. So you actually go and do this within, the admin console, and I'll pull that up in a second here so that we can take a look. But custom roles live in the side panel here. Let Let me make this a little bit bigger. So if I wanted to set up a custom role, I would go into my organization settings, which is accessible from the bottom left corner here, and then again select custom roles. I can add a new role here. I can give it a name, select an existing group that's, synced for my SCIM, and I can select and toggle on and off what capabilities I wanna include in that role. So for example, if I'm running a co work pilot, I might gate it to a specific group and toggle on co work and maybe nothing else for that. Then I can assign that role to a group, so marketing operations. I can add a new group or for a pilot group of users, and that's how I actually configure that custom role and that that RBAC group. So going back to the slide here, on the right, we have the capabilities that are able to be gated per role. So right now, this only includes cloud code, co work, web search, code execution, memory, fast mode, which is specific to the model, and then connectors, which, includes individual connectors per role. I will also say that this is, something that we're really working on or or focus on from a road map standpoint. So there's gonna be a lot that we're adding to this, and we'll talk a little bit about that more, later. But right now, this is what you're able to to toggle on and off. Okay. So building kind of on the previous slide here and going a little bit deeper into connectors, these are basically the four control layers from top to bottom that gate each connector. So the first the first one here is really the org policy ceiling. Right? So the connectors directory is by default off for for enterprise, and an admin has to explicitly enable each one. The second layer here is really the per group connector RBAC. So assigning specific connectors to specific roles, for example, only finance getting Databricks access, let's say. And then that within cloud code that works via the manage settings dot JSON file, which is the third layer here. So that's gonna enforce your allowed or denied MCP servers and kind of rules, rules within those. At the fourth level is gonna be your enterprise managed authorization. So, again, any connector authorization is is brokered through your IDP. So we're we're this is, like, kind of how you can protect what, Cloud is able to access within a connector. So whatever access your user has, that's using coworker or using code, that's the access that Cloud is going to have, within that tool. On the road map is tool level RBAC. So within a connector, actually gating, by role what someone is able to do within a connector. For example, you know, within, let's say, FactSet, the the FactSet MCP exposes a set of tools like fundamentals, consensus, estimates, ownership, and holdings, things like that. Right? And today, when you grant someone access to that FactSet connector, it gets all of those tools. Tool level RBAC would allow you to split that. So let's say your research team gets some of those tools, and your credit team gets others. Basically, it's just making sure that just because someone has access to a connector doesn't mean that they have the same level, of tools as maybe someone in a different role. Okay. So what does this actually look like in practice? So here's an example of a connect a tool that we've set on the connector level where we've allowed read access but disallowed write access. So if we attempt that via request that someone is, giving Claude in co work, we're gonna see that that's denied and the tool is not exposed to the agent at all. And within the the policy, what we're gonna see is that that right tool is disabled. Right? So that's gonna be logged as, like, an Otell event that you would be able to see from an observability standpoint. Okay. So the next topic I really wanna touch on is data exfiltration and bad outcomes. So first, from the data handling perspective, I just wanna make it clear that we do not train on your data for commercial plans. From a data retention standpoint, it's a minimum of thirty days. It's admin configurable up to indefinite for for enterprise. For any, like, EU or UK firms in the room, the the third party path on Bedrock or Vertex is how you get that in, region residency from a from a data residency perspective. And I think for for anyone who's wondering about, like, that kind of single tenancy policy, the the the real answer here is that there's logical isolation that you can, enable at the data layer with your customer held control. So, again, like RBAC, using an IP allow list, things like that. So there's not really a dedicated info option there. So just evaluating those controls against, your policy is is really the the best, the best method there. Okay. So going a little bit deeper on, web access and sandbox egress within Co Works specifically. So this is kind of managed, within two services. So on the left is gonna be your cloud.ai admin console, which is what we just had up previously. Right? So that's going to your organization settings. If folks have that open on the call, you can follow along with this. But if you go to your organization settings and capabilities, this is where you can toggle on and off web search, network egress, and update your domain allow list. So turning on web search, again, that's read only. So this is just on or off at the organization level. And then for code execution, you can turn that on and on or off and turn on or off network egress within that sandbox within, cowork. We have some the the default here for the domain allow list within the the virtual machine is package managers only. So the domain allow list is that means it basically preceded with major package managers, so you're not having to, like, install every dependency basically within that environment. But you can also add additional, domains to that. We have a couple here, right, that that we would want to be able to run within that, within that virtual machine within CoWork. One thing to call out here that I wanna make clear is that the network egress controls that you're setting for CoWork do not apply to web search, web fetch, or MCP connectors. So the the allow list is really for the sandbox layer control. It's not a a global layer. So what this catches is is it the agent writing code that calls an unexpected host, things like that. It's not necessarily gating the model's own, web tools. So for web fetch specifically, that's gonna be turned on or off via the co work managed configuration, which is configured via your MDM keys. And that's kind of what we see on the right side of the screen here. So within the MDM keys, we have the first party API keys, and then we have the additional keys that are available, if you're installing via third party. So for web fetch, you might be wondering, like, okay. If my if I can't apply, my allow list here, like, how is this safe? Right? Or how do I turn this on or off? So you're able to disable this via via the disable built in tools key. So that's one way if you just wanted to turn that off for your entire organization, you can set that. But what really makes it, safe and and how we kind of think about the posture here is that we're using URL provenance, meaning that only URLs that appear in a user message and the prompt or as a web search results or a prior result from web fetch are fetchable by the model. Model. So the model is not able to construct an arbitrary, URL that could be used for exfiltration or or something like that. So I just wanna make that clear because it is a little bit different in cloud code, and we will go through and talk about that. But just wanna make sure everyone is aware of where these things live, whether it's in the admin console, which is, again, your organization settings on cloud dot ai, or an MDM key that you configure when you're actually shipping this out to your organization. Alright. I'm gonna move forward here just for the sake of time. I wanted to show an example again of what this actually looks like, within that cohort VM. So let's say that where the agent is doing some kind of code execution, so it's operating inside of that VM boundary, and we're trying to, access this, this domain that's not part of our allow list. What we're gonna see is that the the, the allow list is enforced by a local proxy inside of the VM, and it's gonna be again logged as an event in our hotel collector where we're able to see that there's a, tool that was denied, and we give a reason here for the domain not allow listed. Okay. So I'm gonna switch now to cloud code. So we've mostly been talking about coworkers so far. And the way that you kind of manage these different settings and policies is a little bit different between, the the tools here. So within Cloud Code, you are able to to set some of these configurations within, the admin console as well. But most of the time, customers are actually setting this via managed settings, which is a a JSON file that you ship via your MDM. And there's a couple different sections of this that I wanna call out. So the permissions block, which is the first on the top, is where you can deny secret reads and, exfiltration prone commands. You can require approval or, excuse me, require approval on git push, things like that. Within the sandbox block, which is the next one down, this is the, kernel enforced sandbox on. So, there's gonna be no nested or unsandboxed escapes, and this is where you're actually setting that network allow list of known domains. So you can think of this as similar to what we saw for co work within that actual domain allow list section, for for network egress. So this is how you would set that within, your manage settings dot JSON file. In the allow manage block next, so this is gonna be where you're setting your manage hooks. You're, setting whether or not you want to only allow managed domains and MCP servers. So this is basically a set of, operators you can set to true or false here, as well as some other things like the model and available models, things like that. And lastly, within the environment block is where you're able to configure your hotel export, as well as hooks here. So for example, a pre tool use hook, which can, validate certain things like bash calls. Okay. So let's take a look at what this would look like in practice in Cloud Code. So as an example within Cloud Code, let's say in our managed settings file, we had allowed MCP servers listed as Jira and Confluence, and that allowed managed MCP servers only to true. This is going to block any other kind of MCP that we try to access or the agent tries to access because it's not in the allow list. So very similar again to what we saw, in co work. This is just another way of applying that policy to to clog code, and that's kind of how you would be able to to gate that within your organization. Okay. So talking a little bit more about observability here. So I know in the examples that we've done so far, we've shown an example of what that, log looks like for a particular event in your scene. But, basically, for observability, the way you wanna think about it is across the different surfaces that we have. So the compliance API is what gives you, basically, access to see the the different a little bit more detailed information about what's going on in the interaction between the user and assistant. Right now, that is only scoped for cloud dot ai and, config events for cloud code. So it's not yet supported for co work and for office agents, but we do have OTEL support for, cloud code, co work, and office agents. So you're able to see, those events. And our our docs page, which we have linked in the, doc section of the webinar, is where you can actually see what events are output as part of that. We also support audit logs, within Cloud dot ai as well as config config events again in Cloud Code. And we support analytics for all of these four product services, so you're able to see that as well. Once again, just calling out that OTEL is the only, audit path today for CO work tool calls. Again, the compliance API, we don't yet support for for CO work, but it is on our road map. So, we're working on that. We're aware that it's something that a lot of people, really need in order to feel confident deploying co work. Okay. So I'm gonna move forward here to the third topic, which is the execution environment and blast radius. So the first is kind of talking about the clogged code deployment and how this looks. So where clogged code is running, it basically determines who owns, the sandbox. Right? So if you're running, on local CLI and within an IDE, It's gonna be the built in sandbox tool, so, sandboxing and and your network controls. If you're running cloud code on the web, you have anthropic, anthropic managed virtual machine with a network allow list, proxy credentials, and auto termination. And then the third kind of option here is dev containers if you're already running on container infrastructure. Right? So for the config delivery aspect, it's gonna be server side from the admin console across these, like, we we just kinda saw there, either in your organization settings or via your MGM file. One thing that I I do wanna call out is that these two don't merge. So the first source that delivers the configuration to your your cloud code, install is what's going to win here. So just important to call that out that you can't kind of layer both on top of each other. So just going a little bit deeper into the sandboxing options. So the the built in sandbox is, OS level. It uses the platform's own, isolation primitives. So on macOS, that seat belt, Linux, sorry, Bubblewrap on Linux and WSL two. There's nothing extra to install there. Like, Docker is not required for the the built in sandbox option. But if you wanted to run cloud code in your own Docker image, you absolutely can do that with, your own hardening and and secrets management, and egress policy. So that is another option as well, kind of related to that dev container option. The the option that we don't have called out here and kind of the one with the strongest boundary is running cloud code in a cloud VM or local VM, or, some kind of VDI image that you control. So that's kind of the overall posture here. I I will call out also that, we don't support native Windows sandboxing, but that is being explored. It's something that we are looking into. I know that that was a big request coming out of the dinner, so just know that we're aware of it, and it's something that we're we're researching right now. Okay. So shifting to the co work deployment. So what does this actually look like? So the Cloud Desktop app, basically runs our agent SDK as a native process on the host. So you have built in file and web tools that execute on the host that are gated by your application layer permission system that enforces your connected folder and network egress policies. So any kind of shell command and any code that the model authors are are dispatched to sorry. Any code the model is running is dispatched to, a dedicated Linux virtual machine. So no shell command or code interpreter tool ever executes on the host OS. On the virtual machine itself, so, again, this is gonna be the, Apple virtualization framework on macOS. All of this is also, in our docs and our trust center, which is linked on the webinar as well. And for Windows, it's a virtual machine platform, and the operating system is, is Linux there in the guest OS. For the per process isolation, so you get a private mount namespace. The privilege is the per session dedicated user. As far as the the network I'm sorry. You have per session isolation as well. For the network, you have an isolated virtual network behind the hypervisor. And then, again, the sandbox runtime, I do wanna call out here because I think it's important that, the anthropic developed runtime enforces the domain allowers that you're configuring in the organization setting. So, anything that you allow is the, as far as network address is gonna pertain to that sandbox runtime. It's not it doesn't actually govern your web fetch or web search. That that is separate. And then, lastly, also just wanted to briefly touch on, Microsoft Office. So the Microsoft add ins for Claude is how Claude shows up inside of Excel or PowerPoint without leaving the, Office application, whether you're using, Word, PowerPoint, Excel, Outlook. The thing that I wanna call out here is that the first party pass, so, the anthropic API that you see on the right is one of four options. You can also route the add in entirely through your own infrastructure, whether you're using Amazon Bedrock, Google Vertex, Foundry, or an LM gateway, via the cloud and office plug in. So with that, users sign in via the enterprise gateway, and your inference never hits Anthropic's first party API. So that is a path available to you as well. The admin is gonna set that MCP is gonna set the MCP gateway, and skills that are available within within the the added environment. So those are also gated, and your end users are only going to see your approved connectors when they're working with Cloud within, a Microsoft Office application. And OTEL is also available. I think we we covered this in a previous slide, but OTEL also available, for all of the Microsoft Office add ins. Okay. So let's take a look at what this looks like in cloud code. So here, we we just looked at the, manage settings, right, where we have the permissions block on the top, and we're denying certain, certain commands. Right? So in this case, this is blocking, a sensitive file read command. So the configuration on the right is what you would actually set within your managed settings JSON file, and then we see the results on the left here. So quad code is going to block that command, and we'll see again what that event looks like in our hotel collector. That's gonna be a denied decision, based on the configuration that you've set. Another example here within clogged code is for that, domain allow list within a sandbox. So, this is a a really similar example to the network egress example we saw before for co work. So within your sandbox, this is, allowed allowed managed domains only configured to true plus the allowed domains domain list that we see. So if we're trying to access something, in, in this command here that's not in our, allowed domain list, that's gonna get blocked. And again, we see what the event collector would show. Okay. I'm gonna pause here for a second. I know we have a couple of folks from the anthropic side, that are on the call as well. So I wanted to see if there's anything that we should, address before we kinda move into some of the overall, security posture examples and some of the the road map items. So, John or Emily, I don't know if there there's anything you want to, flag in the q and a that we should pause and and touch on here. Because we're actually doing pretty well on time. I think we're only about halfway through. Hey, John. Hi, folks. How's it going? Good to see you. So, so I think the the questions are are really healthy. I mean, some lingering issues. Questions are really healthy. What I think we should do is, there may be a couple that we can cover, but I think I just wanna let the group know that we're capturing all of them. We're we're gonna follow-up on these in writing because some of them were a little bit granular to go through Got it. live. So I think we should we should do that. We should keep rolling. Okay. Sounds good. So looking at kind of three example postures here, so want to be basically put this into practice. Right? So, basically, at this point, we've covered, how you actually enable connectors for a specific group of people, how you gate what tools are accessible within a connector, for your entire organization. That will come later as far as being RBAC enabled. We've looked at how you configure your settings within the admin console for co work and cloud code as well as the specific manage settings file for code and the MDM keys for co work. So those are kind of the the main areas where you're able to configure these things. But what does that look like when we're saying, if when we're going from, like, more conservative to to more permissive as far as the model? So this is gonna be split a little bit across cloud code and co work, and something I actually would encourage everyone to take a look at is one of the docs that's linked for, a cloud code security guide. That's gonna have a lot more details on what we think of as far as a permissive model, a balanced model, and a conservative model for cloud code specifically just because there are a few more configure configuration options there. We've also linked a GitHub repo there that has an example managed settings JSON file for, each of those three options. So definitely take a look. I think most organizations are going to fall somewhere, in the middle of those, right, and have kind of a blend from each of these three categories. But let's go through each one. So on the conservative side, we would basically turn off web search and web fetch for for cloud code and for co work. Right? We can allow us our MCP servers to our internal only, turn off basically those external connectors, and then enforce the the sandboxing for, cloud code. For co work, basically, have domain allow us for what we want to, actually support. In cloud code, we can also have any kind of right tool require and ask permission. That could be spoked at the connector level as well within cloud cowork. So, let me actually pull that up because I don't think we we showed that too explicitly, previously. But if I go back to my organization settings and go to my connectors here, I'm able to open those up and scope the the ceiling of what my organization is allowed to do. So for this example, I've opened up the Gmail connector, and I can turn on, restrict to ask before, using the tool or blocking that tool entirely. And that's gonna be the the ceiling, so, like, the most, conservative, layer that my entire organization sees when using that connector. And I set these to always allow the user is able to actually go and and set the, restriction to be more conservative, but they can't go the the other direction. You're kind of setting the ceiling there. So, again, you could set every single, connector tool to restrict to ask first or even blocking any right tools, and that would be more on the conservative side of setting up that, that tool use. From a CoWork deployment perspective, one option here as well is VDI installation, and that's gonna be via supported nest via a supported nested virtualization platform. Platform. So one thing to call out here is that CoWork does support VDI install, but the requirement is that the underlying hypervisor supports and has nested virtualization available. We actually do provide a readiness check binary via our docs page for, Windows and and, other environments. But just to kind of call out a few that will, that are supported, Azure Virtual Desktop, Windows three sixty five for on nested virtualization capable SKUs, Citrix or VMware Horizon on a customer managed vSphere or Hyper V. This is, again, all in our documentation. So this is very this is all referenceable by, anyone who who is able to access those links. As far as unsupported environments, just to call out in case, people have these on the call, AWS workspaces, AWS AppStream two point o, Google Cloud workstations, and any GPU enabled instances. So, there are there is some nuance there within, Citrix tools. So, again, also, please reference the docs page for how you can do those readiness checks, and what options we support and what environments we do not for cohort today. On the the balance side here. So I would say for for most enterprises where we typically find most people, kind of landing for a lot of these policies. So turning on web search and web fetch, but maybe scoping connectors for read and write access on a per tool basis. So not just broadly allowing, you know, every tool to have the same level of permissions, kind of getting it based on what data is inside that connector, and whether, you know, everyone in your organization has access to that connector or not. Also, still using the MCP allow list, setting that in managed settings as well as, for cloud code, the managed MCP JSON file, which, is again available in our documentation. I didn't go through an example of that today, but that is more specific to your MCP, permissions and settings. For, code execution for cloud code, you're gonna have that sandbox enabled, with proxy to egress and then deny rules on sensitive path. So kind of like what we saw in one of those examples, blocking certain, shell commands and and making sure that you're comfortable with what Cloud is able to execute on its own. One thing I don't think we have called out here but is in the GitHub repos that I mentioned is, bypass permissions, auto mode. Those things are also configurable. So for cloud code specifically, again, you're able to kind of, have a little bit more control over those types of features. And then for co work, just using, the the native co work architecture. So deploying this on your machine, which is gonna be a host side agent that does, you know, read, read files and things like that, and access the web from the the the host layer, but it's gonna do any kind of shell command code execution inside of a virtual machine. And then the permissive, the permissive policy stature here or or example is gonna be a little bit broader in terms of, how many domains you have in your allow list, having an open plug in marketplace, for example, and just having fewer deny rules. I think what doesn't change across any of these is having, your, having hotel on, having the compliance API API, and using the the data from that for the supported product surfaces, and still having your managed settings set the ceiling or your admin console set the ceiling for what you're comfortable your user is doing. Okay. So also wanted to touch on Microsoft here because I know there was a lot of questions from the dinner about Microsoft specific, sort of, uses and kind of things that we support. So for Office add ins, we did kind of go through the architecture there. But this is, GA now under the cloud for Microsoft three sixty five app source listing. You can deploy this via your Microsoft three sixty five admin center. And again, if you wanted to route your inference through, your, Bedrock or Vertex or Foundry, you're able to do that as well as through an LM gateway. This is not in the compliance API again, but it is does support, OTEL. The Microsoft three sixty five connector, this is gonna be your actual MCP connector that you enable for a coworker or for code or chat. This is, again, gonna use your own user authorization, and multifactor authentication. So users can only see what they already have access to, and this is a read only connector. On the Purview side, I think we got a couple of questions about this. So to clarify this, we we don't have a native Purview sensitivity label enforcement today. Our connector for Microsoft three sixty five uses delegated permissions. So Claude, again, is only gonna see what the user has access to, but your existing tenant DLP and conditional access will still apply. So for for audit and DLP, we have the compliance API, that that security and compliance vendors build on, and that list is always growing. So, I know that Purview label like, having that label awareness in terms of, the encrypted content is a priority for a lot of people. So our team is aware of this. Unfortunately, I don't have more of an update to share, with you on that right now. And then for for sandboxing within Windows, again, cloud code is running on WSL two on Windows today, and native Windows sandboxing is something that we're exploring. But, hopefully, that clears up some of the the questions that we got from the dinner. I know, a lot of these are are top of mind for folks when it comes to to co work deployment. So, trust us that our team is aware of these, and it's something that we want to, continue to improve upon. Okay. And then last layer here is on prompt injection and prevention. So just kinda I'm sorry. I was gonna say maybe. one of the Microsoft piece to touch on before you move on here. oh, yeah. So, Of course. Eric asked about orgs with OneDrive and SharePoint connectivity. How do you prevent employees from connecting CoWork to these folders and force them to use local folders only? Maybe just touch on that briefly. So when you say low like, if you're only if you don't want them to be able to access folders from that are live within the connector, that would either have to rely on their own access within that within SharePoint. Right? If if they have access to that folder, then Cowork is able to as well. Otherwise, at this point, it would be just gating, the connector to that user. So, that's really the the the line right now. I think when we get a little bit more into sort of some of these, labels and and kind of use cases that that and features that people have, requested, that may change. But today, that is that is how you would draw that line. Perfect. And then one more on the Excel add in, and we can follow-up on this one because it's a bit more specific. Is there a plan for us to run a store of workbook specific cloud sessions so the history of the conversations can be recovered and reused rather than having to start fresh. I think the answer is we shipped this recently, but curious if you have anything to add there. Can you sorry. Can you repeat the beginning of that question again? I'm not sure I fully understood it. Yeah. So instead of Claude for Excel adding wiping the sessions each time, is there a plan to run, Oh, I see. Workbook specific sessions? Yep. Yeah. So so we don't retain session say on that today. It's memory only. So as far as an immediate change, I'm I'm not aware of anything that we're making. As far as a change to that, we can certainly do that as a fast follow after the the webinar today. But, right now when you close out a chat, it it doesn't retain that sort of history where you can reopen the file and go back into it. Okay. Yeah. Perfect. Awesome. Thank you so much. Okay. So going to kind of our last section here before we fully, transition into q and a. So on the risk, kind of pain here and where we see actual threat vectors, so on prompt injection, right, this is obviously a real concern that that folks have. But how we see this being addressed is through, instructional hierarchy. Right? So, again, I I think this has probably been said at the dinner and, at previous, events that you may have gone to, but Claude is trained with security in mind. Right? All of our models, are trained to recognize these types of events, and we, you know, we have this kind of security posture as an organization that, you know, cloud has these instructions to recognize, bad actors and things like that. So that's some something that we, truly do, like, include in the model itself. But as far as what you can do to address it, again, tool use constraints, having explicit user confirmation for sensitive actions, all of that is going to be, within your admin settings and what you're what you're allowing Claude to do autonomously. The other kind of thing there is just sort of, limiting the blast radius. Right? So everything we talked about with sandboxing, and and kind of limiting what Claude is able to do from that perspective is going to to help address this. But, again, this is kind of how we we we feel this is able to be addressed by, both, you know, anthropic and how we have built Claude, as well as organizations kind of setting up their own defense mechanisms and enabling across those four categories that we talked about in the beginning. As far as over permission connectors, this is kind of another threat area that we see, and the way that we, would recommend addressing it is at the admin level, scoping, what tools your team has access to, tool level RBAC, which is coming, and then just starting an error. Right? So expanding tool access or connector access to your organization or specific teams based on the use case and why they need it. Data leakage via generated artifacts. So cloud actually building something that leaks data, that it shouldn't. Right? So the output, that cloud is creating is staying inside of your tenant, so that is one thing. And then export and share are are gated by your existing DLP controls on the storage layer. So even if Cloud does create something, let's say someone has access to a folder within SharePoint, to use the example given before, that they shouldn't have access to, that, you know, that is kind of how we can prevent that from going outside, of your tenant or outside of your storage layer. Unreviewed MCP server configuration. So MCPs are explicitly provisioned by admin, so there's no self install. This was one of the things that we we brought up at the beginning as kind of a commonly heard, fear or worry that people have. But those custom MCPs are gonna be configured at the admin level as well. So, there shouldn't be there there's no risk of having Cloud kind of, like, invent that based on an API that your, your organization is exposed or is exposed to your organization. And then user behavior outside of policy. So this is managed a little bit more reactively than proactively, I would say, as far as the other, examples here. But auto logs, session replay, and then admin enforced guardrails via your system prompts and workspace policies. So this is, again, like, basically, you can enforce these guardrails, but you're able to also see kind of any sort of event that is outside your policy, via those logs, via telemetry, or the compliance API. And then lastly, just to kind of talk about testing and red teaming and how you actually audit either cloud code or co work, doing something that you don't want it to. First is in all of the settings and configurations that we've been discussing so far. So managing what settings the model can't override. So, again, it's gonna be your sandboxing setup, your network egress policy, your MCP allow list, what commands, what what shell commands cloud can run, and then what plugins, your team is able to install. The second is red teaming. We have a really great, blog post online of how we've actually red teamed, Cloud code. So maybe we can link that as well in the docs or send it out after because I don't think it's included right now. But, basically, attempting to attack your own boundary. Right? This is something that we do all the time in Anthropic, but, using adversarial prompts inside of your pilot group. Right? Varying your tasks and trying it on different configurations, seeing what's actually blocked versus what's get what gets through and then using that sandbox boundary for your pilot as a test surface. So running this continuously, testing the boundary and just knowing that, what you configure is, as far as all the things on the left here, is not the model making a judgment call of whether or not to employ that. That is a strict deterministic rule that's being applied. And the third is monitoring. So, again, streaming those hotel events into your SIEM and being able to watch for policy, events outside of your policy, unexpected egress, things like that. Okay. And then I think one thing we wanted to talk about is, the road map. So maybe, John or Emily, if you wanted to come back, up here, we could chat a little bit about some of the things that we're working on. I know we've, talked a bit about some of the the items throughout, but would would love to kind of talk through, some of these more detailed topics that we're we're planning to release. Awesome. So I think John will hop on and share a few things here too. But a couple things we're thinking about are, number one on the sandbox piece. I think a lot of folks are looking for a way to test these new capabilities with a smaller team as well as, how can you connect into some of the data pieces on MCPs that you've built and you've configured internally. So at a high level, I'd say those are the two big buckets. John, I see you're on the screen. If you wanna dive in deeper there, then happy to add a little bit more on the as we've talked to. Yeah. So, this is a this is a component of of our managed agent products that lets you run the compute in your own environment. It's a you know, self hosted sandbox is also sometimes called bring your own compute. And it's important because the CPU orchestration that surrounds the the inference today happens in a managed infrastructure. And for regulated customers, we've heard that that's a that's a difficult compliance ask. And so with self hosted sandboxes, you're able to then choose the environment that that runs. And the host loop lives there and talks to cloud inference on your behalf. And on the NCP tunnels piece, this is in research preview today. So if this is a specific thing that your team is interested in testing out, you've sort of done these types of workflows, feel free to reach out, and we're happy to talk about what that could look like. I've done some early testing with customers on this to sort of, you know, stress test it, see what works, see what doesn't, and we're always looking for that feedback. So just a note on that piece specifically. It's worth talking about CMIC, because this is this is a really important ask for our regulated, and highest data sensitivity customers as well. CMEC is it refers to customer managed encryption keys, and it's what it sounds like. It's equivalent to key management service on AWS, for example. You, as a customer, control the security keys that allow Anthropic to decrypt and access your information. And Anthropic cannot do that. When you grant access, it's time based and and document or item based. And so, you know, the permission only lasts as long as as you've granted it. And if you if you revoke the keys for any reason, even Adropic can no longer access them. This is the kind of feature that that requires sophisticated security practice because, of course, if you if you lose the keys, then nobody can get to it. But on the other hand, for for customers who have highest level of sensitivity about knowing how those keys are managed end to end, seem like that's something that you'll now have. Awesome. Thanks, John. Alright. And then we'll we'll basically leave you with this. So these are the resources that are connected, to the docs toggle on the right sidebar here. So this and then I think a few more things as well are linked for your reference. But that's what we had as far as content, so we can use the remaining ten minutes for some q and a. So I think one that I see so we did talk about, the the coworking SharePoint access. John, I'm not sure if there's anything else you wanted to ask there as far as options for for limiting that. But I think today, we're we're kind of constrained by the connector access, and and can't really get too much more granular than that. Yeah. That's that's right. It's although we do hear that the we do. hear that the additional granularity is something that you want. So it's, Yeah. the so we hear you on that, and we're working on it. For the the next one that looks like it has the most upvotes here is, building out a full pipeline to ingest the compliance API and hotel telemetry is a big undertaking. Yep. Any plans to roll out same support, say, for Microsoft Sentinel? I think this is also something and and John, feel free to to add here that we hear a ton. You know, the compliance API, like yes. This is basically everything that you you do have to set up yourself right now. I think one thing that we are working on is more partner integrations. I'm not sure if there's anything we're able to share on that at this moment, but, I know that this is a big concern and something that, would save a lot of time and and sort of configuration effort for customers if we have this. So, again, I know, like I don't want to just say we hear you on all of these, but, just know that we're working on it. I don't know, John, if there's anything that that we're able to add to that. Let's keep moving. Okay. Looks like the next question we have is around proxying your own packages. So can we proxy packages through our own instance of our factory? So, I think for cloud code specifically, you are able to point it at your, specific package installs within manage settings. But for co work, that's gonna be, for, like, specific domains within the the virtual machine. So, I think it it has, like, the standard package that it's gonna install, and our our trust center should have links for what that is. But I don't think we're able to automatically redirect the package manager to, like, a custom registry. So for Cloud Code, yes. I don't I don't know if it's exactly the same posture for for cohort today. have customers who are who are locking down the binary in this way, for for clogged hood, and they're using, static references to make sure that that the underlying dependencies are are defined as well. Okay. Great. Any other questions that we see? Maggie, maybe just double clicking on something you mentioned on co work. You talked about how to restrict which file folders users can access. So maybe just provide more details on what that looks like. So that's at the user approval level. So the user is granting within cohort that it has access to this folder. That's not something I believe we can gate at the admin control level. So admin control level, again, is gonna be, MCPs and connectors, what actual surfaces you have access to, whether a coworker can execute, WebFed or sorry, WebSearch, excuse me. And then again, the the network egress policy for, Sandbox for for any actions happening within the virtual machine. As far as actual folder access on the user's machine, that's gonna be granted, by the user. And then on the cowork agents sort of auditability observability piece, one user noted that it said no for audit logs on coworking agents. Not yet. Maybe speak a little bit on the road map of how we're thinking about those services for audit logs. Sure. John, is there anything we're able to share, on the audit logging or compliance API side for cowork? I know that's a huge priority for our team. right now. this is something that we're actively working on. The, you know, the the general ask is that customers wanna know precisely everything that happened, in inference and tool calling, in reasoning tracing and output from the model. They wanna know it user by user. And so, we're we're working on a way to make this much more cleanly available to our customers. Awesome. Okay. I think the rest of the questions that I've seen kind of fall under that, category of of pretty specific to your individual configuration. So we will get a detailed answer out to those folks, to make sure that you have what you need. But, hopefully, this was helpful in understanding, or getting some more information on the the questions that were raised during the dinner and kind of diving deeper on each of these topics. What we will do after the call again is send out this deck so that you have access to these materials. We'll resend out the docs that are linked in the webinars that you can access, the specific areas of our documentation where, we talk about the cloud code setup, sandboxing options, and manage settings as well as for co work, all of the available MDM keys both on first party and third party. I know we we flash those up briefly, but, probably a lot easier to to walk through them yourself in the documentation and, you know, figure out what needs to be configured for your organization. So we'll send that all out after, but thank you so much for your time. Really appreciate everyone tuning into this and for all the the great questions and engagement. And we'll follow-up with a a note after, but I'll give you a couple of minutes back, in your afternoon today. Thanks, so. much, everyone. Thank. you, everyone. Bye.