Attacks · By business pattern
Per-call authority where ambient API credentials fail. Replay, relay, tamper, and vault-style key dumps lose the conversion path that makes long-lived API-key deployments expensive: Gate burn, request binding, and registry deactivation deny lasting caller rights after possession.
~6 min readDeep-link: Replay
API attackers call protected workloads with stolen keys, replayed tokens, mutated bodies, or revoked identities. The deployment question is whether possession of a long-lived credential still equals lasting caller rights after vault dump, CI leak, or agent clone - until rotation catches up.
API keys and bearer tokens authorize by possession from anywhere until rotation or revocation. That model makes vault dumps, CI leaks, and agent clones into full lasting-authorization failures: ambient API security is mostly secret distribution plus hope that the key stays private.
Gate-enforced envelopes bind each call. Burn-before-validate kills replay; binding kills relay and silent body swaps; registry deactivation kills revoked handles. Replace ambient keys with one-shot proofs at the workload boundary, then falsify with Verify against the deny path.
Deep-link replay, request-tamper, vault-breach, and revocation for dual plates. This pattern page is the migration lens for workload teams moving from ambient bearers to per-call authority.
Bearer lives outside the request
How to read: long-lived bearers left; possess-once call-many ambient win. Takeaway: authority survives the call.
Ambient API success is the key that works from any host until someone rotates it.
Burn-before-validate stops replay
How to read: second-submit myths fail; ledger burn then reject. Takeaway: spent nonces do not authorize again.
Per-call burn is the first falsifiable deny; binding and registry complete request-scoped authority.
Every API key, bearer token, and service certificate is a secret that works from anywhere until you notice it is gone.ValidatedAmbient credentials authorize by possession alone; ENI6MA replaces that model with one-shot, request-bound proofs.
Burn-before-validate is the structural reason a second submission of the same envelope always fails.ShippingGate stage 5 spends the nonce in the durable ledger before stage 6 validates the proof.Holds under the reference architecture
Every envelope is bound to a specific method, endpoint, request body, policy, freshness window, and nonce.Shippingsha256(method || endpoint_id || request_body_hash || policy_hash || tau || nonce_uuid)Holds under the reference architecture
Public gate order only - which check family denies this conversion. Not an NDA attack-to-stage matrix.
The gate hashes the body it actually received and compares it to the envelope.
Rejects: A body that was altered after the proof was made.
The envelope names the endpoint and the policy it was made for; both must match this route.
Rejects: A valid proof relayed to a different endpoint.
The handle is resolved against the registry and must be active. Deactivating a handle is how revocation happens.
Rejects: A proof from a revoked identity.
The envelope timestamp must fall inside the freshness window configured for the route.
Rejects: A captured envelope replayed after the window closed.
The nonce is spent here, before the proof is validated. Every submission spends it, including one that is about to fail validation.
Rejects: Any second use of the same envelope. This is where replay dies.
Only now is the proof itself checked, against the local binary or the registry. Both modes are equivalent at the envelope layer.
Rejects: A forged or malformed proof.
Ordinary authorization runs in the post-proof zone: arguments, limits, and business rules.
Rejects: A well-proved request asking for something it is not allowed to ask for.
The application does its work, and the response is bound back to the request that earned it.
Second submission dies at burn.
Body edits break the digest.
No reusable key as lasting channel authority.
One registry state change.
