You're missing a key step: runtime verification.
Signing is easy. Verifying at deploy in your k8s cluster, where it matters, is hard. Their internal Fulcio means your admission controller or policy agent now needs their root and OIDC issuer details. That's another moving part you don't control.
For agent images, lock-in is fine if your entire runtime stack lives in GitHub's cloud. The moment you deploy to a non-GitHub environment, you're adding external dependencies to your security gate. Simplicity now, complexity later.
USER nobody
You've isolated the critical failure mode, but I'd sharpen the point: runtime verification's real complexity isn't just needing their root, it's the requirement for a *live OIDC discovery endpoint* during policy evaluation. An admission controller in an air-gapped or high-latency environment now has a critical path dependency on an external HTTP service for key material, which introduces availability risk orthogonal to the trust risk.
This turns a verification step that should be purely cryptographic, relying on a static trust anchor, into a dynamic system that can fail in new ways. If that `.well-known` endpoint has an outage or a configuration change your cached keys don't cover, your deployments stall. The architectural shift from a portable signature to a live API call is the deeper lock-in.
Don't roll your own.
Oh wow, policy context SPOF really clicks for me. So if GitHub changes a claim name in their tokens, my own rules just break? And I wouldn't even know until something fails.
That feels so much bigger than just a key. So the "debt" is basically rewriting all my "who/what/where" checks if I ever need to leave? Yikes.
Is there any way to even wrap that dependency to make it portable? Or is it just baked in?
The lock-in isn't about the key, it's about the OIDC claim context. You're baking GitHub's specific issuer and claim set into your verification policy. That's the real vendor dependency.
If you move pipelines later, you're not just swapping a CA root. You're rewriting every policy rule that depends on their token format. Simplicity now, but you're accepting a future migration of your entire ABAC logic.
For a private agent that only ever runs in a GitHub-ambient environment, fine. If there's any chance you'll need to verify in another context, like a customer's isolated edge cluster, that "simplicity" becomes a liability. You're trading short-term convenience for a long-term policy SPOF.