You run a coding agent with no permissions checks on a production server anywhere I'm involved in security and I will strike down upon thee with great vengeance and furious anger.

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.

▲

sylens 7 days ago | parent | next [-]

Author kindly asked you to stop reading:

> 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).

	▲	xpe 6 days ago \| parent [-]
		"Here is how you build a self-replicating unknown-impact protein structure that will survive in the wild. If this bothers you, stop reading". 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. * https://www.aisafetybook.com/textbook/rogue-ai

▲

sixhobbits 7 days ago | parent | prev | next [-]

Gotta exaggerate a bit to get attention :D

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.

▲

Thrymr 7 days ago | parent | next [-]

Why in the world would you advocate explicitly for letting it run on production servers, rather than teaching it how to test in a development or staging environment like you would with a junior engineer?

▲

nvch 7 days ago | parent | prev | next [-]

We allow juniors in risky areas because that’s how they will learn. Not the case for current AIs.

▲

tptacek 7 days ago | parent [-]

I think that's like, fractally wrong. We don't allow early-stage developers to bypass security policies so that they can learn, and AI workflow and tool development is itself a learning process.

	▲	lmm 6 days ago \| parent [-]
		> We don't allow early-stage developers to bypass security policies so that they can learn 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)

▲

philipp-gayret 6 days ago | parent | prev [-]

My workflow is somewhat similar to yours. I also much love --dangerously-skip-permissions, as root! I even like to do it from multiple Claude Code instances in parallel when I have parallel ideas that can be worked out.

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.

▲

Terretta 7 days ago | parent | prev | next [-]

Author (who also replied to you) might have been "doing it wrong" but no wonder, Anthropic only made Claude Code smarter about this 5 days ago and there's too much to keep up with:

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.

	▲	yahoozoo 6 days ago \| parent [-]
		How can an LLM determine a confidence score for its findings?

▲

indigodaddy 7 days ago | parent | prev [-]

I've often gotten the sense that fly.io is not completely averse to some degree of "cowboying," meaning you should probably take heed to this particular advice coming from them..

▲

tptacek 7 days ago | parent [-]

I have no idea what the fuck you're talking about but nobody is running Claude Code on our server fleet here.

▲

indigodaddy 7 days ago | parent [-]

You took it wrong. I'm with you here.

▲

tptacek 7 days ago | parent [-]

We're pretty averse to "cowboying". We're a small team working on an enormously ambitious problem at a much earlier point on the maturity curve than incumbents. It's fine if that maturity concern impacts people's take on the product, but not at all fine if people use it as a reflection on the people and processes building that product.

▲

indigodaddy 7 days ago | parent [-]

I think I just meant perhaps fly isn't afraid of responsibly "moving fast" in certain situations. Sorry for any offense, didn't mean it like that at all and there was no ill intent (actually the opposite) in my OC. At the end of the day I was trying to convey that the security stances of fly should be paid attention to.

	▲	tptacek 7 days ago \| parent [-]
		Sorry, I was pretty knee-jerk here.