Name: Secure the Advantage: A CISO’s Guide to Agentic AI
Uploaded: 2026-05-12T18:32:34.465Z
Duration: 48 min 52 s
Description: Secure the Advantage: A CISO’s Guide to Agentic AI

Transcript for "Secure the Advantage: A CISO’s Guide to Agentic AI": Everyone, really nice seeing you and really, really excited to be here. We're now in the seesaw guide to Aginic AI. I see a lot of, people and a lot of questions. We are recording it. We'll share it in the end. So so thank you thank you very much. In a nutshell from from our side, and, would love to, to move here forward. So we're recording. We'll have a question section, and we'll leave enough time in the end. So feel free to send it over, but we'll address them mostly, I think, at the end and really open to feedback on our side. We're gonna talk about, Ajenic AI frameworks that we use today in anthropic, how we see governed deployments. We're gonna focus slightly more on co work, which came as top of mind in many of of our discussions, balancing risk, and then really open it up to q and a. On our side, I'm Dor. I'm leading the product management for cloud enterprise security. So really helping customers secure their cloud footprint coming from a identity and cyber security background, and now here in in Entropic. And with me, Jason, he's the deputy CISO here in Entropic. He meets dozens of security leaders, every week. He was the first CISO here at Entropic and saw how AI really accelerated, and we're excited to to have you. Good I. think yeah. Yeah. Great seeing you, Jake. So I see, you know, you see a lot of customers. You see how AI is adopting both here in Anthropic, outside. Do you mind sharing more about how you see balancing risk? What's your guidance to to customers? Yeah. So and and the side of Anthropic, like, we are adopting AI at maybe a faster pace than, like, literally anyone in the world. And so we have the opportunity to sort of, like, discover what works and what doesn't work. And we've seen some ideas that didn't work out so well. You know, you can learn from our mistakes, and so hopefully that's what we're gonna be sharing here today. And, we're we're gonna talk through some examples of of actual system deployments. But, every every organization, including Anthropic, has to decide, like, how much risk tolerance do you have? Like, maybe you're a small start up. You may have just a few people. Maybe you don't have customer data, and you get really just willing to take a huge amount of risk. You maybe you've got swarms of agents running running literally everything in your in your, startup. And, if if you are more on the spectrum of, you know, something that's a highly regulated industry like health care, you know, maybe you have to be very careful. And everybody gets to decide as a leader where on that spectrum they are. Anthropic is mostly on the, the safe side of the spectrum. We we do have a risk management framework that we use. We'll talk about that a bit. And when we think about, like, the ways that we we deploy agents inside of Anthropic, every time that we deploy something, we're trying to figure out what's the worst possible thing that could happen and, you know, mitigate it somehow through a technical control or a human control, something something that can lower the risk. So we'll talk about that about quite a bit today as we talk through a co work and a couple different things that we're we're doing inside of Entropic. Incredible. So I think we we start with the with the taking one step back. We're hearing from customers that they have, like, the governed program that they run. They have the shadow programs that they run. And especially now that AI is becoming much more mainstream over the course of the last few few years, do you have any thoughts, anything that you're seeing either internally, anthropic, or externally about it? Yeah. I think probably the best way for us to, like, hit this would be to, like, talk about a specific example. But before I get there, I think I think all of us as leaders, especially if you work with your GRC team or your GRC team reports up through you, you have to decide, how are you going to be able to explain to your auditors, what you're doing. So an ISO 42,001 is an example of a framework that can be used to sort of, like, govern risk management for your organization. So there's a lot of, ways to sort of take the right, right approach, with regard to what what is going to be, attested later. But the important thing is that you can't just be the the department of no. You can't be the place where, everything, inside of, your organization comes to comes to die. And that's that that's not a that's not a winning solution, and it's certainly not gonna be a winning solution, in a world where our our boards and our executive teams are asking us to move very quickly on AI adoption. So I'm gonna give you a very concrete example from inside of Anthropic that we've used, and and I think it'll be instructive of some of the the ways that we think about moving fast. So, about a year ago, we started using Cloud to help automate our incident response process. So for any of you who've been on call before, you know that, like, 02:00 in the morning, there's a page, people wake up, they create an incident channel. It might be a security incident. It might be a reduction incident. Whatever it is, everybody's sleepy, not not super responsive. But, we created Claw to sort of help us do, incident response. And an example that I'm gonna give here, it it's pretty obvious, in retrospect how we can use, agents in a safe way in in this example. So we gave Claude read only access to all of our production logs, and our production logs don't have any PII in them. And the only other thing at the time that this, bot launched was, access to Slack to open an incident channel and sort of, like, run the incident process and also a, access to create new Google Docs, which we use for the postmortem process. So three activities immediately automatable, in a in a very impactful and very concrete way. And there's, like, a couple principles that come out of that example, that we'll talk about in a second. But before I get there, one of the things that's sort of amazing about that example is that was built a year ago. And if you just think about the progress that's been made in the last six months, we had an ex we had an instance of this particular bot, when Opus 4.5 came out, which was in, was in November, I guess. We we moved this bot over from Opus four to Opus 4.5 and started running the incident response on it. And that intelligence uplift, without us changing absolutely anything at all, That intelligence uplift made it possible for that bot to discover on its own. It's like, okay. It's it's an incident. It's, like, 02:00 in the morning. You know, I've already figured out what the root cause is because the production logs have a stack trace in them that shows that there's an there's an error, a particular line of code. Well, the bot thinks to itself, and you can see this in its thinking traces, well, I've already achieved what I'm supposed to do, and I'm just sitting here and I'm you know, the human hasn't shown up yet. What if I, like, figure out how to how to actually solve the problem? And on its own, in this example, it reached out on Slack, which is where our incidents are managed, to another Claude instance and say, hey, Claude. I heard that you can write code. Can you write the code fix for this change, this this, production outage that's going on route? And, that that in that example, you just see an emergent intelligence augmenting, what what's going on. And the guardrails of, like, having human in the loop seeing the the interaction between, the the original agent and the agent that does the autonomous coding, all happening live on Slack. So we'll talk through that. I think the next slide starts to get into a way to frame, what the, what the framework looks like. So, we have a couple different things that are true about, this, this case. Our production logs are the input in this example. Right? So there's no untrusted content. There's no opportunity for prompt injection, you know, if we're if we're talking about, you know, something that's open to the Internet, whether there might be, you know, some attackers trying to break into your agentic system, it's a different case. And increasingly, models are getting better and better and better at prompt injection defenses, but there's still a small chance that that might it might happen. But in this case, all the input is trusted, and it's all internal Slack. The worst possible thing that could happen, in the example that I just gave is that some production logs that are slightly sensitive get posted to the Slack incident channel, which is locked down anyways. So just, like, really not that much impact that you could imagine. And the coding agent that's contacted at the end of the story, it's gonna upload the coding, like, output to a GitHub PR. So some human's going to review that before it lands in the tree. So, like, there's human in the loop in the incident response in the coding example. And the blast radius, you know, if it's compromised, worst possible case is similar to the worst possible cases if the the agent goes rogue. You know, you have to start thinking about agents and agentic deployments as kind of like an insider risk problem. We we were really, as an industry, indexing quite a bit on insider risk in 2019 and 2020. Everything that's old is new again. So insider risk is is term as far as agents are concerned are are super important. And then everything that happened in the example that I just gave is locked. So everything inside of Entropic in that example goes to our SIEM, and we can use that SIEM to sort of respond, to to the, as you know, respond if something goes wrong from an agent, perspective or if we want to do a a longitude analysis of how impactful these things are, all that information is stored in a data store that we can use as well. So this this example is great because it just shows, like, you know, you've got read only, actions. The rights that exist are for only new Google Docs and for Slack, so there's not really anything bad that can happen there. The, the prompt injection probability is extremely low because we have internal, data sources. And then for the examples, of, prompt injection, in the wild that we've seen, like, the probability of of those, being successful as models get more intelligent is going down over time. So I think it's it's quite, quite important to, to think about, you know, a narrow example where you can have significant success. Now we're gonna talk on the other end of the spectrum. The the, example that I just gave is an example of something that we call, like, an agent deployment using a system service account. This is a fully self contained single business purpose, principle of least privilege entity that does exactly one thing in the business. We're also gonna talk today about Cowork, which is a completely different, end of the spectrum, which is the human operator, the person using cowork on their laptop is ultimately accountable for the outcome of the system, and we're gonna talk about some examples of that too. I don't know. Is there anything else, Dora, that you think we should hit before we move on? No. No. It sounds great. I would love to like, I love the example. And, specifically, I think from my angle of building the products here, really something that resonates with customers and really in line align with what you just said is that gradual rollout and gradual, like, increase of of the capability of the agents as our, like, leading principle to least privilege and what do we want to allow in the products. We actually really think about it in the way that Jason just described. You can start small somewhere and then expand the capabilities as you go possibly by models maturing and also possibly because you adopted, things better. And we will want to allow you all those controls to do it, like, in a safe and trusted way as part of how we also build our own products. Incredible. Jason, should we move to a govern deployments and a. more let's do that. call? I think we actually missed a poll. We got we got a little ahead of ourselves. So before we, before we go on, we have two different polls that we'd like to to throw up for you. One of them, is on adoption, and the other one is on governance and risk, risk profile. So the first one's a little whimsical to sort of break, you know, break up the monotony of a of a long webinar. How many of you have gotten to the point where you feel like you can really delegate a large part of your day to an AI agent? I'm using one right now. It's on my other screen. It helps me every day get ready for my meetings before before I get into them and tells me what's going on with my day and and and, plays guard on my calendar, as well, which is super super helpful. But we have some, poll questions there. And then we also have a poll question on how many of you have adopted some kind of risk management framework to help you with, with, you know, articulating risk to your board, your coat, your your executive suite, and your auditors. And those are all important, important audiences for this risk management framework. So, while we're waiting for you to reply to the poll, we'll go ahead to the next slide, and we'll talk about, a bit of what we're gonna be, talking about for the rest of the session, which is cowork. And I think we can also take some questions too if there are any any that have come in. But, before we get to that, cowork, for for clarification and for those of you who aren't aren't familiar, is a mode of the cloud desktop environment that is nothing more than cloud code running inside of a web user interface. So I think it's really important for those of you who are getting ready to deploy co work to understand that as a threat model, because that, I think, really helps clarify and helps you understand exactly what's going on underneath and what the admin controls look like. Effectively, what's going on is when you, your users inside of your enterprise, download, cloud desktop and they and you as the admin have enabled cowork, you get to decide if you want to do this or not. There's an admin control for this. If you've enabled cowork, what happens is that in the background, cloud desktop, provisions a, Cloud code environment, either in Windows or or Mac OS. And when that Cloud code environment is bootstrapped, now that is a workspace where Claude can work with local files, can write little scripts, inside of a sandbox, can make outbound network requests that are sort of, related to anything that you as an admin have turned on, or it can call MCP servers. And it can all happen on a persistent long running session that allows really long hours of work in some cases, tasks to be completed over many, many steps. So if you've if you've ever done, cloud code before, you know that a very large programming task can be broken down into, like, nine or 10 steps, and and cloud code will iteratively work through every step of that. Let's say you're in finance or you're design. Co work is the ability for those tasks to be broken down into steps and then run locally on your laptop over over a long a long period of time. So all driven by Cloud Code doing the work under underneath. And and many of the controls that we'll talk about today are related to that. So let's, really quickly check-in with the poll and see where we're at, on that. Yeah. I think there's. a way for us to present those. Yeah. Yeah. I'll, Taylor. I'll, present those, There we go. on the screen. So co work, many many customers describe it as now AI for, like, their mass enterprise, like, much more than the specific targeted developers use case. But, like, every knowledge employee can can really leverage it and and get most of it. So what we're seeing here is that around 17%, with pretty high number of of people who voted, handed it over while we saw, like, a few that didn't respond, but the rest are are really, looking, Yeah. Amazing. want. Jason, does that align with what you see, like, you know, is. this set? is. I I hear from so many leaders that they really want to, like, get away from, the, you know, the the the daily emergencies, the the stuff that's taking from their time just so they can learn how to use Cowork, to improve their improve their lives. I have to say, like, it's the best investment that I've made in the last few months on improving my own productivity. This is this is one of the many, many different kinds of what are called local agent frameworks, and this is our product offering. There are many others that have been out there, including ones that went viral, which I won't name here. Those have all been, examples of enabling, you know, local productivity enhancements. And and some of the examples that I gave earlier about calendar management or, workload management, like, all of those things are super helpful. You can set reminders. You can set daily tasks in Kron that help you help you make progress. Let's see what the other poll results are. So. I I just want to give one practical example from from my end. I'll tell you how my morning started. In my. job, I attract multiple items that need to be completed on on multiple, like, boards, digest for even my own, like, patience and, like, mental anxiety. What was done? What's new? What's shipped? And and know who should I think about it if things are delayed. And that really changed how, like, a daily routine is now being done by my co work for that sake. And. I'm seeing a lot of security leaders that tell me that security is very democratic. They have to do a lot of, like, stakeholder management and they use those kinds of things internally. Yeah. Yeah. It keeps track of my Gmail and Slack for me. It's great. This poll result for ISO 42,001 is a little surprising, but, one of the reasons I think it's so, so important and so powerful as, as an organizational leader to lean on this is that if you have 42,001, as part of your ISO 27,001 process, It's usually just a few thousand dollars to add on to an existing auditors, like, engagement to, like, get that additional, certification. And then you can use the risk governance that comes from this. Like, let's say you have a risk register or you have an executive risk counsel to make changes across the organization that help govern AI deployment and and operate at speed. I mean, effectively, we're trying to create a raceway for, like, AI deployment inside of an organization by using one of these frameworks. And if if you have a risk governance in place, you you have the, you know, the you have the task and approval of the organization because the risk management's in place to make pretty profound changes to the way that work goes. It can be a really good, forcing function for, driving executive alignment as well in cases where the the risk management has to be distributed across different leaders. So, very, very, interesting results here. I highly recommend, folks pursuing, this if not if not already on your radar. With that, maybe we should check if there is any q and a. Do you think, has any q and a come in? Yeah. Yeah. Yeah. I think, especially for your I think your last question your last example, Jason, made people, like, be even even more curious about the, the SRE agent and the and the risk mitigation. Do you mind sharing how do you manage the risk for multi author input streams, if. that makes sense? Yeah. So if if, if there's more than one person, involved in any particular task that's going on with, with an AI agent, typically, what we've seen inside of Entropic, you know, we have we have an agent, as I mentioned, agents doing a lot of stuff inside of Anthropic. We have an example of a, agents that are doing, like, autonomous coding. You know, Daria's, spoken publicly about this. If the human is the is the primary author of a code review I'm sorry, an actual, like, code change and and then uploads that to, code review, an agent can do the code review, and, you know, that is sufficient for, in many cases, landing that change in the tree. But if if, alternatively, in the context of a bunch of engineers working together, there there's a request to for Claude to go off and do some change where, like, many, many people have had input in the engineering changes being done. The author of the change is now recorded as the Claude, and then human code review has to happen in the code review process. And so it's like it's either a human and reviewed by an agent or it's an agent reviewed by a human, in the multi author in the multi author case. We're using, we're using the, system service account as the identity in in the, the second case, if that makes sense. Does that sort of answer the question, I think? Yeah. Yeah. And I I love, I think, in in general, the more we make analogies to things we are already used to, to some extent, Yeah. I think that that really helps. I got a pretty interesting question about, all the examples, all up. I'm curious about your take. What's your approach to, like, even understanding how many agents the do you have and and what how should customers think about it? Approach approach to agent, deployment inside of Anthropic, you mean? Yeah. Or just advice for customers. They they they're worried by, like, many agents being spun up and Oh, yeah. then. So, yeah, this. is like the shadow IT question. I think, we'll get into this in the controls for co work, but one of the things that I think is quite, important to remember is that you as an organization have lots of opportunities to intercept, different kinds of agent deployments that might run on endpoints, whether that's, you know, people downloading, you know, an agent scaffold or some open wait or open source tool to their to their laptop. You can use, you know, MDM or policies or CASB to redirect that traffic back to something that's officially on the the company path. So there's an opportunity to make sure that, you have a, you know, a set of governance rules in place, that are deployed through an enterprise policy framework, for that. So maybe we should go on. We should start talking about some of the controls that you can use for for cowork. So as we talked about earlier, yeah, coworker has these these steps that it does, but there's a lot of tools that are inside of your old framework as a as an IT leader that you can use to govern, these deployments. So the IDP is a, an obvious place where we've already performed integration. We have bindings to, your groups, identity, the the things that are inside of, your existing enterprise deployment can be used as as governance control points so the groups can be replicated into cloud. And then you as the admin can log in to the admin console and say, like, for these, employees who are, like, maybe temporary contractors, like, these features are disabled. Or for folks who are in the engineering department, maybe these MCP servers are enabled relative some to some different MCP servers. Like, all of these are are driven by the the IDP, group identities. Everything that happens can be fed into your SIEM through, OTEL, open telemetry framework. We we do this at Endropic for our own internal deployment. It's been it's been extremely helpful. You can use, network policies. Like, for example, you can say, like, we only want to allow outbound network queries to google.com or, or to, Wikipedia. Like, those those are examples of some, like, domains that you could allow list that are probably pretty safe. But, we've we found that a number of enterprises have decided to have a pretty expansive list of domains in the allow list. But the idea being that, like, if there is some prompt injection, there there is no opportunity for the injected model to reach out to, any domain under the control of the attacker. It's a pretty important principle, for for some of the most, most, security sensitive organizations. You can also set per tool approval policy. So if there's, like, specific, MCP servers that you want to allow or even within the MCP server itself, a specific action that you don't want to allow. Or, let me give you a very concrete example. Like, you might say you're you're going to enable the Gmail MCP server. Well, maybe you want to allow only authoring drafts of emails, not allowing sending any emails. Or maybe you only want to allow, reading emails and never, never, deleting emails. Like, you as the admin get to decide on each of those individual actions which ones you want to allow for your organization, which is a very powerful control. And then, we we are really, you know, leaning heavily on existing, public standards. For example, MCP has been spun out. We integrate with, OTEL. Like, all of these are opportunities for for, co work to work with existing, existing, security frameworks. CASB is one I also mentioned earlier. But there's there are DLP and and other other, standard industry norms for for governing deployments. I think we should go to the next slide. Yeah. For sure. And just about the the last point, as as we're now building and expanding our, our security controls, we're really putting more emphasis on integrating with your existing stack and the exciting features and and the partnerships that we're working on, where the main goal is that what you already have should be extended if you manage PII handling somewhere. Like, we want to integrate and to accelerate that instead of introducing a new surface for for the security team. And, that's how we're thinking about things with the with moving forward and specifically also covering co work with that. Back to you, Jason. Yep. Yeah. So, everything on this slide speaks to an ISO 42,001 risk management framework. So, everything here is intended to take a specific risk to your organization and reduce that risk. So I'm gonna talk through the risk and, like, the impact that you you get from from the control. With identity, you're using, you're using a couple of things about accountability in an organization as part of your control framework. So it should it should be the case in an ISO 42,001 for agent deployments on laptops. Employee accountability is part of the story. Right? You have this, like, policy that says that you, the employee, are responsible for whatever the agent does on your behalf using your credentials. If you use the agent to, like, hack our internal systems, that's there's gonna be serious consequences for that. And that, that identity being bound to the session is super important. For connector allow lists, you get to, and decide which systems and which data is in scope for enablement. So many companies draw a line between corp and prod. As as an example, your MCP connectors might all be corp, and you might have a rule that PII from the prod environment never comes into the corp environment. Or if it does, it goes through, DSPM or, DSP, or or DLP rather, opportunity for sort of redaction. So, you can make sure that your connectors and your NTP servers for various kinds of, like, corporate, identity I'm sorry, corporate, tool handling are mapping to however you want to manage risk, with regard to to data. Every one of those connectors allows you to do per action approvals and denials. And with that, you're getting the ability to say one of our ISO 42,001 controls where might be we're only going to allow reads and never writes. We're only going to allow searches and never destructive actions. Like, those kinds of opportunities, to reduce risk are, going to be helpful in cases where you're dealing with, like, let's say, you want to help your engineers move faster, for deployments, but, you don't want, any any kind of opportunity for the be like the production database gets deleted or something like that. You get to disable those delete functions, in the control, permission console. We already talked about egress allow list. Again, this is a protection against prompt injection, and potentially data loss, but mostly prompt injection. Execution, we use sandboxes, as a, very, very extensively inside of Anthropic. For example, many of the autonomous engineering workflows that we have use an ephemeral engineering environment where there's, like, a scratch box where, like, you know, new VMs can be created and destroyed, and it's completely separate from our production keys and our production environment and completely separate, cloud accounts. And those ephemeral VMs are an incredibly powerful tool for Claude to be able to do really long horizon tasks for automating, work. At Anthropic, we've crossed more than half of all of the code now, that is being submitted for PRs is from this autonomous coding agent that literally never has a human, open a terminal window at all. And that is only possible because of this, the sandboxing principle that we apply very broadly, at Anthropic. And then in deservability, I I have to comment on that, Jason, that, as. I joined, I was mind blown by how these sandboxes and that approach really allowed me as even a product manager to commit code so fast in a in a very reliable way. Like, I don't feel like I I've circumvented neither security or just software reliability, because. of how well those those were set up here in Anthropic. Yeah. Yeah. And then, again, we have the human in the loop. So even if the output of the agent isn't great, the worst case scenario is it ends up, in a PR that we never land. And so, it's. a huge opportunity for us to, like, double check everything before it goes goes out the door. Observability is a a really, important principle for risk management. We as leaders with Mythos and the broad moment we're living through with vulnerabilities becoming a tsunami, are going to be facing a need to be able to respond within minutes of something going wrong, not days or weeks. You know, I've been in companies where where DNR, detection response might not find out about a breach or an intrusion for weeks. We can't we can't live in that world anymore. And so, like, feeding this information into your SIEM and then using AI in your SOC, you know, from any provider, whoever it is, is a huge opportunity for us leaders to to move quickly if something goes off the rails. You know, one thing that, you know, I mentioned earlier is the insider risk conversation, really was was, you know, the top priority a few years ago. It has to become, again, because an agent that's out of this, out of alignment is indistinguishable from an insider attack, and you you sort of have to be able to respond to both, within minutes, in this. new world. And then finally part of it ahead. part of it is from from a SIEM integrations. Like, we're now working, in earnest about integrating with Tom top SIM providers. I've seen, like, customers just today with Claude, they can they can build those things themselves even if they don't have their, like, most famous SIM vendor they have. And we really are working and open to feedback about how do we help streamline that process even more, but we see already great results with with customers and more ease of use kind of features coming. Absolutely. Yeah. And, this last one on containment. If you have an autonomous SOC and the autonomous SOC discovers something bad, automatic remediation is now within reach. You can turn individual users off and, you know, Claude. You could, you know, shut down the VMs. You you know, you can do whatever you need to do, with regard to containment. But as a as a product feature, we have this org wide off switch, a big red button that you can push if things are things are going off the rails. So, lots of opportunity for admins to use, things that are that are helping them with their their, governance here. Alright. Let's go on to the next the next section. For sure. I think just just before we move forward, if. anyone in the crowd has, some q and a, we're nearing some summary, and and then we'll open it up. So feel free to send, and, and we'll address them later. Amazing. Yeah. Back to you. Alright. So, yeah, so it is the case today that most security leaders are facing a huge amount of pressure to move quickly on adoption. They're getting demands from their their executive team, their board, their CEO to, say yes to internal deployment. There's very specific things that you can enable today that are based off of, like, real urgent demand and need in your organization. One of them is, you know, coding. I mean, obviously, there's so much there that can be that can be, automated. There's so so many opportunities for deployment, success there. It's pretty straightforward to to govern, exactly what's going on in in cloud code. And increasingly, co work is coming up for the productivity reasons that I mentioned earlier. So if there's a department that's asking for it more, like, using those RBAC controls and those MCPL lists to only allow that one department to make progress while you evaluate for the broader organization is a super important principle in thinking about, like, how can I make progress quickly? And, you need to think about what, what what's the what's the best way to make progress in a way that I could show truck show traction very quickly. I think we should also talk about control families for our current vendors. So if you think about, IDP and SIM, they have to change and they have to adapt to this new agentic era. The some of the IDP providers are starting to look into things like nonhuman identity as a as a way to to move the needle on, on events. I'm not gonna name names here, but, like, if you just go look out in in the ecosystem, you can definitely see that some folks are are thinking about agent identity and what nonhuman identity and and the future looks like. That can be part of the story. And then once you know which, which identities are human and nonhuman in your sim, in your detection response team's, event horizon, you can so sort of use that information to drive the the next steps for mitigation. And then, for the trust boundary, the sandboxing principle that I pointed to earlier is important part of the reasons that Anthropic was able to make a huge amount of progress in a very short amount of time, with regard to deploying, agents inside of, inside of, Infropic. We have these swarms doing different things, and they're all using VMs. They're all using ephemeral execution environments as a place for, for folks to, to to experiment, to try out ideas, to to let Claude run for days at a time. And if you have, you know, nice clear boundaries around what those are, that's a huge that's a very safe way and a very governed way to to make progress. Let's go to the next slide. Incredible. Alright. So I think in summary, and I think if if you're being, you know, asked to, make progress very quickly on agent deployments, again, you as an organization get to decide where on the risk spectrum are you from startup to highly regulated, industry. If you choose to be somewhere in the middle, then you have to measure the risk reduction. And the controls that we talked about today with regard to, like, co cowork, and associated, associated technology are all important principles and and ways to think about the the difficulties and the mitigations to the difficulties that you can measure and show to your auditors and show to your, executive risk counsel and your risk register when when, when appropriate. And that, I think it's it would be great to open it up to q and a. I'm not seeing any q and a on my screen, but it's probably Taylor. Is the is. the q. and, I can jump, I can jump. in. Great. So super helpful, Jason. Really, thanks for for the context. We'll we'll go into a few questions, and then if anyone from the crowd has additional ones, feel free to send now. But, I think, your your examples, Jason, really resonated, so people wonder you even more. They're curious about, any GRC use cases that you see either used by topic or by customers, if you can share more. Yeah. Yeah. So, we have two GRC agents today, through actually three of them. One of them is an autonomous long running risk, register updater for lack of a better word. So we have a risk register. The risk register ranks all the risk by, like, you know, impact and probability, and, from, you know, like, low to critical. And there's an agent that continually I think we have more than a 100 risks in there now that continually is trolling through Slack looking for updates to, any of the risks that are in there. So it's like on an ongoing basis just going one by one by one by one through each of the risks, searching for search terms that might be relevant to the risk, and then it pains the risk team and says, hey. I found new information which is relevant to this. Here's my new recommended risk score based on the new information that's available. It is a huge productivity boost, for the risk team. We also have a GRC agent that does, fully autonomous, first draft of all of our questionnaire, security questionnaire responses. There are many products that are trying to do this, at scale now. So Vanta and Drata, both have this in their product offerings. We built our own, and, you know, it basically uses internal information and a sanitizing process and a citation process to make sure that all the information that's in the draft of the questionnaire, responses doesn't have any hallucinations, and then a human reviews those responses before they're sent out. That reduced the, that reduced the compliance team's load by 90%. You know, we. have a lot of customers, and so a huge, huge productivity boost there. And then finally, we do have also an agent going through two of the, the questionnaire responses we get from our SaaS vendors looking for violations of our our security policies and then also subprocessor notifications. We have we have a, a internal Google group to subscribe to all the subprocessors, notifications, for all of our SaaS vendors. And anytime any of them send us a terms of service change or a subprocessor change or anything like that, our GRC agents going through those notifications and looking for something alarming. And we found in a couple of instances now where we're like, oh, no. This is bad. We need to reach out to the vendor and say we're opting out of this. Thank you very much. Super super helpful with third party risk management. I'm curious about the the last examples. I think, every enterprise is is dealing with some variant of what you said whether through agents or not. Do you get interesting, like, internal feedback either by, like, the GRC security team or other internal, like, stakeholders about it? Or is it, like, more Yeah. In this case, one of the things that we do we're doing a lot at Anthropic is every team is really trying to clodify as a as a phrase we use internally, clodify themselves. And so, it's so easy now to code even though the GRC team does not have an engineering function. Everything that I just described was built by non engineers, and, you know, it's just a testament to how easy it is to move. Now especially if you give your organization a golden path where they can deploy something like that without having to be an engineer themselves. So we have several internal platforms for hosting, agents that that don't require any engineering skills. Incredible. Another question that came up is, from a customer that, they used to be, like, API only. They use it through, like, non directly with cloud, interfaces. We can think about, like, Amazon Bedrock. We can think about Courser. Many examples come come to mind. And they're now thinking about this shift of whether should they and and what's your thought about moving to directly consuming stuff like CoWork, as an example, from Anthropic versus their third party kind of solution. I'm curious how how are you thinking about it from, from your stand? Yeah. So a couple of thoughts here. First, Anthropic, and the the third party, providers, we our goal is to achieve, feature parity across all services eventually. Now there are some some caveats. It is possible technically today to use CoWork with, AWS, for example, but it is not a a great experience. It's effectively like redirecting cloud code to, to to, Bedrock, on on the on underneath. However, the reason the reason for this is that there's, like, state stored in Cowork. Like, the reason Cowork has a nice user interface is you have, like, your chat history and, like, and then those kinds of things. And these third party API surfaces do not have a place to store chat history or or do some of the features that were associated with the chatbot or long long horizon tasks or, you know, background triggers, like, all of the things that you would want for for a cohort type user interface. So over time, I'd I'd anticipate that the third parties, you know, move more directionally, at at future parity, but we're not there yet. And, from a from a security perspective, the reason customers choose Vertex and, and Bedrock, today and and soon Azure, is that each of these cloud environments offer the ability for you to have, like, certain VPC controls or certain redaction controls that you can say as an organization, maybe in a highly regulated context, never leave, you know, certain kinds of security enclaves, with with security guarantees. Anthropic is, you know, a new hyperscaler who's on a journey to to achieve those same levels of assurances in our first party, API service. And frankly, we're not quite there yet. I, I built our security, team, you know, three years ago, having come from Google, which is I think is probably the best in the industry at this. And so we brought all of the Google, ideas on how to secure infrastructure with us when we when we started building, our security program, and we're on that journey to have nation state level defenses, for for security, privacy, and, reliability. But, there's still a little bit more work to do so I think some customers they may choose that they want to go with the third party providers and that's perfectly fine and we're there to help them with either case, depending on what they do. Yeah. Incredible. And I can say that, like, day in, day out, there is, like, a massive team here in Entropic who's working exactly on what you just said, Jason, with providing, pairing all, all different security controls that that have been built throughout the years. Some, exciting things coming up on our end. Arbuck just recently she shipped and and really talks to that, and we're really seeing that as our goal. We are also seeing that just like there's some inevitable, like, whatever is, like, first party ships faster, And. the customer experience and, for example, some customers have chosen to have, like, dual modality that some products are actually consumed first party, just because they wanted to serve some some of their populations with the best, fastest experience as it just ships out, from on top. Yep. I think, with that in mind, we exhausted, I think, the the primary questions that weren't answered prior in in some of your your answers. Obviously, Yeah. more to come. I think before we finish, any any last thoughts on your end? There's a there's a huge opportunity in front of us to be successful. The the moment that we're facing is one where, the models are going to keep getting smarter. We we you know, we're a front of the lab who has been on this journey from the beginning and the reason that models like NEATOS are possible is because the scaling laws hypothesis so far has turned out to be true. And so if you're a leader and you're listening to this and you're thinking about what, the future holds, you know, from within a FrontierLab, I can say definitively that the the scaling laws are going to keep on delivering model intelligence improvements for at least the next two years. We know we've bought the data centers. We have the data. We're training the models for improvements for at least the next two years. It's kind of hard to predict, you know, further out than that. And, because of that, as you think about what models are capable of doing today and what co work looks like and what the controls look like, think about where the models will be six months from now as you start your journey. Because if you start your journey on where the model intelligence is today, you're going to be behind by the time your program launches. So it's super, super important to be thinking about the future. And to that point, co work is a preview of a modality and a way of working with models that is much more autonomous, much more long running, long horizon tasks that have lots of, lots of freedom and autonomy to achieve, goals. And if your organization isn't able to put the right risk management controls in place to enable that with sandboxing, with, with, observability, with, you know, allow listing, you're not going to be able to benefit from the productivity boost that come from that agentic revolution. You know, something like a virtual employee, is already happening inside of Anthropic and it's going to soon be happening outside of Anthropic and so trying to plan for a world where you have virtual employees running amok, inside your organization as an insider risk is I think where where everybody as a leader should be thinking right now from a risk management Incredible. I'll share on my end that I really love the last the last point you raised, and a lot of customers are telling me. that their best path to adoption is actually looking on that journey on their end, how they start with, like, a beta program where the risk profile is much more bounded. And they also learn because this like, six months ago, this conversation would have looked very different from the opportunity landscape, the demand landscape, and being there hands on as those things come up is really, like, their path to success with, like, gradual maturity across their enterprise in security. And I could say that from our end in Anthropic, we're highly committed to delivering the most secure experiences for that AI adoption on our side. Yeah. Incredible. So, Jason, I really enjoyed for our listeners, really thank you so much for, for, the thoroughness and clarity you brought us. For everyone who listened, you'll get the recording. We have a series of white papers in our trust center. So trustananthropic.com, where we're featuring, and releasing in the next few weeks blueprints and how we're thinking about, our data security, how do we think about access management, and a lot of things that and even high level secure adoption, a lot of things that Jason spoke about today. So, please go in and and chime in. And if you have any questions, follow ups, reach to to your account teams or, to Antropic, in general, and we'll be happy to help. Amazing. Thanks you so much. thanks for listening, everybody. It was great. Thanks for hosting, Dore. Appreciate it. Yeah. Yeah. I, really, team. really enjoyed it. Bye bye. See you soon. Bye bye.