raesene9

Yeah for any even vaguely security related tasks, using Anthropic/OpenAI models is a minefield. You might be able to cheat them into bypassing guardrails but that risks getting more seriously blocked.

What's possibly even more annoying is that the guardrails in Claude Code aren't even consistent. I've had cases where just opening a new session and repeating the prompt works fine.

It's much easier to just move over to GLM/Kimi/Deepseek and not worry about it.

and if 20% of labor costs are translated (a.k.a 20% more unemployment), who's buying all the goods and services those companies create?

The tech companies will just parrot "UBI" at that point, but given how adverse they are to being taxed, how UBI would be financed, is an unanswered question.

Let's posit that that's possible, for Anthropic to get to 500B in revenue, they'd either need 100% of the market or the market has to be even bigger.

OpenAI, Google, the many Chinese labs all have products and several of them likely have better financial positions. At the moment Anthropic have one of the best models but it needs to stay sufficiently above competition for them to capture a large share of the market.

At the same time this year we've seen a move for model diversification as cheaper models become "good enough". If this IPO was 6 months ago I think it might have gone better for them.

If the company controls the enclave, and controls the software that contacts the enclave, how do you know that your messages only flow to the enclave and aren't also logged somewhere else?

Attestation can get you the idea that the software they're running is what they say they're running, but unless you constantly audit every version, how do you know that it operates exactly how they tell you?

I mean how do you know there's really an enclave there at all :D If your threat model is "this entire provider is untrusted and potentially hostile" it seems like there's lots of options for them to do bad things, that can't be fully solved by secure enclaves.

I definitely wouldn't trust standard Linux style containers that expose a shared Linux kernel at the moment, there's been far too many LPE and container breakout vulnerabilities this year. It's possible that in future if the kernel gets a lot more hardened, that could change but things like Firecracker are a better bet from a security standpoint.

But if all those peolple are unemployed will they still be able to buy all the products the corporations sell…..

One other option, if you're an obsidian user is, just add the excalidraw plugin there, and then you can ask your agent to just create excalidraw diagrams as needed.

Definitely Opus 5.5 via claude code has no problems generating Excalidraw images with no additional software, just based on conversation.

For some cybersecurity tasks, the Chinese models are already good enough, things like PoC development or things like exploiting mis-configurations.

Whilst I'm sure the top-end OpenAI/Anthropic models might be better, I've found their guardrails so twitchy (especially Anthropic) that I wouldn't try to use them for even vaguely security related work.

The key word in the post you're replying to is "normal". Non-technical people don't (in my experience) plan for this kind of thing, like at all.

The idea of multiple hardware keys, which have to be enrolled individually to every site, is just not an ordinary end-user friendly activity.

So passkeys may be great for technical users (who are happy doing that) or corporate users (where centralized IT systems can be put in place) but not for standard non-corp users (which realistically, is most people)

In case it's useful, I did a talk about giving talks earlier this year which covered various things I've encountered/learned over the talks I've done and seen

https://tagt.mccune.org.uk/ - has sections and links to specific parts of the video, so you don't have to watch the whole thing to get to a bit that seems interesting :)

Jokes can be tricky in talks, as they rely on shared cultural context. If you know your audience well and know what will land with them it's great, if you don't then care is needed.

I generally advise people to put some jokes in if they like but don't make the talk rely on people getting the jokes.

This seems like a very nice release. Just ran it over my Kubernetes security benchmark that I run for most new releases. It was fast, cheap, and got a high scoring result, nice!

It's great that they're making the auto usage tokens free by default and I guess auto mode will be a good default for a lot of workloads, but recent changes to the auto mode classifier just moved me to either use YOLO mode or use a different harness.

I've been using Opus 4.6 for some security related work (it has much looser guardails that later opus models) and last week, all of a sudden, the processes started to fail. It wasn't the main model blocking commands but the auto mode classifier changed how it worked and it started blocking the main models commands.

That's one specific incident, but it does have a wider potential problem which is, if you use Anthropic's harness you'll always be at the risk of sudden breakage from server-side changes that are opaque to the end user, which is a tricky one for building long lasting processes.

Same Story as it ever was. The first time I encountered what I thought was a phishing attack at the bank I worked at 25 years ago, it turned out to be a marketing campaign, with URLs that put our company name as a user before the domain name (back in the day when creds could go in the URL).

So one of the factors in this is that Kubernetes disables the default seccomp policy provided by the container runtime, by default (you can re-enable it ofc, but you have to know to do that).

As a result I reckon there's more vulnerable containers that you might expect.

Also depending on the environment there's things like dirtyclone https://github.com/raesene/vuln_pocs/tree/main/CVE-2026-4350... which can be triggered where the attacker can start new containers.

Rootless helps, but less now that it used to (pre-2026). There have been a lot of local privilege escalation vulnerabilities in the Linux kernel (dirtyfrag, fragnesia, CIFSwitch et al) and several of those can be repurposed as container breakouts.

As a result, if you're looking for good security isolation, I'd say a (Micro)VM is a better option. The other route is hardening down your container runtime with seccomp/AppArmor/SELinux but that can be a tricky game.

They address that in the article :) to quote :-

"So where's this huge price gap coming from? token pricing, prompt caching, and effort-per-task. On SWE for example, K3 works much harder than Fable: roughly 55 turns and 1.3M tokens a task versus 21 turns and 130K. On the long terminal tasks it's the other way around: Fable is the one that spirals, running up 64 turns and 1.5M tokens (sometimes straight into a timeout).

Prompt caching does most of the work of turning that effort into K3's price advantage: even when K3 reads ten times the tokens, with cache hits that means that SWE runs still come in lower cost than Fable. There’s a tradeoff. Tasks with extra turns generally mean more wall-clock time per run i.e. slower runs. If you need an answer in two seconds, that matters; if you're running agents in the background at scale, a bill that's a fraction of the size matters a lot more."

As other have mentioned, and I'm the same. Leaving "Co-Authored by:" feels like open disclosure of how the project was created.

That way if a consumer does not want to use LLM generated/assisted software, it's easy for them to do that without having to search around in the codebase for "AI Tells".

Removing those would feel like I was mis-representing my coding abilities (LLMs are better at most coding than I am) :)

Interesting write-up and I do think LLM assisted/powered exploit disclosure is a real concern (I've been able to get models to create container breakouts from Linux LPEs relatively quickly).

One thing I'm surprised about is that GPT-5.6 didn't block that prompt due to guardrails. My experience is that GPT-5.5 and up does not like offensive security work (similar to Opus 4.7+/Fable).

I didn't notice it but I'd assume that the authors have some level of cyber approvals from OpenAI to relax the guardrails a bit.

Future returns are never guaranteed but over the course of the orgs history (since 1965) they've done a fair bit better than the S&P 500.... https://www.visualcapitalist.com/warren-buffett-vs-the-sp-50...

You might find some areas to criticize Berkshire Hathaway but I don't see being lazy as one of them. This is one of the most successful investment companies of all time and they got that way by being better than most at judging when the right time to get in and get out of the market, and by putting in the work on researching where/when to buy.

Might there be opportunities they miss? I'm sure there will be, but perhaps finding those is just too risky at the moment, so they've looked at the options and decided not to invest.

I'd say for some sectors and users, we're already seeing that. After GLM-5.2's release there were quite a few stories about it picking up use.

Then looking at Openrouter's stats we can see heavy use of non Anthropic/OpenAI models https://openrouter.ai/rankings#top-models

I'm not sure I'd call them rando, but Deepseek/Qwen/GLM all have decent models that will work fine for some use cases at much lower costs that the SOTA models from Anthropic/OpenAI.

It's an interesting thing and we can only speculate from the outside, but there's some obvious reasons why they'd literally hand out money in the form of free compute to people who have already committed to paying them.

- They've had to commit to minimum spend with their suppliers and their actual usage is below that level, so they might as well give it to end-users. That implies either their demand is waning or their forecasts were off.

- They want the usage numbers for this period to be higher and are willing to spend money to achieve it. I guess if they're about to IPO maybe showing more usage is good?

- They've got a lot of competition and want to keep market share. With lots of new models coming out, some of them much cheaper than Anthropic's options, you can see why this might make sense but it's effectively burning cash, so they won't want to keep doing that for long I'd guess...

I think until they produce full financial information, which will happen I expect when their S-1 is published, we won't have a good picture on Anthropics true position.

There's a lot of different ways to calculate "profitable" depending on what's included or excluded...

Interesting write-up. Having been a bookkeeper a long time ago, I'm not too surprised at this being susceptible to automation by an LLM backed system.

It seems also that the classes of error they encountered could be handled by improved skills/knowledge base access on the fine points of relevant tax legislation.

The important part for their software ofc is, will they take responsibility for the output if HMRC come calling? Without that users are adopting the risk which they may not be keen to do (dealing with HMRC is not fun), with that it could be a very nice saving for a lot of small companies (and bad for the employees of a lot of accountancy firms)

If you're going to have "blessed" plugins, which seems like a good idea, you'll need a review and possibly hosting process.

- Review to check that the plugin is reasonable quality/isn't malicious.

- hosting (e.g. the plugin is retrieved from a repo. you control) or "known good" checksums so pi will only download the plugin with a version that you've reviewed.

From a security/supply chain aspect, ironically what you're looking to do is deliberately add some friction to the publishing process, which sounds bad, but can be quite effective at mitigating attacks. Most of the recent supply chain attacks get found by automated scanners in < 24 hours, so having a review process for new releases that takes a while will reduce the number that affect users.

I think having this is handy as it'll give security conscious users more confidence in using pi, without the anxiety of pulling a load of additional code from effectively random sources.

It provides a right to privacy if the company allows personal messaging services on the device, but I don't think it provides a right to having personal messaging apps on the device(s).

Personally I think it's much cleaner to keep work stuff on your work device(s) and personal stuff on personal devices. The only place that gets sticky is where companies don't provide the device but want you to have work information on it (e.g. mobile phones)

I have a similar experience, for the last 5+ years I've worked in companies where very few of the people I work with are British which does require care on both language and idiom. Combined with being older than a lot of colleagues, cultural references need to be picked with care :D

The later Opus models (4.7/4.8), Sonnet 5, and particularly Fable 5 will refuse to do tasks related to offensive security.

One example I've hit is working on a benchmark of how well LLMs handle Kubernetes security tasks, there's a section on them exploiting security misconfigurations. Opus 4.6 was fine with that section, 4.7 and 4.8 saw some refusals and Fable point blank refused to do any of it.

The only other model I've seen refuse is OpenAI GPT-5.5, all the open weight models seem fine with it.

Ofc if you need to do that kind of work a lot you might be able to get on OpenAI/Anthropics allow-list for cyber work.

If you want to chat with Claude about this, I'd recommend using Opus 4.6. IME it's happy to talk about (and even write) PoC exploits