17 comments

[ 1.9 ms ] story [ 29.4 ms ] thread
Does this apply to anyone who verified their ID to get access to the slightly less restricted Codex versions, or only to security professionals who have the almost-entirely unrestricted version?
This is what I want to know too. I already gave them my ID, and I won't be happy if they put more barriers to my usage
If they're going to be forced to play these games, may as well make it somewhat secure.
I hope that at some point this is not developing to remote attestation when only "permitted" devices can use the models.
Or even only letting the model be used via remote desktop style access.
It’s an advertisement by Yubikey - the hardware key manufacturer
Cobranded YubiKeys? Weird flex but ok.

Seriously though if you are letting agents do whatever they want without a PR process that requires hardware authentication or proof of presence, you are putting your code and your org at high risk.

> Cobranded YubiKeys

More interesting than that even, a tier of YubiKeys that does not exist outside of this cooperation.

The supported features sit between a YubiKey 5C and a Security Key C and I did not find any other way to purchase this tier.

> want without a PR process that requires hardware authentication or proof of presence

Just curious, what do you use for this?

I built OTP Guard [1] a few years ago for exactly this problem, although I haven't seen any alternatives in the space. Does GitHub have something built-in now?

The original framing was more "local malware compromising your GitHub account" ... it never occurred to me that the malware could be a LLM. I really should update the website.

[1] https://otpguard.com

My simple process is:

0) agent gets its own separate git user and ssh key, separate from mine

1) branch protection rules on main, only I can approve merges into main

2) any other ssh key uses (interactive login, direct git access, etc.) are ed25519-sk keys and require a touch on yubikey.

TBH, the biggest hole is that it can be unclear exactly what process is requesting a touch on the yubikey. Apple has a head start here because they can lock down the TouchID UX relatively well, but unfortunately they don’t seem to care about building a polished developer experience for 2FA on sensitive tasks.

They are probably waiting for someone else to build the right solution and then copy/steal it.

I was actually thinking they would have to do this. Having to mail a physical token to a valid address is a extremely powerful access control method.
Dumb question: is using the built in passkey support on my iPhone not considered “hardware-backed”, since iPhone is using device biometrics?
It's a great deal — about 50% off — for those who already wanted a Yubikey.

https://www.yubico.com/store/partner/openai/

Interestingly, I had to switch to my unpaid OpenAI account to access it. I suspect this is because my paid account is registered to a custom.com email address.

I was looking at something similar a couple of days ago. I think a physical key like a yubi key is a great way to fight bot traffic. And apparently cloudflare already ran project to test this out, and found some small drawbacks. So they proposed CAP together with other orgs https://developers.cloudflare.com/fundamentals/reference/cry...

This might be an extreme case of that, but I can see us going in that direction