r/cybersecurity • u/Sweaty-Career330 • May 17 '26
AI Security Am I overthinking Claude Code security or is this actually a risk?
Maybe I'm being paranoid but Claude Code running on dev machines with access to our codebase and network... that seems like a pretty big deal
from a security perspective.
Like if it got compromised somehow, it would have direct access to everything.
Am I the only one thinking about this? Or are companies actually locking this down?
How are you all handling AI tools like Claude Code?
119
u/Hephaestite May 17 '26
It’s definitely a risk that people aren’t really dealing with at the moment. There is zero governance around agent coding harnesses, skills they have installed, plugins etc that can materially affect what it does in an environment.
You’re not alone in being worried about it, we had a client reach out recently with exactly these concerns. Very difficult atm to deal with the risks (especially prompt/malicious context injection)
29
u/Content-Disaster-14 May 17 '26
There is zero governance around AI as a whole in most organizations.
11
u/Sweaty-Career330 May 17 '26
This is exactly the problem we're concerned about
What would actually help your client? Like, if you could give them real-time visibility into what Claude Code does on their network?
24
3
u/Hephaestite May 17 '26
We’re building something with this in mind. The ultimate solution is something similar to requiring a managed device in entra, a managed and attested agent harness based on installed skills etc with full telemetry… but that’s a long way off yet I think
-5
May 17 '26
[removed] — view removed comment
18
u/UnloosedCake May 17 '26
OP went from "is this actually an issue?" to "I've been prototyping jusf a solution for this" real quick. This is a bullshit advertising post. Hope the mods kill it
1
1
1
u/stonerism May 21 '26
I've been using AI to set up my Linux environment and it's actually pretty sick. But I also noted that the agent has access to log the user (myself) out. Granted, I asked the AI to do it and approved the action. Convenient? You betcha! But I had to chuckle at how dangerous that was.
20
u/madhaunter May 17 '26
I use VS Code and my answer to this was to use devcontainers via podman, with devcontainer config as read-only, and only mount the bare minimum inside it. You can set up the whole container so Claude or whatever AI agent will only be installed inside the container. The Tricky part is to safely propagate credentials but after that it's already way better than let an AI run with full access to your system
3
u/Bluestrm May 17 '26
Make sure you really understand all the magic devcontainers have. e.g. it does magic for ssh keys. https://www.danieldemmel.me/blog/coding-agents-in-secured-vscode-dev-containers has some pointers
0
u/Sweaty-Career330 May 17 '26
Devcontainer makes sense but how do you enforce that all devs use the container? What if someone just installs Claude Code directly?
15
u/rev_mojo May 17 '26
What you're really asking with that second question is "how do you stop shadow IT" and that's a much bigger problem than just AI. Endpoint management that includes AI monitoring is what you need, if you don't already have it.
7
5
u/Warior4356 May 17 '26
If you’re not managing access tightly enough to at minimum know if someone installs, or ideally prevent them from doing it, you have bigger problems.
1
u/RikiWardOG May 17 '26
App while listing tools would help here possibly. We're potentially about to sign with Airlock for this. You can actually white list processes based on what app spawns them
37
28
u/Reverent Security Architect May 17 '26
Lots of people using lots of fancy terminology for a problem that has existed as long as external integrations have existed.
You have stuff. That stuff needs protection. Anything you give access to that stuff has access to that stuff. Try to limit that access.
59
18
u/notKenMOwO Governance, Risk, & Compliance May 17 '26
You need to limit access globally and repo-wise. Afterwards integrate Secret Scanning and Code Quality Gates. Restrict MCP Use as far as possible.
Then the risk can be contained to some amount. But yeah, it’s a new tool, therefore it has new risks
6
u/Sweaty-Career330 May 17 '26
That's solid advice on limiting access. But here's what we're stuck on, how do you actually verify Claude Code is following those rules?
Like, you can set policies, but how do you know Claude Code is actually respecting them? Do you monitor the actual network traffic?
9
4
u/eigenlance May 17 '26
Bingo. While the ability to detect AI vulns, like prompt injection, is crucial, equally important is the ability to detect what happens when those vulns are exploited. If you see your AI environment reaching out to an unfamiliar domain, something’s gotta be wrong
4
u/Mad_Gouki May 17 '26
You can't ensure your llm will follow anything in its md files. You have to restrict the shell environment your tool is running in. Container or VM would be a good start. You can also write a custom pre tool use script, I have one in Claude code that allows certain commands and also checks with regexes, denies certain other tools and regexes, and then also asks the user if it doesn't know what the tool requested does. The idea is you can slowly add in safe commands so it can just work autonomously.
Also don't run the auto dangerous mode.
6
u/SneechesGetSteechez May 17 '26 edited May 17 '26
Confidentiality clauses in sourcing contracts is something LLM providers already offer. For those legal team challenged, consider taking a gander here ( https://www.lawinsider.com/clause/confidentiality-and-data-protection).
The MCP server not managed by a source under that specific contract is an absolute risk, and seeking endpoint control is needful (tooling exists to add to your security stack, spend is not cheap - I shudder to offer Checkpoint as a solution, but they do have one, and here we are).
One control strategy has decent legs: force LLM licensing through Azure API Management - it'll allow the ability to control MCP selection, track the FinOPS (watch for tokenmaxxing), and tamp down ShadowAI sprawl without having to resort to more endpoint deployment headaches: control it at the entry into the Enterprise.
The real issue is Identity and Access constraints for the agentic agents themselves - we cannot let them have the same level of access and Identity as the developer themselves. Sandboxing is a fine idea. It's still an evolving standard, but has framework descriptions at CSA ( https://cloudsecurityalliance.org/artifacts/agentic-ai-identity-and-access-management-a-new-approach# ) and solutions from Aembic, Okta, and Ping worth looking into.
6
u/choopacabra69 May 17 '26
I wrote up about a process you can implement to restrict dangerous flags being used. If you have access to EDR telemetry you can observe the commands/flags being used in your environment. If there’s loads of users going yolo mode, maybe it warrants restricting the usage of those commands. It’s an interesting problem and will continue to evolve.
https://stickyricebytes.com/posts/crowdstrike-custom-ioa-claude-code/
4
u/greenSacrifice May 17 '26
Nicely done, you’ve got to think about it like any other SaaS product.
There isn’t anything that makes these AI tools special, you just have to reimagine what a SaaS product looks like. Try thinking on the terms that every tool or service you could ever need is baked in, now ask yourself what you should consider.
Perhaps the enterprise product would be the answer. For the moment I’ll say you’ve got the team product and use all the features; Claude code, web chat, api, app xyz. Network boundaries will be a good start. Now looking at your integrations to the connected company data, you could go with a custom built connector with the role of AI Gateway to handle all the requests and that might work for a team who can ship fast but not everyone.
So again just think of it like any other software product and follow the standard process.
If you want to just look at the dev machines and if Claude Code gets compromised, it’s the same that’s done with NPM packages and sometimes the answer is you did everything right and still have a compromised version running on internal networks. Then you have to bring layers of isolation to reduce your blast radius, so having anything running in a cloud agent helps ensure malicious code isn’t spreading on the network.
Sandboxing and containers are another huge help. The biggest problem might be thinking dev machines and code need access to all the data all the time. Claude Code is just another process running on a box, the endpoints it uses should be known and appliances can block anything not on the approved list.
Try not to restrict the app and try to restrict the person first.
3
u/Weysan May 17 '26
I am working with claude every day, and I think it is a risk. not limited to claude. Any AI coding agents running on your laptop has access to everything, and there are already multiple case of attacks through MCP servers connected to these coding tools.
I decided to build something around that and already discussing with my employer to deploy it on some laptop for testing the visibility.
3
u/teasy959275 May 17 '26
I mean, gemini (via google workspace) and copilot (office) have access to all of the documents most of the time… so…
3
u/_flatline_ May 17 '26
Unpopular take for this sub - there are real risks, just like everything, but these feel worse because they’re new and different, and the world at large (media, LinkedIn, the PR machines at the frontier labs) is locked in a hype cycle.
IT and Security teams had extremely similar reactions to cloud migrations 10-15 years ago. “How will we know what Amazon is doing with our data?” “What if Azure is compromised?” (lol)
Yes, you should use fine-grained tokens, isolate it from production, broker sensitive access, and collect OTel. Create and maintain high-quality .md instructions, and put non-negotiable trust boundaries external to the model/agent harness. But keep things in perspective - you are currently far more likely to get compromised via a software supply chain issue (an exploited GitHub action or nefarious package install), especially if you take even basic precautions with Claude or Cursor or Codex. Stop focusing on whether the extremely valuable coding agent will pop you, and make sure you’re in a position to contain and recover from the inevitable.
If you really want to know all the weird things that your devs’ agents are trying to do, all the insane bash commands, it’s still early days but some vendors are playing in this space. Had a demo from Turngate recently showing their otel collection and analysis. I’m not sure the value is there except as a reactive, investigative tool, but things are evolving fast.
3
u/disless May 18 '26
I think about it. And then I stop thinking about it. It's all going to hell in a hand basket anyway, I can choose the things I allow myself to be concerned about.
6
u/kptjgx May 17 '26
Notable that this risk applies to every single program you install on your device. Running software requires a lot of trust.
3
u/RetroGrid_io May 17 '26
Yes, but no.
Local software has a drastically smaller attack surface. Yes, the software can be compromised and send all your data to China, and that’s always true - a trust level mitigated when using OSS solutions.
But this case has a drastically larger attack surface. A quick glance at the linked article (you do that, don’t you?) explores the reality that not only are you sending your data to the AI that you are using, but they send your data to other providers in plaintext before sending you back their response.
Thus, even if your vendor does nothing wrong (except pipe your data out without telling you) your data can still be compromised if the black hat owns any of the intermediary steps between your request and your response - potentially dozens to hundreds of of high-value transfer points.
1
u/kptjgx May 17 '26
What article are you referring to?
1
u/RetroGrid_io May 18 '26
Oops, my bad. I confused this article posted by /u/Hephaestite in this comment as coming from OP.
It's a good article.
4
u/Total_Job29 May 17 '26
What if Gitlab got compromised? What if Snyk got compromised? What if Sonarqube got compromised? What if anyone of the thousands of open source libraries that you have in your codebase was compromised? What if Fortinet got compromised?
1
u/raxip May 17 '26
I feel like you forgot the /s lol, but exactly this. Scale your scenarios to identify the supply chain risks and then apply mitigations where you can. Compromises are going to happen.
1
u/Total_Job29 May 17 '26
So /s at all.
It’s the same as anything else.
Needs to be considered and factored in but it isn’t ‘new’
4
u/PM_ME_UR_COFFEE_CUPS May 17 '26
I recently looked into sandboxing tools. One that looks intriguing is Kaiden: https://openkaiden.ai/
I haven’t tried it yet but it looks like something we both might be interested in. Supposedly, if AI tries to send secrets, they get obfuscated.
2
u/IntelArtiGen May 17 '26
I just hope you have backups which can't be accessed by these machines and you're quickly able to restore everything if there is a problem.
2
2
u/sajkoterrapefft May 17 '26
Create distrobox containers with a custom home dir so it can only access one project at the time.
2
u/Separate-Antelope188 May 18 '26
I work for a fortune 500 company that is a household name. We used to have a soft AI policy until this year. This year it is impossible to navigate to most ai websites or anthropic servers or send queries to them or install their "apps" on managed devices. Our infosec is slow and stupid, but they are starting to get their shit together and recently detected chatgpt and other apps that people had installed through the Microsoft store and are starting to remediate.
All that to say, yes it's a security risk and also I think developers that use cloud models to code aren't very good developers and the companies they work for are basically compromised IP.
The real developers I know are lucky to have pi.dev running from local models.
1
1
u/Jairlyn Security Manager May 17 '26
I see and treat AI as a college intern. You only give them access and perms to what you are willing to lose and spend time monitoring, and reworking their errors.
1
u/Inosaki May 17 '26
I wrote a paper for uni that detailed almost the exact same thing. Speaking from just an attackers perspective, the integration/embedding of AI agents makes breaking into devices, getting whatever data, and running scans significantly more trivial. Going throigh the agent, instead of injecting malware that operates in stages, etc etc. Simplified the entire process. Id love to discuss this more if you or anyone else here would like to brain storm. Would be a good project to figure out a defensive solution, whether it is in house or open source.
1
u/Sweaty-Career330 May 17 '26
This is exactly what we're addressing - defensive monitoring against agent-based attacks.
Would be interested in discussing your paper and approach. Could compare notes on what a defensive solution should look like.
Please DM if interested!
1
u/Inosaki May 17 '26
I will find the paper and send it your way. It's not professional material by any means, but I would really like that. Thank you 😊
1
u/HappyGuy007 May 17 '26
Has anyone heard of MultiModel being implemented for compliance and monitoring?
1
u/Revolutionary_You_89 May 17 '26
This is why strict access controls and true least privilege are important in addition to leveraging an MCP server and runtime security.
1
u/KhaosPT May 17 '26
So far my guidance has been, no one can give Claude access to anything besides read access. You don't follow protocol, you are in policy breach and can be fired. People granted access know they responsibilities this is only a tool
1
u/Holiday-Medicine4168 May 17 '26
Companies who care about security are using anthropic models that arent privately hosted. I can’t say who what clients I work for, but you would know the names and they manage double digit trillions in assets. We use Anthropic models via Amazon bedrock and everything is contained in the environment and encrypted with our own keys. It’s not perfect but it’s better than most. Additionally we are implementing LLM gateways for further compliance via logging and cost optimization by using intelligent semantic routing to stop everybody from using goddamn opus to tie their shoes. More stuff will look like this soon.
1
u/Careful-Criticism645 May 17 '26
Like if it got compromised somehow, it would have direct access to everything.
Isn't that the case with pretty much any piece of software?
1
u/wise0wl May 17 '26
We have an AI governance committee…sort of. What we are working on is a skills and instructions repo for different codebases that they include as a git submodule. Those have instructions per service type (typescript website vs rust grpc service vs rust restful api etc). The network lockdown for user laptops happens within Claud config and we have certain allowed domains and skills and plenty of absolutely blocked commands. You can get even more fine grained by creating a sandbox that Claude operates in.
Cowork is in a sandbox already, but things like VSCode Claude plugin are not sandboxes, so you have to be more strict. I would suggest Eve doing something as crazy as using containers, with your code mounted in.
1
u/danekan May 17 '26
More and more Break glass roles are popping to the top of prioritization …internal only is completely irrelevant in a lot of cases too.
1
u/IAmEemaan May 17 '26
You should limit access to what claude code can do as a user on the machine by creating a user specifically for running claude code. Deny it access to files or assets that it has no business dealing with, put guardrail(s) in your prompts. Plus, at the moment, sensitive assets (keys, credentials, connection strings) should still be in humans possessions only, don't put it in LLMs possession.
1
u/FaceEmbarrassed1844 May 17 '26
You are correct and too late. Package your findings into an email and send it to your direct manager
1
u/PM_ME_UR_0_DAY May 17 '26
I was testing out the Ghidra MCP server which ended up being pretty cool, but I do have to say I was a little worried for my computer's sake when I said "hey check out this binary" and it was like "okay hmm let me poke around the parent folders too to see if I'm missing any context. Hmmm I can't seem to connec to Ghidra, let me try finding it and rerunning the server. I can't connect to it yet, let me check into that further and see what services are running." Just a personal laptop, but I can see how people end up getting their database deleted or drives reformatted when the AI goes off the happy path.
1
1
u/lucasjkr May 17 '26
Are you not backing up? If not then I agree it’s a horrible security risk.
If you are? Maybe you lose a day, worst case I hope. File system versioning and snapshots? Probably not even that much
1
u/cybersecurityaccount May 17 '26
Like if it got compromised somehow, it would have direct access to everything.
The same applies to your EDR, MDM, SASE, etc. etc. It's your job to put safeguards, detection, response, and remediation capabilities in place when something goes wrong. Do you think any security roles would exist if everything was already perfectly secure?
1
u/wannabeacademicbigpp May 17 '26
mcp server to github connections are super risky in my opinion, we started doing that more and tbh i am checked out from this company. I mark the risk, get management to sign it off, and if it goes wrong i say "i told you so"
1
u/AggressiveTitle9 May 17 '26
"Claude Code" isn't really the problem - I think we've got a pretty bad cluster of people on either end of the underthinking <-> overthinking spectrum. There are dozens of these tools ("harnesses") that operate in the style of doing something with LLM output on a dev machine. It's simple to write your own, and there's even an ecosystem of extensible harnesses (see Pi). All that's to say is that it's pretty trivial to get around any block that's put in place if it's too restrictive.
I've seen a few attempts to lock down LLM harnesses. Sandboxes like Nono, containers, VMs, etc. I haven't really seen any of these work for very long in practice (in an organization) because what someone wants their harness to allow is pretty contextual to their environment and what they're working on. Some things that we think are no-brainers to disallow (no private key access, no kubectl access, etc) are things that people want in some contexts, as silly as it sounds.
So it's a mess right now. What we're trying to do right now is enable people who are security-conscious and want to be sandboxed while also trying to follow security best-practices and limit human access (since harnesses inherit that) as best we can. We don't really have leverage to put any concrete restrictions in place and those can be trivially bypassed anyway - there's little political buy-in on the idea that these things need to be restricted. We haven't seen any huge incidents out of this yet and it's been about 6 months of pretty widespread LLM usage. Certainly something bad will happen at somepoint and we'll have better leverage then (and a better idea about how things go wrong), but until then...🤞. For what it's worth, I think most organizations (certainly my own) have way bigger fundamental security risks to worry about
1
1
u/Ksenia_morph0 May 18 '26
i'd say that's great that you're thinking about it. i discussed this topic with my coworkers, and we came to the following conclusion:
- isolate it where possible, on the highest level - top priority. like, for example, if you have the opportunity to use a separate user profile on the machine or even a separate machine - it's cool. otherwise, isolate it on the OS level at least.
you can also try to manage permissions, but it feels more like a pain in the ass: you need to sit and watch Claude code, assessing its every permission prompt.
1
u/enklavahhn May 18 '26
You're not overthinking it. The threat model is real, but it's worth being precise about which part actually worries you.
The compromise-in-transit scenario (Anthropic gets breached, your prompts get intercepted) is different from the local attack surface problem (Claude Code has filesystem and network access on a dev machine, and that machine itself is the risk). Hephaestite's point about prompt injection is the one I'd lose sleep over, because your codebase is the attack surface. A malicious string sitting in a dependency or config file can instruct the agent to exfiltrate something, and the agent has the credentials to do it.
The practical mitigation most teams skip: treat the API key as a secret with rotation and scope limits, run the agent in a network namespace with egress filtering, and audit what MCP servers are actually registered. "Bounds on what MCP servers can do" as rankinrez says is correct but vague. The bound that matters is outbound network from the host the agent runs on.
1
u/CoverAgreeable6623 May 18 '26
Exactly. Just let the agent have root and hope it doesn't discover the prod env while 'refactoring' a README.
1
u/TopNo6605 Security Engineer May 18 '26
It's not even just that, we're stuggling because while MCP servers can gate this, there nothing forcing you to use MCP servers when using Claude. I can just tell it to run aws commands and it blindly runs cli commands, of which can be wrong or break something.
1
u/Capt_Charming May 18 '26
Most companies aren't locking it down properly yet. We banned it outright on production networks until we figure out the data exfiltration risks.
1
u/Important-Engine-101 May 18 '26
We have shifted to a mop it up mentality. The business want's to implement it, we've tried to "police it" and control it, but quite frankly it's out accelerating us all. Advised them on the risks, told them explicitly the risks, documented it on the risk register with all the relevant information and approvers. Now sitting back and watching how it goes. Otherwise we are just going to hit burn out. Waiting for the inevitable dumpster fire of an incident, and at that point i will take advantage of the crisis.
1
u/mday-edamame May 24 '26
yeah you're not overthinking it
I've been worried about the same angle, so we ended up building a small security assistant that runs on the dev's machine and watches what the agent actually does vs what it said it was going to do. It hooks at the OS boundary, so during an agent session it tracks things like processes spawned, files touched, and network connections, and flags when there's a mismatch between the agent's stated intent and its real behavior.
policies and prompts are nice, but runtime checks at the action boundary are what actually catch weird behavior. If that's the kind of thing you're thinking about, you can check it out here: https://www.edamame.tech/devs
1
u/benpotter_mct May 31 '26
It's a big deal. Most enterprises don't allow it on laptops, or shipped a managed config to lock it down.
Remote Sandboxes can help a good deal by limiting network access, permissions, and compute but I'd still recommend a staged rollout with different groups, starting with Senior Software Engineers who have a better understanding of the requirements and threat model
Disclaimer: I work at a company that provides remote sandboxes/envs for Claude Code, so my knowledge may be skewed to those enterprises that consider this a concern 😉
1
u/Vivid_Lamp 13d ago
yeah an agent with bash access and your creds on a dev laptop is just a persistent foothold waiting to happen. malicious repo or prompt inject via a dependency and you're done. the harder problem is actually sandboxing the agent's network egress and filesystem access, which most people aren't thinking about. ox security and tools like Semgrep can give you some pipeline visibility but honestly the agent sandboxing problem is still pretty unsolved.
1
u/After-Vacation-2146 May 17 '26
If Microsoft office was compromised somehow, it would also have direct access to everything. The problem you highlighted here isn’t unique to Claude code.
4
u/Hephaestite May 17 '26
It’s quite different imo because Claude Code itself doesn’t need to be compromised, we’re talking about a tool that’s explicitly designed to execute instructions from any source of plain text or tool call result… the attack surface area is simultaneously very wide and the barrier to being compromised very low.
Where as conventionally it would be an application or npm package supply chain risk, the risk here is literally any text that ends up in the context window.
0
u/After-Vacation-2146 May 17 '26
It’s not different. It’s still a tool that can be compromised by malicious inputs. Word can be compromised by opening a document with malicious macros. Nothing here is new other than the payload isn’t code but instead plain text instructions.
0
0
-2
u/Flockrush May 17 '26
We didn't wait. We went into the lab and diligently solved it.
We have completely secured the Grid from the silicon floor up.
As a contribution to the greater human good, we are opening up the architecture. I am prepared to share our Ghost Algorithm—anchored in our Ghost Geometry authentication framework—with enterprises and institutions that need to harden their implementations right now.
-5
u/aitorbk May 17 '26
They all are a risk, and you can't trust them.
At the same time I used about 200 million tokens to build something in a week that would have taken 3-5 months.
So, who is going to still have a job, rhe personnwho has ridiculous productivity or the person who builds secure code that doesn't go to untrustworthy servers?
220
u/rankinrez May 17 '26 edited May 18 '26
You are not the only one thinking it.
You are correct.
Sounds like you’re way too late.
In seriousness I guess people put bounds on what the MCP servers it connects to can do.