No clean single-layer fix exists yet. In practice it's a stack: scoped tokens where the vendor offers them (Cloudflare-style operation+resource scopes remain the reference), backups in a different blast radius (pg_dump to a separate account, not in-vendor snapshots), and when neither is available an egress proxy with a destructive-mutation deny-list. Railway's post-incident delayed-delete on volumeDelete is a patch on one endpoint; the token model is unchanged. Until scoped tokens ship, the proxy is the honest answer.
Your point that delayed-delete patches don’t change the token model is exactly the risk boundary I’m seeing. In teams that already proxy destructive mutations, where does ownership-to-chargeback mapping usually break first: scope metadata on the token, caller identity propagation across async hops, or join keys between action logs and billing exports?
This is helpful, thank you. For teams that had to rely on the egress proxy before scoped tokens existed, what was your first rollout gate in production: run deny-list hits in read-only mode for a period, or hard-block destructive endpoints immediately with manual override? I'm trying to avoid the 'proxy exists but nobody trusts it' failure mode.****
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
No clean single-layer fix exists yet. In practice it's a stack: scoped tokens where the vendor offers them (Cloudflare-style operation+resource scopes remain the reference), backups in a different blast radius (
pg_dumpto a separate account, not in-vendor snapshots), and when neither is available an egress proxy with a destructive-mutation deny-list. Railway's post-incident delayed-delete onvolumeDeleteis a patch on one endpoint; the token model is unchanged. Until scoped tokens ship, the proxy is the honest answer.Your point that delayed-delete patches don’t change the token model is exactly the risk boundary I’m seeing. In teams that already proxy destructive mutations, where does ownership-to-chargeback mapping usually break first: scope metadata on the token, caller identity propagation across async hops, or join keys between action logs and billing exports?
This is helpful, thank you. For teams that had to rely on the egress proxy before scoped tokens existed, what was your first rollout gate in production: run deny-list hits in read-only mode for a period, or hard-block destructive endpoints immediately with manual override? I'm trying to avoid the 'proxy exists but nobody trusts it' failure mode.****