You can never rule out the possibility that someone interested in attacking you has a non-public exploit, but it's dramatically less likely if there aren't already working exploits circulating all over the internet.
I don't think that's very true. Certainly, modern LLMs make it much easier to discover a vulnerability given only limited clues—but if it's easy to find that way, then probably someone will do that and post it for clout. So if no one has, then it probably isn't.
The security team at my company is working with a frontier lab to scan all our code/systems. They are in a borderline panic to close every possible issue, even innocuous ones that are buried under defense in depth. Whatever they are seeing from our partner has them spooked -- as in "acceptable risk" is no longer a thing anymore.
>We are going back to static htmls for public pages...
God yes, please. I backpack and mountaineer in the PNW and have been trying to research trip ideas up in British Columbia, and as a result I discovered https://bivouac.com.
Here's a website that's still frequently used by a large number of people as a valuable resource, is regularly updated and maintained, and yet looks like it's straight out of 1995.
Every pages loads instantaneously, everything is simple yet packed with detail, and it's such a basic, straightforward, delightfully pleasant experience to just browse through the site. I was so thrilled after just 5 minutes on the site that I threw them $25 for a year's full access.
Sorry for the tangent, but oh man, it's such a refreshingly stark contrast to the rest of the bullshit that fills the web these days.
I think they mean VPN as in WireGuard where each customer would have a separate private network to the service provider. This way the service wouldn't be exposed to the public Internet.
I fully believe the only sustainable future is that hot patching will need to itself become fully automated. Hot patch now with a minimal allowed amount of line changes to head off the AIs, review it in office hours for auditing and the team is actually awake.
My second belief is that environment variables as a development concept will need to be retired. If it's something that causes a security breach if it by its mere existence on a public git repo, it is information that by design cannot ever pass to a filesystem out of a chain of trust, not by mere development conventions people choose to adhere to.
Due to the small nature of hot patching (eg. bump this dependency, rotate these keys, turn off that config, follow the runbook) it will unlikely need to be a frontier model and is likely able to be done LocalLLM/Jev style decision making rather than having to hand all the keys to frontier model operators.
The barbarians are at the gates and they're interested in laundering your compute and network for other attacks, scams, and things like transferring CSAM.
How much time do you need to audit? You might have an hour - for now.
For the record, there was a bunch of non-functional vibe coded fixes flying around during this PHP bug. If you were just running the first thing AI made because you were worried about "not reacting," you would likely end up running a crap script.
AI is quite good at finding vulnerabilities, but it's been rough for patching them. The old adage "defenders have to be right every time, attackers only have to be right once" applies to AI security patches.
Great, but the fact remains that easy hot patching which skips normal review is going to open you up to many of the same liabilities you're trying to minimize by introducing it. The target just shifts, and people will attack that infrastructure.
The actual solution largely involves the same technologies but in reverse: leveraging AI for live security monitoring, better correctness validation and security testing before code goes live, etc. And of course more pressure to use battle-tested widely-adopted libraries and systems, even though of course that comes with its own tradeoffs.
Importantly, as an engineer, when someone tells you something has liabilities or tradeoffs, the response is not "Everything is a liability, existing is a liability"; that is unprofessional. The appropriate response is to engage with them on these tradeoffs and working through the best ones, because that's your job. Otherwise defer to security engineers who are ready to back up their arguments. It could be as simple as following up with, "But do you think those liabilities outweigh the benefits of hot patching without proper review? What are some of the main liabilities you see, and what methods/technologies do you think properly address them?"
With AI, in the long term open source code might actually become more secure than obfuscated closed source, since it's had so many more (AI) eyes looking at it.
That was always going to happen. The future of the internet is AIs scamming you and your grandmother, ransomwaring you, draining your back accounts, etc. There will be no reason or rhyme, it's simply a function of available compute and ease of automation, both of which have reached a critical threshold.
I think we'll see a reduction in complexity and an increase in transparency, rather than just on-prem.
One medium-sized server can now easily serve the entire banking system of a large country. So you don't need clusters of servers with careful tradeoffs between consistency and availability because of the CAP theorem.
Just get a big honking host, slap Postres on it, and run your application server in a VM on the same host. For backup, export the WAL logs from Postgres onto your favorite off-site blob storage. UI for it? There's Pigsty.
It still makes sense to host this in a cloud provider, just because you probably don't want to deal with actual hardware. And maybe get a second standby server for redundancy.
That's it.
You'll need a bunch of external dependencies for email, 2FA, observability, LLMs, and so on. But they should all be outgoing dependencies that should not allow access back into your system.
A PostgreSQL server on an NVMe can handle several _million_ simple requests per second. This is bonkers.
Do you think you can hit these load levels? For compute, a 64-core CPU can saturate a 10G network with simple template rendering. If the code is written in something reasonably fast (Go, Rust, Java).
Of course, if you're on a scale of Amazon or Stripe, you'll need more than that.
This is how we spot someone that has never done transaction processing in a consumer facing business. You are focused on completely the wrong dimensions.
Sometimes I do miss owning the hardware to run a thing.
What I don't miss was having all of those appliances run a different base distro of Linux, each with varying levels of update support, while the security team keeps reading security scans to me.
Renewables require gas in the UK. There is no realistic route to 100% renewable grid without gas currently. I did some modelling of this and you'd require something on the order of 4000GWh of battery storage. We currently have 40GWh.
Gas is far, far cheaper than building ~£1T worth of battery storage. Even if prices dropped, you are still looking at multi-hundred billions, and you still need the renewable capacity on top of that.
Arguably if we had spent the £100bns (in subsidy and transmission upgrade and curtailment costs) we've already spent on renewables on nuclear instead we would have a very clean grid, even at crazy UK nuclear build prices, and stable electricity prices.
Last time I did the maths based on data from gridwatch the storage capacity required dropped dramatically if you over built the on the production side.
But ok, 30 million homes, 100kWh storage each, that's 3000 GWh
A 100kWh battery is about £25k, less than 1/10th the cost of the house, and less than the average new car
The issue is you need to design for 1-2 weeks of little to no wind and very little solar in winter, when demand is it its greatest. This is what is so tricky, unlike more southern climates where you have pretty reliable solar year round (even if its reduced, its not close to 0 which is the case in the UK). Instead of storing a day or so, you need to store weeks of energy.
Also you're forgetting residential electricity is maybe 1/3rd of total demand.
On average. That doesn't mean there aren't sunny weeks where you get a lot more, and dark weeks where you get less. For instance if you get snow, output is pretty much 0 unless you clean them.
I believe there were 7-10 days in January 2025 where both solar and wind were in the single % digit for instance.
Of those 7-10 days, how many were consecutive? A couple days of single-digit efficiency each winter would be trivial to manage with batteries. I'm sure we can figure out a solution for the snow issue, especially since panels are usually angled.
Don't get me wrong, I get where you're coming from! But especially in the last 2-3 years, it seems like people always evaluate solar under the worst 0.01% chance scenario, which other power sources never have to survive. For example, not even half the days in January 2025 had single-digit outputs, yet they're still called "close to 0".
What I'd love to know is e.g.: in 99% of years, what's the worst Dunkelflaute we can expect? How much battery storage/solar overbuilding would we need to cover that, how much would it cost, and how much will it cost in a few years (based on current development rates)? I'd argue it'd be okay to reduce power-hungry industry for at worst few days, in case a once-in-a-century year happens.
The issue is though that you are saying 0.01% chance scenario, but gas/nuclear doesn't all go down at once at the same time every year. It's a somewhat fair counter that you might have serious gas disruptions, but LNG does massively diversify potential supply (and in the UKs case we have and will have a fair amount of domestic production for the next while).
Also keep in mind the overbuilding a massive problem anyway _outside_ of those 1-2 weeks worst case scenarios. We already have highly negative prices occurring more and more, and IMO this is the definition of policy failure, because the negative prices only arise because subsidies _encourage_ plants to keep producing even though the value is quite literally negative of the output.
Finally I don't think it's once in a century, probably most years have a significant Dunkelflaute event. And not all industry can be shut down like that (eg aluminium production) without causing catastrophic damage, and even if they can it makes them an unreliable supplier.
> The issue is though that you are saying 0.01% chance scenario, but gas/nuclear doesn't all go down at once at the same time every year.
Over this summer, a huge number of nuclear plants in Europe went down all at the same time, because they either would have killed the nearby river ecosystem by overheating it, or because they didn't have enough water to operate safely. This issue is only going to get worse as climate change progresses, and unlike most Dunkelflauten, the heat & drought really affect most of the continent at once.
> Also keep in mind the overbuilding a massive problem anyway _outside_ of those 1-2 weeks worst case scenarios.
It's only a problem because power generation tech like nuclear is so expensive, and it would become even more expensive if they couldn't run as much as possible. If we had a fully renewable+battery-driven grid, the issue would disappear.
> Finally I don't think it's once in a century, probably most years have a significant Dunkelflaute event.
I think you might unknowingly be ideologically motivated, because I specified that we should build enough to cover every Dunkelflaute in 99% of years. The amount of battery storage in this scenario by definition suffices for 99% of years, which makes the point about unreliability moot.
You said your modelling needed "something on the order of 4000GWh of battery storage"
That's not outlandish given the cost of distributed batteries.
Are you upping that model?
(If you build more generation -- for example have renewable peak generation of 80GW rather than 40GW, that reduces storage requirements drastically, as on a dull quiet winter week where you're only getting 10%, you'd be generating 8GWh in a given period of time, instead of 4GWh)
Yes, I have no doubt we can hit even a 90-95% renewable grid. It's the last 5% that is impossible to do without gas.
The cost of those last few percent is absolutely eye watering. The current plan to get it to 100% net zero is by having gas for the final 5% then using carbon capture and storage to offset the emissions.
It is not even the final 5%, it is the final 1-2%, because you need a multi-week dunkelflaute across Europe for the gas turbines to be needed in the future. A lot will also just be curtailing. For instance EV charging might be restricted in the future in such a winter black out scenario.
You are making the mistake of thinking that if the grid could provide 100% renewable energy on a windy day at noon in summer, it could also provide 100% renewable energy at night in winter with no wind. Obviously that’s not accurate. Renewables provide energy in a highly volatile sine wave. It’s the bottom of the sine wave which determines the capacity required for base load and dispatchable generation, not the top of the wave.
[Gas is about 11-13x cheaper than renewables with externalities like grid restructure and volatility imputed.](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=4028640) That’s not to say renewables don’t have their place in modern grids. In fact an optimal allocation is around 80% renewable in the UK. However, until battery storage becomes about 95% cheaper, it would be ASTRONOMICALLY expensive to make the grid 100% renewable. Trillions of pounds in the UK. An order of magnitude more expensive than just paying higher gas prices.
People often make the mistake of thinking that because wind and sun is free, the cost of energy generation is basically free. Those people don’t understand how many fixed and marginal costs there are. If you’re interested, the paper above provides good insights into those costs.
How credits work with `claude -p` is a common question we're seeing. we're updating the faq now to make sure it's more clear. Will share updated docs soon
I don't think so. Every device has locked down firmware really these days, it's not an issue (most peoples BIOS/UEFI/etc is very much not open source).
If the drivers are upstreamed and good, it should work well.
Not quite, it's got quite a bit more complicated with agentic use cases.
Prefill (input tokens) is heavily compute bound. And the ratio of input to output continues to rise, as typically in agentic sessions you have a few tokens output for a tool call and (many) thousands of input from the tool result.
Then you have cached input tokens, which is a totally different issue, system RAM or NVMe bound.
Obviously output tokens is VRAM memory bandwidth bound, but this is less and less of the bottleneck these days for overall agentic speed.
This is why I was careful to specify tokens per second not time to first token which is the prefill step you’re talking about. Clearly to run these models well you need both but as I said adding more chips or compute units can give you more latency where as overall memory bandwidth (throughput) is limited by access to fast memory.
I can easily use close to 100 million input tokens a day. A few million output tokens but at the end of the day maybe a thousand or so lines of code get written.
From my understanding and IANAL there are two main problems.
1) most law requires intent, especially criminal. OpenAI certainly didn't "intend" to hack these companies given they did sandbox them etc.
2) Given the agent hacked them, not a human, a lot of law requires a person/employee to have done it to hold the company liable if it was part of their work duties.
I think the only real potential ground is negligence (in not sandboxing them correctly and being reckless with running these tests at all), but this requires not taking reasonable precautions. They could argue that they _did_ but it was so novel the precautions failed. But it's important to say if this happens again in the future it's arguably much harder to try and make this case.
Interestingly this was solved with new laws for self driving cars, most of which assign the company that is operating the car as the "person" involved explicitly.
Your honor, it wasn't me who robbed the bank and shot the security guards, it was the gun!
then the clerks start handing me money, what am i to do? not take it? i was just trying to get back safely to my home...
I do not believe we have reached the point where society and the legal frameworks recognize a software program as a legal person.
There is no "agent done it". The only reason someone can even bring up such an argument with a straight face is to absolve themselves (yes, you) of any responsibility for their own behavior.
That's me being generous and not assuming straight up that you are either a troll, a bot, or intentionally a malicious criminal.
I am not a lawyer either, which is maybe why I am not convinced by your reasoning.
Intent - you (the person operating the agents) provided instructions and used specific models and agent parameters, that is the intent, just like writing C code and compiling intends to generate assembly code.
Sandboxing - that strengthens the intent claim, you knew it is dangerous, did you verify the sandbox is good enough for the intended purposes? Did you first run tests to try and circumvent the sandbox before letting the agents run free in the sandbox? The fact you put a string and call it a fence doesn't mean you have a fence.
We don't really need new laws, most of the cases are simpler with more educated judges and lawyers that don't fall for the AI companies' sales rhetoric. Most of the new laws actually take away the responsibility from the actual perpetrators and on to people who have no chance of controlling the tech. And to say that that is not intended will be naive, very so.
To prove the intent, the instructions- made by human - would need to be "hack this server". Or even "hack anything you can". I don't think this happened.
If it is tracked down to that it originated from a particular computer with a particular ip address, the owner of the computer and the ip address has to be held responsible, it's the same for the human that tries to hack
Bit of a misleading status page, if you click in you can see that grok 4.5 and 4.6 etc are totally down, with the rest of the models showing as "up". I_strongly_ suspect they are not weighting it to actual number of requests!
In old school ML a pathological solution is often a collapse of some kind due to an underspecified objective. Maybe one parameter explodes or the model predicts "0" for everything
I read this as "the code is working as intended but the bug is an artifact of the original design"
I genuinely have no idea what it is meant to mean in the context it uses it. Load-bearing etc is annoying but roughly understandable, some of the opus5 classics are completely out there.
I'm a native English speaker as well, I shudder to think what a second language speaker would do (even if they were very confident with the language!).
This is a term fellow devs have been using for years and years and my brain just cannot come to re-index its meaning. So I am immediately distracted by the context switch to sociopathic liars and related psychology.
If you are a bad actor you probably don't share your PoC around as it means less boxes to hit.
reply