Name: Agents Don’t Ask Twice: Governing High-Risk Actions in Claude Code & Cowork
Uploaded: 2026-08-26T18:46:16.383Z
Duration: 25 min 5 s
Description: Agents Don’t Ask Twice: Governing High-Risk Actions in Claude Code & Cowork

Transcript for "Agents Don’t Ask Twice: Governing High-Risk Actions in Claude Code & Cowork": Hello, everyone. Welcome to our second installment of our August webinar series. My name is Scott Young, and I'm here with Viet, and we will be talking today about, AI agents in your third party systems, specifically securing Claude code and Claude Cowork. What we're seeing, kind of the risks that are present in organizations that we work with every day, and our tips and tricks on kinda where to start and how to ensure safe deployments and actions. So before we dive into the content, a little bit of housekeeping. There is going to be a recording available today from our presentation, and that's gonna be within twenty four hours that we'll share with you via email. And, also, this is gonna be a shorter webinar, but if we do have time, we are gonna be taking some live questions. So feel, feel free to paste any in the portal at any time, and we can either answer them via the chat or address them live at the end. And then this goes double for any feedback you have for us as well today too. So any feedback on the content, we really would love to hear from you about the session. So completing the survey at the end is very much appreciated. Alright. Let's get on to Claude security. So AI agent security is a really broad topic. There's a lot of buzzwords, a lot of challenges, a lot of solutions that you're being asked to use or resolve, and so many vendors claiming to kinda be that one silver bullet. Our view here at Obsidian Security is that true end to end AI agent security, a program that's gonna have many needs, and those needs won't be met by just one single tool. And a lot of the customers I talk to, they really understand this intuitively. One of the first questions I get on calls with customers a lot of times is usually to tell them what it is we don't do. So today, we're not here to pitch Obsidian, but to orient the conversation around today's focus, and that's on securing the actions of your agents like Claude Code and Claude Cowork and how they're taking, actions within your third party applications. So what you can see here on the left is a lot of the apps that we see most commonly and are very prevalent in our customer environments that their agents are connecting to. This is including your data warehouses like Databricks and Snowflake. It's including your CRM like Salesforce, your productivity suite such as Microsoft and Google. But beyond those, we also see Notion and Slack very routinely. And then lastly, especially with the coding platforms like Claude Code, it's infrastructure like GitHub and GitLab. So what we like to say is that agent ROI is really directly tied to the business apps users grant access to. AI is only so useful on its own. Think about the limitations of those LLM chatbots. But once you allow AI to autonomously act either with data in these third party systems or to take action that's been enabled in these third party systems systems with these critical applications, that's really how productivity and innovation take off. That's how you're able to fix bugs and code continuously or organize tables and unify records in seconds. Now with all of this does come the potential for risk. That's because agents, they're not immoral, but they are amoral. Meaning, if you grant an agent access or you give an agent a privilege or permission, they will use it if they believe it helps them achieve their goal. So any misunderstanding, it means a production table could be wiped, or it means your inbox could have things deleted. So if you don't have the right tooling or detections in place, a lot of that's gonna happen, and then you have to do investigations after the fact. Yeah. And I think just to add to that, Scott, the implementations that we do have for Claude Code and Cowork here, at Obsidian Security, you know, we provide the discovery and governance piece. So we're helping you understand your agent deployments, understanding, any risks that are relevant, to your users' behaviors, configurations across the, the, enterprise deployment. But we're also creating real time, guardrails, particularly for Claude code that secure the end results, of agents, inference and actions. So, we're actually able to block, let's say, for instance, a tool call looking to drop, a table, within a Databricks or a Snowflake. We're able to block an agent, in Claude Code from sending, a potentially sensitive information laden email to an external email domain. And so that's really our focus is helping you secure that end result, that end access, or that end action by the agent rather than trying to, infer what the intention of that agent was, which, in and of itself might be, you know, not a 100% accurate, or potentially have gaps in the way that it's implemented. And so really that is one of the big focuses for us is providing you an audible, repeatable, and, guardrails that actually help you secure, how your agents are behaving, across, your clientele. Excellent. So we talked about kind of where we're orienting the conversation today. And when we talk about specifically what is the risks of agents acting within third party applications, it's really helpful to break it down with examples. And so we kinda did a simple workflow here, but it's one that we do see routinely. So on the left, you see a user is asking ClaudeCoWork to help them clean up still data in Snowflake. But when you look under the hook of what that connection means, the privileges that the agent is granted is coming from things like service accounts. And so in this case, without knowing the right service accounts, you could be granting the agent the ability to take a destructive or an irreversible action that the user never intended when they set up that integration. So in this case, the service account allows the agent to drop a table. And if the user is submitting an ambiguous prompt, the agent, again, being amoral, just thinking it's being helpful, it could translate that, clean up these tables, and delete from production. And this is a quite common example. We do see a vast number of our customers grant their agents access to third party applications and systems. But many times when this access is granted, it's being done by the user. Think the citizen developers or folks that aren't, you know, security minded. So they're giving often much broader access than is ever needed, and they're giving excessive permissions that otherwise are creating these opportunities for risk. Around 40% of the agents that we see, a lot of times, they have these medium, high, and critical risk factors present when we initially do discovery. Meaning, the agents aren't just slightly misconfigured, but they are able to take these risky actions like publishing private data publicly, like executing commands that result in data being deleted. Just to provide some, specific examples of, the risk factors that we expose for Claude code and co work, example of one of them is actually excessive fluidograms. So, one of your employees has started up a session in a Claude CoWork Claude code, and that session has full access to their disk. So every piece of sensitive information on their, disk is now, a part of a potential, exposure. So if there was a prompt injection, if there was a stake by the agents, if there's employees that work a lot with sensitive data that you don't want being passed over to the LLM, that is a risk that we can actually spot as part of, the analysis that we do from the data that we gather from co work, and code. Another specific risk factor, is dangerous command. So if someone's, doing a, PIP install of a package from the open Internet, this is actually a process, that one of our customers has already identified, and seeing, in their deployments. And they have an internal process where those same packages are typically requested and set and delivered through MDM rather than allowing, their employees to directly install those through something like a PIP install. So the issue with some of those risk factors that we had explained and then also the example that we have here is if you're not having just the right security architecture in place, you are gonna get some visibility. Like, you're gonna be able to see some of your agents. You might be able to know kind of the systems that they're integrating into, but you're gonna be missing those risks that Viet was talking about or that's present here. And if you don't have a visibility into what risks agents are possessing and then the controls actually prevent these irreversible actions before they occur, that's where some of the challenges come from. And a lot of this is found in kind of the legacy builds of security because they were designed for a world where humans represented the majority of tool calls to your applications rather than the agents. So you'll see an IDP is really great for SSO, for MFA, and securing this human authentication, but they might be missing the content that's telling you the agent entitlements and which ones are presenting those business risks based on things like the service accounts or the permissions that they're being used to call into your applications. There's, at the network layer, with zero trust players, really good at funneling human traffic through these gateways. But app to app and now agent to app activity, that often plays out on the open Internet. It could be done using personal MCP servers with direct API links with traffic that is bypassing these gateways. And if anything is bypassing kind of those choke points, it's gonna be falling outside of their ability to secure it. And then when you think about some of the newer players coming onto the scene, they're really good at claiming to solve a lot of these gaps where they might be sharing controls that are coarse grained at best. And what we mean by that is they can solve the inventory challenge. They're able to do blast radius mapping. But if you're not correlating from the apps, the data paired with the agents, you might be lacking the ability to see an enforced policy that is much more granular and actually useful for the business. If I take you back to the snowflake example on the previous slide, you would either need to accept the risk of an agent accessing that Snowflake application and having the ability to drop a table or just sever the integration and reject it entirely, but then the business will be losing the productivity of those legitimate workflows. There's really no ability to kinda stop specific granular actions if you're only looking at one side of the equation. And then when you look at the native controls kind of under the hood for these AI hyperscalers themselves, think like Anthropic for Claude Code and Claude Cowork, They're not really security tools, and their dashboards and controls aren't oriented around showing you risk. Meaning, you won't know how to prioritize which agents actually need remediation first or which connections are safe and which ones are going to be dangerous. There's also, as of yet, is about to share some well documented evidence of agents getting creative and kinda finding these, bypasses of these native controls and policies. Yeah. So that what Scott is referencing is, you know, we've had a couple of customers, actually tell us that, you know, they set up in managed settings, a policy that blocks cURL commands or policy, that, you know, specifically requires or denialists or allowless some specific thing. But because the Claude Code and co work agents are helpful, you know, they've actively seen them, offering ways to bypass those managed settings, those particular, like, commands that have been blocked, and offering that up to the employees, as a way to kind of continue their, end mission, while also bypassing those policies. And so, for us, you know, we're looking to provide an additive, solution that allows our customers create policies that, say for instance block, external communication, you know, at the tool, level rather than at say, at the command or at a MCP, level. So really allowing you to create, policies that are granular, while also ensuring and helping you ensure that those policies aren't actively bypassed, as part of the, you know, agency to day operations. It's really important that even when you have policies in place, having the confidence that they're gonna be used and they're going to be actually run when an agent goes there. You know, you can't be, monitoring your agents twenty four seven. So knowing that the policies that you have built are gonna be working at 3AM when no one's watching what agents are doing. And that's kinda what is really important on building a secure program when it comes to AI agent security is going through these steps meticulously so that you know once agents start hitting production and these third party apps, it's the confidence that your controls and your guardrails are going to scale as agents scale across the business. So kind of the phase approach that we've been taking with a lot of our customers, it really comes in a few different, levels or kind of platforms, I guess you could say. The first one is going to be on inventory and discovery. Now what's really important for discovery is it's not just an inventory of the agents that you have existing, but it's kind of all the infrastructure that comes along with them. It's seeing what models are they using, you know, what MCP servers can they access, any skills that are there, who their owners are, and then acting their blast radius. Having that one shot view is what helps start the assessment of their risk factors and then alerting these teams to the most critical agents to start remediating and actually operationalizing security. So once you have inventory in place, that's when you move to the governance stage for Claude Code and Claude Cowork. And what this looks like is removing dangerous permissions, like the ability to drop a table. It's managing which agents can read, modify, or write sensitive information. Only the right agent can go to these sensitive files. And then it's also about rightsizing access. So only the right agents are able to touch approved systems. This is a big, important case too where if there's some type of compromise or an agent misinterprets, it's really getting the containment of their blast radius down by removing the scope and pruning the integrations that agents are not needing for their day to day workflows or are just unsanctioned. Now once you do have this, in place, the. governance program, it's really critical to have enforcements of your policies. A lot of the customers that we speak to, they kind of explain it as their 10 commandments type framework for AI agents. An AI agent shall not x, y, z pick to the policies that you wanna enforce. So having these policies documented ensures that you're not waking up to a production database gone overnight. And a flow that we recommend to our customers when building out how how these policies work is to build them and launch them, but observe and not enforce first. An example of this is that if there's a policy that is a very high risk, but it's rarely triggering, that's an easy one that you can go ahead and block those agent executions. And you're knowing that you're stopping risk, but you're not disrupting the business. But if there are policies that you've built and it's being triggered quite commonly, that's now a business case that you can take to the table, talk to the owner, talk to the department to see how you can work together to get the same value that the agent is delivering, but in a more secure manner. And that's really how security and kind of that organization is being partners for the business, where you're not there to stop workflows and cause friction, but you're able to scale AI confidently and securely. And one thing that we also have that is just as important as wanting to define what your policies are is exclusions in place. You wanna ensure that your admin's agent is gonna be governed with the same rules as your intern's agent. So kinda having these flexible policies is how you actually operationalize them. Seeing, does this actually require a human of loop approval, or am I just gonna block it outright? And so Obsidian Security is really built to take any organization, it doesn't matter your size and maturity, through this AI security journey from left to right. And we kinda have that guidance and support in place to make sure that whatever makes sense for your own organization, you can plug and play and make it happen where it makes sense to really make sure that Anthropic Claude is always gonna have safe access and safe actions when it comes to your third party applications. Thanks, Scott. I did see a question, in the chat around real life examples of policy. So I actually use this framework to kind of describe something that we saw, within one of our, you know, customer deployments. Customer onboarded into our Claude Code and Cowork solution and saw within our credential in context risk factor as part of the inventory, that, you know, some of the agents were actually reading, ZSH con ZSH configuration files, so, environment files that actually potentially contain, credentials, or other sensitive data. And from there, they actually went to our real time enforcement mechanism and created a policy, that effectively said if I see an agent trying to read a ZSH configuration file in the payload, I'm going to alert that, and send an alert to our security team. And if that happens enough, potentially I'm going to push an automation to rotate, like, force rotate keys, for that specific, individual who's running that, that set of agents within Claude Code. Another example is a bit more, I think probably more commonplace. We have another customer that as part of their policy, within their organization, they don't allow Claude Code, agents, to communicate externally, so sending emails externally. So they have a policy, in place that says, you know, if the agent is trying to use a tool that sends a message, an email external to the organization and they see that it's not to, you know, the internal email domain, that specific tool call gets blocked, or alerted, as part of their, policy controls. So those are two examples, both in real life and that we've seen. Excellent. Yes. Yeah. Alright. So I do see some questions coming in through the chat. We're gonna open it briefly to those, but I did wanna share first before we run out of time that if you did enjoy today's topic, we do have one final webinar in our August series next week. That's gonna be with Chris and Sadia here at Obsidian Security, really talking about securing your third party supply chain. So this is a core challenge that we help many of our customers with today, especially as criminal groups like Shiny Hunter and others are regularly breaching businesses and using these solar rending toll tokens to kinda access these applications. So we really hire highly recommend joining that one as well. We also have an event coming up in October in Texas called Horizon, and I would encourage you to get in touch with your Obsidian Security counterpart about joining us there. It's gonna be a lot of great details on AI agent security, third party application security, supply chain, all the topics that we're covering in these webinars, and more from our actual customers themselves too. So we have some, questions coming in from the chat here now, Viet. One of them was talking about kind of limiting access to bash shell or external, email send domains. So, maybe if there's any, more that think can talk. about kind of on the commands. Sure. I think I answered that question, kind of in my, wrap up with that last slide there. But I do want to say, with our, to answer some of the earlier questions, in terms of how we get the inventory for plot code and co work, we actually gather that through, OpenTelemetry. So Anthropic has built OpenTelemetry into their CLI and desktop applications. So setup for that is actually quite straightforward. You know, you're just grabbing a bare token, an API key from us, and, adding that to the Anthropic admin console. From there, those hotel logs, are being admitted to the, Obsidian endpoint or to your SIEM and then to Obsidian. And from there, we're actually able to build the, inventory, the risk factor analysis, as well as exposing, you know, skills hooks, plug ins, or any MCPs that are being leveraged, as part of, the, enterprise deployment for Claude Code or Cowork. We do also have a posture connector to, InfraCompass compliance API, but that provides primarily provides, like, posture data, and some high level data for, like, Cowork and Code. In terms of our real time enforcement mechanism, so that one, yes, it does allow you to limit, through the policies that we create, you know, what type of, bash or shell commands that can be run. You can also limit, based off of some of the tool parameters. Say for instance, you wanna block, a tool that is sending an email externally, specifically if one of the parameters contains, as I mentioned, a non, you know, company email domain. Those are just some examples of what you could run. You can also create policies that are pretty much targeted towards the prompt as well in Claude Code. Even though that is another piece of that because we're actually leveraging the, Claude Code hooks, so PuTol use uses in this prompt, alongside our sidecar, which is the implementation that allows us to actually enforce these policies, against Claude Code CLI and the desktop application. So it's pretty customizable, and pretty flexible in terms of what it allows you to create alerts for, create flags for, or require approval. One of the, you know, use cases that our customers have serviced up to us is, while they do allow, Claude Code agents to connect to like Snowflake or Databricks, they require that their end users, actually attest that they've backed up data before they allow, a clock code agent to run a drop table, or delete data or modify data. And that's something that you can set up as part of our real time enforcement. The sidecar implementation, so that's a light binary you deploy through MDM. It looks specifically for the Claude Code Hooks, and so it's not active outside of Claude Code. It's very much a sidecar for Claude Code. It is, Obsidian Security, specific. So we implement, we built out the SCIAR, as that light binary you deploy through MDM, but it does pair with the Claude Code Hooks, which you expose through, Claude's managed settings. So the sidecars, Obsidian Security, the managed settings and the hooks that are exposed, those are a standard to, Claude code and Claude code. Alright. So I'm gonna see if there's any more questions that roll in. But one thing I did wanna mention as well today too was we've really been talking about when it comes to, security for these Claude agents, kind of the risk factors, the access, the policies of the actions they're taking within their third party applications. There is also kind of in the news. I'm sure everyone has seen, in the past few weeks plus. All these Frontier AI models and kind of the risks that those are running from Anthropic, from OpenAI, Meta, these different hyper scaler labs and what that can do. And in next week's webinar, that's really what they are gonna be talking about as well. So if you're at all worried about those Frontier AI model risk and how you can get the containment of when those kind of infiltrations happen, I do encourage you to join next week so that you way you get the other side of the coin when it comes to what is the risk of these anthropic models coming into your applications and to your data. So I'm not seeing anything else come across right now. So I wanna give a big thank you to everyone for joining for Viet for sharing his expertise as well too. I encourage anyone to join and visit our website, obsidiansecurity.com. There's a lot more videos and other resources that are available. So if you wanna find any more information on specific to Claude's, AI agent security or the other AI agent security platforms that you might be using, like Copilot Studio. I encourage you to go check those out. And then as always, we're available to talk to an Obsidian representative for any deployment help that you need for your organization or kind of questions on how it might work for you. So thank you all again, and we'll see you next time. Thanks.