Really, any coding agent our shop didn't write itself, though in those cases the smiting might be less theatrical than if you literally ran a yolo-mode agent on a prod server.
> 1) Have faith (always run it with 'dangerously skip permissions', even on important resources like your production server and your main dev machine. If you're from infosec, you might want to stop reading now—the rest of this article isn't going to make you any happier. Keep your medication close at hand if you decide to continue).
Other people's blasé risk profile -- or worse, willful denial of risk -- is indeed our problem. Why?
1. Externalities, including but not limited to: security breaches, service abuse, resource depletion, and (repeat after me -- even if you only think the probability is 0.01%, such things do happen) letting a rogue AI get out of the box. *
2. Social contagion. Even if one person did think about the risks and deem them acceptable, other people all too often will just blindly copy the bottom-line result. We are only slightly evolved apes after all.
Ultimately, this is about probabilities. How many people actually take the fifteen minutes to thoughtfully build an attack tree? Or even one minute to listen to that voice in their head that says "yeah, I probably should think about this weird feeling I have ... ... maybe my subconscious mind is trying to tell me something ... maybe there is indeed a rational basis for my discomfort ... maybe there is a reason why people are warning me about this."
Remember, this isn't only about "your freedom" or "your appetite for risk" or some principle of your political philosophy that says no one should tell you what to do. What you do can affect other people, so you need to own that. Even if you don't care what other people think, that won't stop a backlash.
But I think I'm getting to the point where "If I'd let an intern/junior dev have access while I'm watching then I'm probably OK with Claude having it too"
The thing that annoys me about a lot of infosec people is that they have all of these opinions about bad practice that are removed from the actual 'what's the worst that could happen here' impact/risk factor.
I'm not running lfg on a control tower that's landing boeing 737s, but for a simple non-critical CRUD app? Probably the tradeoff is worth it.
Back when I worked at an F500 it was normal practice to give early-stage developers access to a "research" environment where our normal security policies were not applied. (Of course the flipside was that that "research" environment didn't have any access to confidential data etc., but it was a "prod" environment for most purposes)
Maybe my wrapper project is interesting for you? https://github.com/release-engineers/agent-sandbox It's to keep Claude Code containerized with a copy of the workspace and a firewall/proxy so it can only access certain sites. With my workflow I don't really risk much, and the "output" is a .patch file I can inspect before I git apply it.
https://github.com/anthropics/claude-code-security-review
The new command is something like /security-review and should be in the loop before any PR or commit especially for this type of web-facing app, which Claude Code makes easy.
This prompt will make Claude's code generally beat not just intern code, but probably most devs' code, for security mindedness:
https://raw.githubusercontent.com/anthropics/claude-code-sec...
The false positives judge shown here is particularly well done.
// Beyond that, run tools such as Kusari or Snyk. It's unlikely most shops have security engineers as qualified as these focused tools are becoming.