Name: Securing Claude: Playbook for Governing Coding Agents
Uploaded: 2026-09-29T17:58:06.890Z
Duration: 42 min 8 s
Description: Securing Claude: Playbook for Governing Coding Agents

Transcript for "Securing Claude: Playbook for Governing Coding Agents": Hey, everyone. We'll go ahead and get started. Today, we're gonna be talking about securing Claude, the playbook for governing coding agents. So first, a little bit about us. I'm Jackie, and I lead product for the machine learning and governance team for Rubik agents cloud. I'm joined by Arnav here who leads the ML team, on the engineering side. Arnav and I actually joined Rubik last year by the acquisition of Pretabase, an AI infrastructure start up. And as product and engineering people, we love understanding problems and coming up with solutions. So we structured our talk here today in that way. We'll talk about the problems facing enterprises with agent decoding today, talk about what we've learned solutions, and then end with a demo and some success stories. So what are we here to talk about? It feels like just yesterday when Andrew Kaparthy, former head of AI at Tesla, founding member of OpenAI, and one of the most respected names in deep learning, coined the term vibe coding in a post on 02/02/2025. He described it as a style of programming where you fully give into the vibes and forget that the code even exists. At the time, the concept of vibe coding was new but still limited in its effectiveness, with users experimenting on side projects and complaining that they end up with just a bunch of spaghetti code and bugs that were just impossible to untangle. Since then, coding agents have improved dramatically with the rise of coding agents like Cursor, Cloud Code, Replit, and now Codecs from OpenAI and huge improvements in model quality in models like Opus. Cloud Code and other coding agents has skyrocketed in adoption in the last six months. You can see in this chart showing the explosion of cloud in Cloud Code author commits really starting to escalate here at the end of twenty twenty five. And if you think this is just for start ups, think again. Coding agents are coming to enterprises. In fact, most of our customer conversations these days are centered around cloud code and other coding agents. Enterprises can no longer choose to defer adoption. In over 200 companies that we spoke with, 86% of enterprises already have agents in production, and 50% of the companies we interviewed are managing 10 or more agents in their live environments right now. This is no longer a pilot stage curiosity. The pressure for enterprises to adopt AI agents and coding agents in daily workflows and their products is mounting. And it's not just about writing code. Agents were born by giving LLMs access to tools and allowing AI to go beyond simple use cases like chat bots or summarization. Coding agents today do things like access production databases, trigger API workflows, install third party packages, interact with in external users, and leak intellectual property. Coding agents are becoming general purpose software engineering partners, not just code generators. You know, writing code is just, you know, 30% or maybe even less of what engineers are using agent coding agents to actually do. You know, these other use cases are covering the other 70%. As AI evolved from traditional ML to chatbots to agents, the blast radius has also grown at each step. In the traditional ML, you get something wrong and you get a back prediction. It's pretty contained and you have limited scope. For chatbots, when they get something wrong, you get a hallucination or maybe just something embarrassing gets published. Maybe it's reputational damage, brand damage, but it's still just words. When agents get something wrong, now you you're talking about potentially deleting data, pushing code, and opening a security vulnerability. The damage is operational, and it's real. Agents reason and execute multistep workflows autonomously and at rapid speed. One natural language instruction can trigger dozens of tool calls, API requests, and mod system modifications potentially on real production data. But what can go wrong when we give agents access? There have already been public cases of coding agents misbehaving and performing disruptive actions, which can impact end customers and businesses. For example, a replica agent deleting an entire company database or a cursor agent hallucinating a login rule and emailing users causing a lot of confusion. Hallucinations have always been a huge topic for LLMs, and now with agents, this is an even bigger issue now because we're talking about executed actions. And then there's mythos, which everyone is talking about. Why? Even strong models like Opus, powering Cloud Code, they're still coding assistance, you're steering, and the agent follows. Mythos is a step change because of its ability to sustain autonomous reasoning, which found bugs humans missed for decades and demonstrated its ability to change together complex, multi step attacks end to end. Although Mythos is currently gated to a small set of companies through Project Glasswing, GBD 5.5 is in the same capability tier and available to everyone today. And Anthropic also dropped Fable five. These are incredibly powerful capabilities that companies are starting to take advantage of. But at the same time, that means the floor for attackers has dropped as well. For example, Jason Clinton, the deputy CISO, Adam Tropic, said at Forward Rubrics conference that he thinks there are six, seven to ten months until open source models will be as good as Mythos. And he said, you know, this great quote that was like, security people, we're gonna have the worst eighteenth months at that time. It'll be quite bad. And the hard truth is this, traditional governance and access control methods don't work for coding agents. Let me give you some examples. A lot of enterprises today are really focused on identities. They spend an enormous amount of time managing access across all their applications. But everyone knows fine grained access control is really hard to get right. In practice, most orgs have gaps, overly broad roles, permissions that are never audited. Before agents, those gaps didn't matter too much. The UI was the guardrail. One customer told a story about how they discovered that employees could pull total ARR numbers through Claude CoWorks. For a public company, aggregated revenue figures are material non public information, which if leaked, would be an SEC violation. And here's the thing, CoWork just inherits your user's identity. Sellers are allowed to see their own deal numbers in Salesforce. That's totally fine. But aggregating across every opportunity in the pipeline, that was never possible before through the UI, and nobody thought to lock it down because nobody could do it before. Now with agents, all you need is one prompt, and suddenly you have a compliance exposure that had been invisible for years. And others might think you can rely on human in the loop to go on every action, make users approve every tool call before it runs. But we all know what actually happens. By the fifth prompt, you're just hitting enter. And it's because agents are getting really good, and they're getting it right more often than not. Right? But it's all it also means that this is no longer a viable security control. It's just a speed bump. Next, your EDR is great, but for agents like Cloud Code, you're often missing vital context and intent from the session. On the left, in your EDR, you might see bash executions and that cloud code was run, but you're having to make assumptions about what actually happened. On the right, you can see in the session, the user had a typical safe request to debug an installation error, and the agent starts reading a bunch of files, we can you can see on both sides. But what you can't see is that a poison dependency injected hidden instructions, found customer data on the machine, and posted it to a public gist. This is the gap. EDR investigation is time based and host based, but you're losing session continuity and user intent. You don't know if you're dealing with a malicious user or clogged code going off the rails. You don't know what data was sent out, only that bytes have left the machine. Traditionally, security teams also relied on posture based scans to detect vulnerabilities. But your CSPM, SSPM, DSPM, they all check configuration, not behavior. They can tell you this I'm role can access s three, but not an agent actually just used this role to read every file and post it to a pay site. Scans give you vulnerabilities, but oftentimes, there are just so many that you just end up ignoring them. There's also the issue of the timing gap. Even if you have a scan that runs every twenty four hours, in that time, an agent can spit up a public s three bucket, upload records, and delete the bucket in just a few minutes. Both scans come back clean, and you don't know what happened in in between. We've all seen how quickly the space of AI moves, and these pull in time snapshots of configurations or what data lives where just doesn't work for how quickly AI is changing and how quickly agents can act. These are just a few examples of the current gaps in governance and security, but adopting AI and AI agents is no longer optional for the enterprise. So we've seen the agent errors here and the failure modes are real. So here's the question every team is now asking. How do we deploy these things safely and securely without slowing them down? Our whole approach comes down to two core principles. First, we believe that runtime governance is more important than posture based governance. We want to govern what agents actually do at execution time, not just how they're configured beforehand. Second, we believe that you need to govern AI with AI. Only AI is fast and flexible enough to judge a nondeterministic agent and the actions it takes. Let's dive into them one at a time. Most governance today is posture based, and it is necessary, but it's not enough. Here's why. Posture based governance operates before anything runs. It is concerned with inspecting the static setup of your agent to ask what could possibly go wrong in production. And for agents, we're primarily con concerned with three aspects of posture. The first is identity and access. So I'm RBAC, NHI tokens, who the agent authenticate and who the agent authenticates us. Permissions and scopes. So things like which tools, what data systems they can actually touch and reach. And the third is agent configuration. So system prompts, tool definitions, your deployment settings, such as if it has a DLP layer or prompt injection layer, so things like that. And this is useful. It greatly shrinks the attack surface before anything even runs. However, there is still a blind spot. For example, you can lock down your DB and govern your NHI tokens, but those are separate pieces that don't always interoperate, and nobody has them all configured correctly. Posture also can't see what the agent actually does once it's live. And it's very noisy from a government standpoint because you don't actually know what will happen in production. You just know, like, these are the risks that exist. So So everything ultimately flows through run time, and that's where you see what actually happened. Now here's a typical agent loop. It starts when a user submits a prompt. The agent then decides whether it needs to call any tools. And if it does, it executes them and feeds the results back to itself. It can repeat that loop as many times as it needs, and it can even fan out sub agents' tool calls of their own. Once it has everything it needs, it pulls it altogether into a final response. What we want is a run time governance engine that steps into every point into this loop to intercept, reason, and return a verdict. Allow, deny, or requires approval before that step executes or return its results to the agent. And that verdict shouldn't be shallow. It should be made after reasoning over a wide range of context. Things like intent, identity, data sensitivity, what policies you have active, and even historical sessions and past agent behavior. And for sub agents, we can actually reuse the same engine recursively so that every loop is governed exactly the same way. So principle one in one line, you need run time governance to dynamically monitor and control your agents' nondeterministic real time actions as they happen. Principle two is focused on the how. You can't govern a smart, adaptive, nondeterministic agent with dumb static rules. To govern AI, you need AI. And let me show you why the old way breaks down. Let's start with this let's start with looking at a simple rule based system that has been traditionally used in governance systems to minimize malicious packet installations or supply chain attacks. The traditional approach is to use a denial list. You might block NPM install, block curl pipe to your shell, or block all w get calls entirely. And it matches exact patterns, and that's exactly the problem. The shell at its core is Turing complete. And what this means is that there are infinitely many ways to write the same command, and a denial list cannot enumerate them. And even if we could enumerate them, you you will still have to keep updating these over and over and over again, as a as, you know, AI agents and attackers discover new ways to bypass it. So it is easy to think of four simple bypasses to this denialist strategy. The first may be variable indirection, but we can assign a variable and then use that instead of calling the package name with NPM directly. We could also do an obfuscated payload strategy where we encode the package name in base 64, and then decode it into a pipe. The third and very common strategy is the write and execute style bypass, where we write the NPM install to a batch script and then run it right after. And the fourth is the fact that there's so many different verbs too and tooling gaps and possible package installation mechanisms. And it's very, very hard to keep your, list enumerated denial list up to date. So any of these walks straight past your AJAX. In general, static tools are too narrow, have a lot of false positives, and require continuous maintenance to update them. And even if you could do that, attackers really are getting more creative with the advent of AI tooling like Mithos, which makes it nearly impossible to keep up. And we believe that what you actually need is AI that judges intent and semantics, not just syntax. And and that the right unit for governance in such a system is a natural language policy. A policy is a machine and human readable rule monitored and enforced in real time. It serves as a safety envelope for nondeterministic agents that can take anonymous actions, and it defines exactly who can use what, when. And if you work in the industry for some time, this might sound a lot like a guardrail, but it's not. So policies differ from guardrails in three main ways, what they focus on, the level they operate at, and the type of risk mitigation they help with. Guardrails typically serve as a politeness layer. They keep the chat window clean and prevent toxic or bad language as well as biased outputs. Policies, on the other hand, are the permission layer, so they control the the system back end and prevent bad outcomes from taking place or being executed at all. So guardrails are primarily responsible responsible for mitigating reputational risk, but policies mitigate operational risks, financial liability, data loss, data leakage. And while guardrails are truly necessary in your agent systems or LLM systems, they don't stop an agent from doing something catastrophic. To understand this better, let's revisit the disasters that Jackie was showing you earlier. A guardrail wouldn't have saved replit because the agent wasn't being rude. You know, the agent dropped a company database during your code freeze. But if we, you know, if we had a policy, a tool blocking policy, it could have intercepted that database push because a code freeze was active, and it would have understood this because of semantics. Similarly, a compliance policy rules via trusted API before committing the airline to a payout. So these are, you know, at our core, are two principles, govern at run time and govern AI with AI. Now how might you ensure that all of your agents are secured at run time with AI in the loop? We built a system grounded in both of these tenants, and we call it the semantic AI governance engine or Sage. Sage is a new way to think about securing AI, and we believe it'll become the way organizations lock down their agents. The core intuition is that you need a system that can understand both human and agent intent in real time to secure the way agents are operating today and tomorrow. Within Sage, we let you define policies in plain text English. It can be something as simple as don't share sensitive data externally via email. We take this definition, and we convert that semantically into a policy configuration our system understands that contains things like the key definition, any key terms, and examples of instances of agent responses or human intent or two calls that are safe for violations. And then once it auto populates these key parts for you to edit, we then distill it into a proprietary small language model that runs on every input and every output. It looks at every prompt, every response, every tool call, and every tool call result, and decides in real time whether to allow, to alert, or to block. If you don't know what policies to create, Sage ships with a curated set of policies out of the box, such as those for preventing prompt injection or supply chain attacks, ensuring your agents have the minimal scope of tools required for their role, and many others. All of which have been created by us by using best practice guidelines from frameworks like OWASP, MITRE, and NIST backed by continuous evaluations. There are two additional components that make Sage especially powerful. First, it learns your agent's normal behavior and can alert of anomalies as they drift over time. So you get adaptive intelligence out of the box. Second, Sage fixes the oldest problem known with policies and governance systems. There's a high number it can have high number of false positives and negatives. With rules, you may have traditionally waited on a vendor to update the rule to catch these cases that it's currently missing or that's currently over triggering on. With Sage, we hand that control back to you. You feed in your own examples and let us know if certain alerts or behaviors were false positives or false negatives, and then we tune our models in real time. So to put simply, Sage gets better the more you use it. One of the most compelling things about Sage is actually how it's architected. We've established that you need AI to govern AI. But what we found is that you specifically need small language models purpose built for governance to do this effectively at scale. SLMs let you enforce your policies and cardinals at higher accuracy than leading large language models like GPT 5.2 and at far lower latency per response. We worked hard to ensure that Sage's p 95 latency is under a hundred milliseconds, which is critical because most of our customers want this for real time blocking and prevention. And one additional advantage of using SLMs is that they run at a fraction of the cost versus doing the same thing with the conventional LLM. We've also made sure that SIT is unified so that you can use the same run time governance across all your agents, whether they're cloud agents, endpoint agents, or custom agents. And maybe the most powerful part is that it's augmented by your own context, Your sensitive data and your identities and your policies so it can make accurate predictions in real time. Sage is the core governance engine that lives within our product, Rubrik Agent Cloud, which brings your applications, users, and agents, and models into one simple and unified platform. Rubrik Agent Cloud provides full visibility into your agents across your entire fleet of agents and their actions with triangular app and identity understanding. So you get observability out of the box. Through Sage, you're able to control them by enforcing policies, quantifying risk, and detecting agent errors in real time. And finally, in instances where agents still do destructive things, Rubik's agent cloud ships with the ability to remediate destructive actions, especially to, that affect your data, and you can apply these guardrails and optimize agent performance. So all the core things you need to have, to to really ship your agents in production with high confidence. I've told you what Sage does and why it's better than traditional governance systems. But now let me give you a peek under the hood to why this is generally difficult to build. And in particular, there's usually a trade off between getting high accuracy and getting high performance in a real time setting. So let's start with the challenge we had to solve at the point of enforcement, at the point of enforcement decision making, which was how do you do consistent enforcement when every agent platform gives us different context? And this is pretty important since we want to provide a unified pane for agent governance across the entire fleet of agents. To illustrate this problem, let's take two let's take two agent for the platforms, for example, Copilot Studio and Cloud Code. Each of these platforms expose a different slice of context. So Copilot Studio exposes chat history, the tool call and the arguments being made, any previous tool call outputs, tool definition, and then user and tenant identity. However, at the same point of enforcement, flawed only gives us the tool call and the tool arguments. So we've had to build many mechanisms to normalize all of this data across all of the agent providers that you use, into one path and then fill the context context gaps in real time so that every agent gets governed equally even though each platform handles something different. At the infrastructure level, this is deceptively hard. And while the slide has a lot of content, let me help you break let me break it down piece by piece. The core idea of the slide is that, you know, every time say it judges an action, the model reads two things. The policy definition that you've created, which are typically long, but the same every single time, and the new action, which is a user prompt, a tool call, or the agent response at checking, which is typically short and different on each request. If you take a naive approach, you might reread the whole policy book from scratch on every request when you send it to the LML, which is very expensive because policies can be very large. So instead, what we do, beneath the surface of Sage is that we let the model read this big policy book one time, keep that memory warm, and then route every request for the same policy to the same GPU replica that's already memorized them. So if request one and three share the same, you know, policy, then they both will get routed to replica one. And that's what this slide means by kv cache where routing. But now let me explain why this is generally difficult to do and get right, especially with a performance estimate of a hundred milliseconds or lesser. It's really just a balancing act that that tends to fight itself. So to reuse this cache that we keep in memory to keep it warm, you want to send identical requests from your batch to the same GPU. But if you pile too many requests onto a single GPU and it overloads, every everyone's request becomes slow. And this typically can happen if you have a large number of policies or a large number of users using the product in parallel or a large number of requests coming into the system, maybe because a single user is sending a lot of requests. So you're constantly trading cash reuse against load balancing load balancing. You wanna keep the cash warm, but you don't want to create hot spots. And you're doing all of this in line and real time because this sits in front of every agent action and has to answer with the verdict in milliseconds or it slows the agent down. On GPUs that are expensive and slow to spin up. And if you get the routing wrong, you either blow your latency or your cost. And that's the exact problem that Pradibay spent years solving with all of its customers before acquisition. And because of this clever mechanism of kv cache aware routing and load balancing, we're now able to reuse 70 to 80% of the work on each request. And we can handle hundreds of requests a second in real time. On a GPU feed that scales up and down automatically as load changes while minimizing cost. But simply, you pay to read this policy book once, not on every request. And that's what makes running an AI judge on every single action affordable at scale. Okay. So we've talked about problems with the application layer. We've talked about problems with the infrastructure layer. And it's important to think about what other problems might exist. Right? And the the maybe the the core problem is, like, how do you even know what to govern and what to write policies for? So you might have a general idea of what agents might do, but you're never sure exactly what they will. And if one misbehaves, you don't you can't really spot it by hand across hundreds of sessions that might occur every day. And let's say you write policies to govern the things you care about, out of the box or custom. You can't be sure that they're good enough for your specific needs since they will naturally evolve over time. So the system we use for governance actually has to help find these gaps for you. And so as a part of Sage, we built a feature called agent insights to close this blind spot. It reads a a real agent sessions and surfaces security gaps automatically. For example, in this screenshot, agent insights got plot code exposing AWS credentials and build log URLs across 12 sessions, plus embedded credentials and an install script and Google auth threads in a deploy script. You can click into any of these affected sessions to see exactly where the risk happened so you can quickly audit it and understand the blast radius. But insights doesn't just flag that an agent did something it shouldn't have. It drafts the policy on your behalf to stop it in the future given all the context Sage knows it has and can use at enforcement time. We made this as simple as a single click. So through insights, very quickly, unknown unknowns become governed unknowns. And this is a loop, not a one time scan. First, you want to enable best practice out of the box policies and author custom ones based on guidelines from your security team or legal team, infosec team or project team or even engineering teams internally within the company. Next, we'll want to monitor for alerts and violations created by these policies as well as the insights being generated by your governance system in real time through Sage. And you can use this information to improve your existing policies by flagging false positives and negatives or obeying the policy definition directly or even creating new policies from the gaps you just found through insights. Sage is built such that the system gets stronger the more your agents run and the more feedback you provided over time. Now let's see Sage in action. I'll hand it back to Jackie to do a live demo that demonstrates many of Sage's capabilities, such as creating natural language policies and then real time blocking for cloud code. Awesome. Thanks, Arnoff. Great. Let's take a look at Rubrik Agent Cloud. So welcome to Rubrik Agent Cloud, your centralized agentic security platform for safeguarding agents, including coding agents across your organization. I do wanna focus on the real time policy enforcement. But just to give you a quick overview, I'll go in ahead and click into cloud code here. RACC helps you discover agents across all agents across your organization, see what tools, applications, and MTC servers they have access to. We support other connection methods as well. Maybe if you're using, building custom agents with an AI gateway like LightLM or, agent builder platforms like, Microsoft Copilot Studio. We also support those as well. And then we also support, a variety of coding agents such as Quad Code or Codex or GitHub Copilot through our MDM, integration as well as the compliance API. Once you have all of those connected, this then populates your various inventories, like your agent inventory, tool inventory, identities, MCP servers, so on and so forth. And then for runtime governance, we have all your session logs. Here you can view all of the conversations and get a few sense of all the alerts, and violations of all your policies. Cool. I'm gonna jump over to policies here really quick. So here you'll have access to, our expertise out of the box via predefined, week what we call system policies. We have them shipped in a number of policy packs, like agent decoding security or compliance. And so you have these out of the box available, and these map to, again, kinda your popular security frameworks like Miner and NIST and OWASP. For the purposes of the demo today, we'll go ahead and focus on creating a custom policy, through the natural language policy creation flow. So we'll go ahead and define a custom policy for our organization in natural language. Here, I'll go and click create policy. For example, one policy that, you know, we here have here today at Rubik as well, our own security team want to implement, it was to prevent agents from posting gist. So here I'll enter the policy in natural language. GitHub gist are you know, they can be used by coding agents for data exfiltration. And one of the common misconceptions is that even a quote, unquote private gist is actually always still accessible via the URL, so it's actually not, private. Our security team was particularly concerned about this use case because coding agents, will often suggest posting to just there have been many, many cases where a cloud code runs into an access issue and decides to post a to GitHub gist as a workaround. And you might think that you can prevent this with human human loop approvals and things like that, but, you know, ask anyone who uses coding agents. You're probably not reading every single message and every tool will call that carefully. So that policy I entered here, gets fully flushed out into a policy definition. You have sections such as, the goal and instructions, the key definitions, examples of safe and violated behaviors, as well as reference examples. You get a policy strength score and recommendations for how to improve that policy, such as maybe clarifying particular terminology for your organization. The scoring itself is based on criteria such as clarity, specificity, and actionability. You can also run single examples, to test how well your policy definition is being defined, and we also added the ability to do, back testing as well on previous sessions. So I'll go ahead and close this for now since I've created and iterated on a GIST policy before. So here we're looking at, a particular here's the gist policy that I've edited before, and you can see the full policy definition fully flushed out, and that I've already set the policy definition to block tool calls. So let's go ahead and see that in action. Here, in my, directory, I have a file called, twenty twenty six g two. It has some fake customer names, and I'll try to get Claude to post it to a GIST. Cool. These options, I don't like them. I want a GIST. Right. And it looks like it was blocked by Rupert Agent Cloud. And this is great. Right? You know, rather than catching the file later in, like, a scan which checks for just, you know, mentioning the word Rubrik or something, we're actually blocking it here in line, via that natural language policy that we just took a look at, via that small language model that we're using in the platform. And I know this is sort of a simple example and, you know, Claude is first recommending that I just do it myself. But a lot of times what happens is that Claude is just posting just in a long stream of a conversation, and without the user really paying attention. Maybe they ask for approval or not, but it's sort of getting lost in a a long string of actions. What's also really fun about, this particular policy, if I jump back to the slides, is that, when we launched it here internally at Rubrik, it even caught a case where someone was using, a computer use tool. Sage was actually able to recognize from previous messages that web page coordinates are actually for a create new gist button, which is pretty crazy because I definitely would have never thought of that method. So really showing that, you know, doing just a simple GA's gist create rule, doesn't catch all the cases, to really capture the intent of what you want in this policy. I wanna also show how we can block user prompts. So I'll go ahead and jump back to the policies. So we have a policy, let's say, for credentials, and I'm gonna go ahead and set right now, it's set to, monitor. So if I start a new Cloud Code session here. So for example, you might wanna block user prompts like preventing users from sharing secrets or credentials with LN providers. So, like, a common developer prompt might be something like, you know, help me set up my a AWS CLI, and here's my access token. Go ahead and run. You can see it's percolating there, which means it's already reading my, my prompt, my token. So I'm gonna go ahead and stop it before it actually starts to try setting up the CLI. Jumping back to the policies, I'm gonna go ahead and set this policy to block. And now let's try that again. And great. I can see that it's here. It's blocked by Rubrik Agent Cloud, and I can't now you're you're preventing, those credentials from being shared, with the model provider. So let me jump back to the slides. I wanna talk through a few, examples of some case studies as well. I pulled together a few real case studies, that we've had from customers, across the various personas, which I think really kinda help demonstrate the variety of case use cases that you can use when it comes to governing AI with AI. So first, we had a director of infrastructure security come to us concerns with about coding agents that were exiting executing Python dash c, with this quote, you know, Python dash c. The cod code generates Python on the fly, and a lot of times they'll run it, via Python dash c. It, you know, shows a wall of code, and the user just hits enter and, you know, and the users are definitely just hitting enter. We can define a policy like, you know, analyze code the code itself that's being run and block any code from being executed that, is a potentially potential security risk. And I love this quote. We actually caught a few instances of scripts we didn't want to run, and I like this, you know, quote for why Sage you know, you they can block Python dash c himself, but, you know, I want Rubrik Asian Cloud to read the code, determine the actual intent, and block based on what you're trying to do. You know, just blocking Python test c can be very disruptive, and so really understanding the intent of the actual code that's being run is really important here. Another great use case for Sage, a lot of, you know, companies and IT leaders are excited about rolling out agent decoding, that we all can see those, those costs really skyrocketing. So an IT leader we worked with has this company policy that employees should not be using their work credentials for personal use, but there's no way to actually know if that was policy is being followed. So we use Sage to actually add a custom policy and caught cases of employees using cloud code for personal projects like portfolio sites or, you know, writing cover letters and things like that. So it's another great use case for, why this is, you know, another exam great example of why this is only possible for when you're using AI to govern AI. And lastly, we often work with legal and GRC teams who are concerned about AI compliance when rolling out agent tools. The a EU AI act in particular has one section which talks about not using AI for evaluating candidates. After enabling the policy, we actually caught a case of employee using Cloud Cowork to rank and recommend candidates. And you could easily use, you know, CloudCo to do the same exact task. Right? Because it's not just blocked limited to coding. You know, this type of policy is quite nuanced. And with the wrong detection system, you would either have a lot of false negatives, miss a lot of cases, or also just the reverse, which is having a lot of false positives. So in summary, what can you do now? I would say start with just getting an inventory of all the agents in your organization, including those those coding agents, and what are all the tools, applications, skills, MCP servers, plugins. What are those coding agents actually accessing? And then leverage those best security, best practices, and frameworks and start edit auditing what are those agents doing at run time and logging, having an on audit trail for what those agents are doing. Next, start by blocking start actually blocking risky agent behavior. You can start to fine tune your policies and use more sophisticated models of detection to help you discover the unknown unknowns that are hidden in your sessions. And you'll also wanna bake agentic security practices into your existing SOC and IT operations. What does that look like in six months? I would say great. Looks like they have to deliver measurable ROI from coding agents and really having a cyber resiliency solution for AI and AI agents that's able to adapt and evolve autonomously. Thanks for joining us today. I hope you learned a lot. Thanks for your time.