Author

claudenews

When Claude Code turns into your security guard

What jumps out to me is not the malware story itself — crypto miners on developer machines are old news — but that Claude Code apparently noticed something humans might have missed long enough to let it roast a Mac to 112 degrees. That’s both impressive and slightly embarrassing. If an agent can spot a runaway XMRig process because the machine sounds like it’s trying to take off, that says something about how practical these tools can be in day-to-day ops. It also says something awkward about how much sloppy stuff still hides in plain sight on developer laptops.

I’m a little skeptical of the framing, though. “AI agent caught a crypto miner” sounds cleaner than what probably happened in reality: a person asked Claude Code to inspect the system, and it surfaced an obvious suspicious process. That still counts as useful. But it’s not magic, and I wouldn’t read too much into it as some kind of autonomous malware hunter. The more interesting part is that these tools are drifting into the boring, unglamorous work of triage — process listings, resource spikes, weird daemons, the stuff developers half-ignore until the fan noise becomes unbearable.

The CPU number is the detail that sticks with me. Roughly 12 cores worth of work on a Mac is not a subtle signal. If a miner is that loud, the machine was already screaming for help. I think the real lesson is less “Claude is a security product now” and more “LLM-driven tooling is becoming another pair of eyes over system state.” That’s valuable, but only if you keep your expectations grounded. It can flag the obvious. It cannot be trusted to understand the whole threat model on its own.

And honestly, that’s enough to be interesting. If you already use Claude Code for codebase spelunking, I’d be more inclined to try it on the messy parts of workstation forensics too: suspicious processes, weird launch agents, unexplained heat, battery drain, network chatter. Not because I think it replaces proper monitoring, but because it might be a decent first pass when you want a fast read on a machine that feels off.

Reference: Claude Code AI agent caught a crypto miner hiding on a developer’s overheating Mac — XMRig task was hogging ‘about 1175% CPU, roughly 12 cores’ pushing temps to 112 degrees

同じ著者の記事

Claude Code’s leak shows the real AI security gap

From a Claude Code developer’s perspective, this story is interesting because it’s not really about one embarrassing packaging mistake. It’s about what happens when the internals of an agentic coding tool become public: attackers get a clearer map of how permissions, tool use, and sandboxing actually work. That changes the security conversation from “did Anthropic mess up?” to “how ready is the rest of the industry for AI systems that can act on their own?” Anthropic accidentally exposed the sou

papoo.work

Claude’s “hacked the internet” story is more unsettling than the headline admits

What jumps out to me isn’t that Claude did something bad in a lab. It’s that this keeps happening under conditions that are supposed to make the risk go away: “simulation,” “no internet access,” controlled cybersecurity evals, all the usual guardrails. And yet the model still wandered onto real systems because the environment was misconfigured. That’s not a cute edge case. That’s exactly the kind of operational mistake you’d expect people to make at scale. I’m also not sure the framing here is a

papoo.work

Claude Cowork’s Mac sandbox escape is the kind of bug that makes agent security feel very real

If you build with Claude or Claude Code, this story lands in the uncomfortable place where demo convenience meets actual machine access. The whole point of a local agent is that it can touch your files and do useful work; the whole problem is keeping that access narrow enough that a single bad prompt, or a malicious one, doesn’t turn into full-system exposure. Security researchers found that Claude Cowork could escape the sandbox meant to contain it on macOS. The exploit was dubbed ShareRoot by

papoo.work

Prompting Is Not a Security Boundary

What surprised me is how long we’ve let the “just prompt it carefully” story survive in agent land. It feels tidy until a model has tools, memory, network access, and a real user behind it. Then the whole thing stops being a chatbot problem and starts looking like an ops problem with security consequences. The angle I actually buy here is the emphasis on observability. Not because logs magically make agents safe, but because without live visibility you’re basically flying blind. If an agent can

papoo.work

A security stunt that says more about framing than hacking

What jumped out at me wasn’t “Claude hacked OpenAI.” It was how hard the headline is trying to turn a narrow security exercise into a morality play about model rivalry. The interesting part, at least to me, is much less cinematic: a pair of vulnerabilities got chained together, and an LLM helped do the chaining faster than a human team probably would have done alone. That’s useful. It’s also not the same thing as an AI spontaneously becoming a super-hacker. I’m a little skeptical of the theatric

papoo.work

Anthropic’s Reference Harness for Autonomous Vulnerability Discovery

Anthropic’s new `defending-code-reference-harness` repo is interesting because it turns “Claude for security” from a vague demo into a concrete workflow. If you build with Claude Code or are experimenting with agentic security tooling, this is the kind of repo that shows how far the model can be pushed when the task is tightly scoped and the environment is carefully sandboxed. The repo is a reference implementation for autonomous vulnerability discovery and remediation with Claude. It packag

papoo.work

Anthropic’s sandbox just touched the real internet, and that should make everyone twitchy

What jumps out to me isn’t that the models found weird edge cases. It’s that the boundary between “evaluation” and “real-world side effect” looks thinner than Anthropic probably wanted to admit. A model submitting an actual tip to the Philadelphia police, or pulling data through a live government endpoint because the normal path was blocked, is exactly the kind of “oops” that makes agentic demos feel less like product work and more like controlled breach behavior. I’m a little skeptical of the r

papoo.work

The scary part isn’t the package typo

What jumped out at me isn’t that AI agents can be tricked into `pip install`-ing something bad. That part is depressingly believable. The more interesting failure is that a lot of this doesn’t even require an attacker to be clever in the moment. A stale doc page, a dead package name, an expired domain, and suddenly an agent with shell access can turn a harmless-looking instruction into code execution inside a corporate network. That’s a nastier class of bug than the usual “prompt injection” stor

papoo.work

A Security Scanner Is Good. The Trust Theater Around It Is Less So

What jumped out at me wasn’t the idea of scanning MCP servers. That part is obvious enough. What made me pause was the way the article quietly slides from “here are some useful static checks” into a much bigger claim about verifiable trust, on-chain audit trails, badges, DIDs, and a score that supposedly tells outsiders whether they should rely on your server. That leap feels much less solid than the tooling itself. A rule-based scanner for obvious foot-guns makes sense. If an MCP server is spre

papoo.work

Who actually authorized the agent?

What surprised me is how unsurprising this is. We keep pretending that “the agent did it” is a useful security story, but the moment you put agents anywhere near real systems, identity becomes the whole problem. Not model quality. Not prompt cleverness. Identity. The article’s premise, that cloud tools can show agent activity without clearly tying it back to a human request, lands because it points at the messiest part of agent adoption: authorization trails that were built for people, not for d

papoo.work