I think every API key system should have endpoint "invalidate_api_key" this way whitehat hackers or the party who stored them could invalidate all keys in the case they leak. Now it is race against the time, and everybody got email, and everyone must act themselves.
It actually is a thing, although indirectly in a hacky way! If you push keys from GitHub secret scanning partners to a public repo or a gist, they get sent to the partner who (usually) instantly revoke them. So if you want to help someone, just make a public gist with the key and delete it like 15 seconds later, it'll be enough.
Only responsible thing in this case would have been for OpenCode people to invalidate all keys. But I guess it is not that straightforward if Anthropic/OpenAI etc don't have endpoint for it.
There's no self-serve endpoint, but OpenCode could send the inference providers the leaked keys and ask for them to be revoked, which is a thing the inference providers can do. It's possible that this'll happen, apparently remediation is still in progress.
Given they found a secret key in a public place? No that’s not malicious and it would be odd for a serious organisation to be upset someone immediately invalidated it.
Are you really unable to imagine a situation where financial or physical harm is caused by a system abruptly being shut down by a credential revocation, triggered by a random person on the internet?
Other options available: ruin the company financially, violate the terms of service of whatever system it uses and get the organisation banned, access business/customer data.
If it’s that sensitive and there’s access keys accessible to anyone, it could end up much worse. Nobody said it was without inconvenience.
This is so stupid. It’s pretty simple: malicious actors will use it to do all of those, plus now they can unilaterally bring down a system via revocation.
Non-malicious actors using it to bring down a system via revocation are therefore indistinguishable from malicious actors. It’s by definition a malicious act.
That’s why it’s a stupid idea. Non-malicious actors should just contact the company and let them take action. It’s not for an outsider to decide the impact of a leak.
Could you point to the part where I said revocation as a principle is a bad idea? Rather than what I actually said, which was that untraceable random third parties revoking your keys without any involvement likely isn’t a good idea.
Also GitHub doesn’t revoke the keys. The providers of the key take provider-specific actions, which may or may not be revocation.
That’s your opinion and plenty of people in here have pointed out they disagree. It has nothing to do with people not being serious or being unable to envision a situation where it impacts an important system.
Is that system made by a supervillain or a mad scientist? But such system can go amok for any reason. Anyway revocation is already possible by publication on github, telling to GPT or sending an email to webmaster.
The alternative is that the key won't be quarantined and the attacker will be able to do everything. And quarantine still means denial of some service, e.g. ec2:StartInstances is denied, but ec2:StopInstances is allowed? So the attacker can shut down the system and you won't be able to start it again?
Can you point me to where I said I had an alternative? Or any rules that say you can’t discuss an ideas flaws if you don’t immediately have an alternative?
The status quo is clearly the local minima, given the myriad of trade offs and different parties involved.
Not any more than any other public endpoint service exposes.
This revocation endpoint can be protected by auth too. Use API key that you're revoking in auth.
I see now from another comment you thought about denial of service for service that leaked key. And I thought about mass leak resulting in DDOS onto API provider. Wrong guess from me.
Article refers to Hugo Duminil-Copin, who also did a podcast with Brady Haran [1] about this subject, for him it isn't case of bruised ego, or gatekeeping. He realized that the way things were done were going to change, and it made him emotional, he is not pessimistic or against AI.
GPT-6 Astra with computer use has gotten some of architects and 3d modelers wondering what their future is. Astra does such a good work with SketchUp 2026 and computer use, here is video, but it is well worth it because the author actually knows his stuff:
> Openrouter is not ideal, because you don't know who they send your traffic to and there are rumours of vendors cheating by providing quantized models.
OpenRouter allows to make an API key locked to certain provider, I do that myself.
This sounds a lot like Spotify's XIRP. They managed to vibe something useful for their own engineers, were super hyped, and decided to release it in public. However what are the odds this harness will stand the test of time against actual harness makers like OpenAI or Anthropic? Neither Spotify or IBM are focused on making models or harnesses, these are just side-products.
To be fair Codex and Claude Code don't have a lot of secret sauce either. This is not to say that the harness doesn't matter at all or that you can't do any better, but whenever they benchmark it always turns out that you don't lose that much with even a very minimal agent. If a different harness makes better sense for your workflow I don't see why you wouldn't switch (or make your own if you have the resources to do so).
I'm also sticking to first-party agents, but that's more because I feel no compelling reason to switch and CLI agents fit well with my spartan technology choices. YMMV.
IBM is training their own models (for instance IBM granite) as well as watsonx as a platform. They are trying to build a products for enterprise as well as their specific AI modernization models.
Sure! IBM and Spotify, two companies united in being famous for not being software consulting businesses and definitely not ever developing software development tools.
Very cool. I'm cloning the repo, just in case it gets taken down. I've been using EGUI, but its biggest problem is that LLMs really struggle with it. There isn't enough good examples of it. This codebase seems to have a lot of good examples, so given this as a reference, one might make a lot of progress much faster.
One thing would be shipping interfaces without implementations. Rust could try to ship more traits without implementations, I do see it could be problematic with Rust as they don't try to be opinionated on what you will build.
There is another alternative too, releasing interface only packages, then hoping everyone agrees to use those. JavaScript/TypeScript people actually did this already for one very tricky one, validation, see Standard Schema [1], which was great success. But I would hope to see more, for instance interfaces around typical building blocks like job queues, email sending etc.
Thanks, quite an achievement they got people to agree on the interface. However, for supply chain attacks the danger lurks in the implementation, not in the interface. You could argue that this approach comes with the benefit that one could switch implementation when one library goes rogue, but that is imho too little and too late.
I also have Kobo Clara BW, and don't like swipe gestures, or any gestures whatsoever.
I (now) know why I don't like that, because regular book and magazines, you don't have to think about how you hold it. Your thumb isn't going to magically flick a page by accident if you take a firm grip on it. With gestures only e-ink books, I have to take extra caution how I hold it so that it doesn't trigger something.
